13th December 2021

Late on Thursday 9th and into Friday 10th of December 2021, we began to see reports of a new zero-day vulnerability found in the popular Apache Log4j Java library. This remote code execution vulnerability is being tracked via CVE-2021-44228 and has been named “Log4Shell” (the security researcher, Kevin Beaumont, has even pulled out all the stops and given it a logo).

Log4j is a very handy and popular library used by application developers to automatically include logging in their apps. This vulnerability is particularly scary given its ease of exploitation and widespread usage.

Log4j is maintained and released by the open source foundation Apache, who have already released a fix in v2.15.0. The Log4Shell vulnerability affects all versions from v2.0-beta9 to v2.14.1.

The best defence is to ensure your systems are patched and security is up to date. However, if patching can’t be achieved quickly, the Apache team has also suggested a workaround (see details below). 

By Friday afternoon, our Threat and Vulnerability Management (TVM) and Incident Response (IR) teams had fully mobilised and knew they had a busy weekend ahead of them.

To date, Options have found no applicable instances of any public exposure or Indicators of Compromise (IoC) within our systems. To ensure the highest standards of protection, we have focussed our efforts on 4 key areas:

Enhanced Scanning

We updated our firewall IPS signatures across our global estate to include the latest Log4j exploit signatures. Our internal vulnerability scanners have also been updated to the latest releases that include Log4j identifications. We have scanned all internal and client networks and devices for any related vulnerabilities.

Vendor Reviews and Patching

As software and hardware teams around the world scramble to review their codebase and confirm their response to the vulnerability, we have been just as busy pouring over announcements and contacting their teams directly. We’ve been applying the fix and/or working with clients to help them apply it.

External Penetration Tests

We’ve had our 3rd party pen-testers conduct detailed assessments of our public perimeter, and they have not identified any log4j-related issues. 

Communicating with Clients

We have been releasing, and continue to release regular updates on our response, and are working closely with client Security Teams. We will maintain these communications throughout the incident.

Workaround

As noted above, the workaround for this zero-day is to set the system property “log4j2.formatMsgNoLookups” to “true” or remove the JndiLookup class from the classpath for versions 2.10 and above.

As always with a new serious zero-day vulnerability, it’s a marathon and not a sprint but the first miles are critical – the Options Security Team has set the pace yet again.

To learn more about Options Managed Security offering click here.

You are currently viewing <a><strong>Zero Day: Log4Shell</strong></a>