REA : responds to Apache Log4J vulnerability

On 10 December, a security vulnerability in a widely used open-source software library, Apache Log4j, was made public.

The vulnerability, renamed to Log4Shell, can lead to remote code execution without authentication.

As far as vulnerabilities go, it's a doozey - it has a base score 10/10 on the National Vulnerability Database, and it has literally set the internet on fire.

You can read about it here

Why is this?

Put simply, this library is pervasively used by software engineers to add logging capability into their systems. What no-one realised was the inherent functionality of Log4j meant that simply by adding entries into a log file, that could enable someone to maliciously download files and run commands remotely on someone else's infrastructure. It's as bad as it gets from a security exposure viewpoint.

Given the popular use of the library it's hard to imagine an organisation that is not impacted by this vulnerability - either directly using it in their own code, or indirectly incorporated into third-party products such as SaaS (Software-as-a-Service) and on-premise technology.

Was REA impacted by this? Like many organisations, you bet we were, but we immediately invoked our response plans and got to work assessing our exposure and taking mitigating actions. As a result, REA's products and systems have not been exploited by the vulnerability.

What is our approach to this at REA?

We prioritise our response based on risk, but our strategy is simple - leave no stone unturned.

Our approach to this vulnerability is to block, patch or disable functionality that could lead to an exploit, based on information available from security researchers, and our own multi-level scanning.

We're going further however, looking into dependencies, second-order exposures (from code libraries) and making enquiries of our own software suppliers where we do not manage the code ourselves. This has meant applying patches for third party software as they become available or implementing mitigations while we wait for these to become available.

What have we done?

We're not taking this lightly. Over 150 engineers across REA have been involved in our response, which has been coordinated through our Cyber Security team. That's one third of our Tech firepower being directed towards this problem.

Our partners have also been very helpful, responding to requests for information, providing software updates and allowing us to leverage additional scanning capability.

REA is a member of the Joint Cyber Security Centre and we have been following updates and remediation advice.

We have detection and monitoring in place to alert for any potential exploitation attempts as well as other mitigation controls.

Continuous evaluation

We're not stopping there. Since the original disclosure on 10 December, we have evaluated several related vulnerabilities as more research emerges. This means we're continuously assessing the need for further action - we strongly believe that similar exposures will be discovered - it's only a matter of time.

As this issue continues to evolve, we will continue to implement additional remediation actions as appropriate.

Where can you get help?

We recommend the following resources if you are worried about the vulnerability or want to lean more:

Australian Cyber Security Centre

Apache Foundation

Lunasec

Parting thoughts

All software has vulnerabilities, and some are more serious than others. Like many organisations, REA has a dedicated cyber security team and operate a vulnerability management program. We encourage information sharing and cross-industry collaboration. We also operate a responsible disclosure policy. This makes everyone safer online. Our thoughts are with our peers and friends across the technology industry as they respond to this issue.