Overview of the Log4j vulnerability
On December 9, a vulnerability in the Java Log4j logging library was publicly disclosed. Tracked as CVE-2021-44228 and with a CVSS risk score 10, this remote code execution (RCE) zero-day vulnerability is being exploited in the wild.
Many application servers use Log4j for logging incoming requests, and many Java-based services use this library to process logs later on in the pipeline. Since exploiting this vulnerability is easy (it only requires attackers to control a portion of the log message) and since it can lead to full control of the affected server, this attack is especially potent.
The first attack vector is clearly internet-facing services such as web and API application servers. Over time, we expect to see residual exploitations taking place as other vulnerable tools process “infected” logs, as well as completely new attack vectors that are not API and web-app related.
Detecting Log4j Exploitation Attempts With Neosec
Neosec uses API activity logs to perform API monitoring out of band, which ensures broad coverage with minimal friction.
Our Log4j exploitation attempt detection model triggered alerts in our customer environments starting December 10 (we did not see any exploitation attempts prior to December 10).
In addition to attempting to exploit the User-Agent header (since it is often logged in access logs), we have seen exploitation attempts via other often-logged headers such as X-Forwarded-For, and through various parts of the URL including the path itself and parameter names or values. Some encoding and simple obfuscation techniques are beginning to emerge.
Impact on Neosec
The Log4j vulnerability does not affect Neosec Cloud functionality. We immediately upgraded the few affected components to the latest version of the Log4j library, which is not vulnerable.
All our customers have been contacted and notified if any vulnerable components were identified with recommendations to upgrade to a non-vulnerable version.
Specifically, if you are running a vulnerable version of our RedHat RPM-packaged or container-based Neosec Collectors, you have already been contacted by us for upgrading to the latest non-vulnerable version.
Log4j Vulnerability Details
The Java Naming and Directory Interface (JNDI) is an API that provides naming and directory functionality to applications written in Java, and is included in the Java 2 SDK since v1.3.
JNDI enables a Service Provider Interface (SPI) to access remote Java objects (files) and use them. There are 6 popular SPIs - LDAP, DNS, NIS, NDS, RMI, and CORBA. The initial disclosure uses the LDAP (Lightweight Directory Access Protocol) SPI, which is probably why it is currently the most prevalent one we see in scans and exploitation attempts.
Apache Log4j 2 is one of the most common logging services in Java, and supports JNDI since late 2013 (version 2.0-beta9). Last Thursday, on December 9, Chen Zhaojun of Alibaba Cloud Security Team disclosed CVE-2021-44228, and a fix to the Log4j 2 library was made immediately available in version 2.15.0, disabling this behavior by default.
Protect your APIs with Neosec
- Neosec monitors API activity out of band, which ensures an easy set up, minimal friction, and zero impact on your production environment.
- Neosec detection models alert on exploitation attempts as well as behavioral anomalies.
- Covering all your APIs is important for discovering all potentially vulnerable systems.
- Neosec recommends ensuring it processes API activity logs for all externally-facing APIs.
- The Neosec log-based deployment model enables covering all services without implementing any service-specific code.
.png)
