Security researchers recently disclosed the vulnerability CVE-2021-44228 in Apache’s log4j, which is a common Java-based library used for logging purposes. Popular projects, such as Struts2, Kafka, and Solr make use of log4j. The vulnerability was announced on Twitter, with a link to a github commit which shows the issue being fixed.
Before jumping into vulnerability management and threat detection, we want to assure customers that Sysdig software components and back-end data systems are not impacted.
If your environment is running Kubernetes, see Mitigating log4j with Runtime-based Kubernetes Network Policies.
Proof-of-concept code was also released to github which shows that the vulnerability is trivial to exploit.
The vulnerability only requires an attacker to send a specially crafted string to the logging functions. Specifically, the vulnerability is in the Java Naming and Directory Interface (JNDI) support of LDAP.
If the malicious string contains instructions to use LDAP, the server will attempt to contact the specified LDAP server and load the specified Java resource. This server and resource can be compromised and result in remote code execution on the server.
Affected Versions
In particular, CVE-2021-44228 affects vulnerable versions: 2.0-beta9 to 2.14.1
After the 2.15.0 version has been released to fix the vulnerability, the new CVE-2021-45046 has been released. The new vulnerability hits the new version and permits a DoS attack due to the incompleteness of the previous patch. The severity upgraded 3.7 to 9.0 HIGH.
UPDATE: Fix version: 2.17.0.
After the 2.16.0 version has been released to fix the vulnerability CVE 2021-45046, the new CVE 2021-45105 has been released. The new vulnerability hits the new version and permits a DoS attack due to the incompleteness of the previous patch.
For more details, see the Apache security announcement. The code fix for log4j can be seen on the Apache github.
Vulnerability Management
In Sysdig Secure, a report can be run detailing all of the container images in your registries or runtime environment which are using a vulnerable version log4j.
To quickly do this, first make sure an admin user enables “Scheduled Reports” under Sysdig Labs – see below
Then, go to Scanning -> Scheduled reports -> Add Report then go to the Data tab. Then input your repositories, and add a new condition: Vulnerability ID. For the Vulnerability ID field use “VULNDB-275958” which maps to CVE-2021-44228.
The preview button will only return a few rows, so the report should be scheduled on the Configuration tab. Once run, the report will give you a list of all affected images and vulnerability remediation efforts can begin.
As a best practice we advise scanning images pre-deploying them as part of your CI/CD. Using Sysdig’s scanning policies you can detect a vulnerable image or block its deployment.
Threat Detection
Using Falco runtime detection, exploitation can be detected through anomalous behaviour coming from containers. This can include unexpected connections to remote servers over the LDAP port (389). However, the attacker can change the port used so any unusual outgoing network traffic should be investigated.
It is also possible to see attempts to exploit this vulnerability in log files by using simple tools like grep or creating correlation rules in your SIEM. Effectiveness will depend on the verbosity of the logs being stored. For example:
sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log
Credit goes to Florian Roth. More detection examples can be found here.
Conclusion
This is a very dangerous vulnerability due to the widespread use of log4j and the ease of exploitation. We strongly recommend upgrading to the latest version of log4j (2.17.0 at the time of this writing) as soon as possible.
If possible, mitigate by following instructions provided by apache or ensuring attacker controlled data cannot be passed to the logging functions.