Update: ExtraHop has added firmware updates and three new detectors designed to rapidly identify post-compromise behavior associated with exploitation of this vulnerability. See the details.
A zero-day vulnerability referred to as Log4Shell in the commonly used Java-based Apache utility Log4j (CVE-2021-44228) has been disclosed. An attacker using a Log4j exploit can remotely execute code that, once deployed, can grant the attacker full server control, making the flaw a critical and widespread cybersecurity threat. Proof-of-concept Log4j exploit examples are currently available, and attackers are actively targeting vulnerable systems.
The flaw allows an attacker to exploit the Java Naming and Directory Interface (JNDI) API to cause Log4j to execute arbitrary malicious code delivered by the attacker. Current analysis suggests it's delivered via LDAP or RMI, to a remote server that then redirects JNDI to reach out to another server, using HTTPS or another protocol. An emergency patch has been released by Apache. Because Log4j is ubiquitous in commonly used Java apps such as Jira, iCloud, and Minecraft, many users have the software deployed and are unaware that it is running in their environment.
While the total impact of affected applications and devices is not yet known, further proofs-of-concept indicate that attackers may be able to target hardware, such as servers, laptops, mobile, and IoT devices, in addition to cloud-based services and apps, deepening the potential risk. Reports quickly surfaced of observed scanning behavior:
@GreyNoise is currently seeing 2 unique IP's scanning the internet for the new Apache Log4j RCE vulnerability (No CVE assigned yet).— remy🐀 (@_mattata) December 10, 2021
A tag to track this activity on https://t.co/QckU3An40q will be made available shortly and linked as a reply when released.
Remediation and Detection
Log4j exploits use alternate ports, evasion encoding, and TOR to hide identifying details. Immediate updates of software containing the Log4j utility are recommended, however, due to complex supply chain dependencies, vulnerable users are dependent on suppliers to patch systems and release the necessary updates. Unfortunately, many users lack awareness of which applications are vulnerable.
Understanding that baseline behavior for affected applications can help organizations identify indicators of compromise associated with this flaw, which is where machine-learning-based detections from a network detection and response solution can assist.
Addressing Log4j with ExtraHop Reveal(x) 360
ExtraHop has released a threat briefing and a new detector in Reveal(x) and Reveal(x) 360 for activity associated with Log4j exploitation. This detector fires an Unusual Executable File Download alert when an attempt to download a
.class file is made.
Reveal(x) Enterprise customers (with cloud connectivity) and all Reveal(x) 360 customers will automatically receive this detector, in addition to updated firmware. Customers can get detailed information about updates by visiting our forum, or if you're currently logged into Reveal(x), you can jump directly to the threat briefing by entering your Reveal(x) domain below:
Reveal(x) transaction records can be searched for JNDI calls, which can provide a starting point for investigating potential exploit attempts. If new JNDI calls are observed to external endpoints, the external IPs should be blocked immediately. If using JNDI calls is an expected behavior, then further investigation may be required to identify whether the activity is malicious or benign. The ExtraHop Threat Research team is closely monitoring for new PoCs, and will provide updates as more information becomes available.
The ExtraHop team has also observed attack attempts using encrypted protocols, such as HTTPS on port 443. In these cases, the telltale JNDI calls may not be visible unless the traffic is being decrypted. Reveal(x) users who have enabled decryption of traffic from the devices that are under attack will still be able to see the JNDI requests that indicate an exploit attempt.
Cryptomining Attacks Using Log4Shell
Researchers have observed attackers using the vulnerability to install cryptomining malware on exposed systems. It's further evidence of this vulnerability's ease of exploitation. Reveal(x) includes both a classifier and a detector for the cryptomining protocol Stratum, alerting security teams to malicious activity. ExtraHop has seen a number of actors using the Stratum protocol to deploy XMRig, which can be used to hijack a user's machine to mine cryptocurrency.
The implications of Log4Shell are severe and widespread. It is not a supply chain attack, like SUNBURST, in which a series of exploits were introduced by malicious actors. Instead, it is a serious security flaw in a ubiquitous piece of software. Moreover, because this vulnerability is not only difficult to patch but also easy to exploit, looking for indications of compromise is simply not enough. There is a high likelihood that many attacks have already moved past the compromise stage and are engaged in post-compromise behavior. While organizations should continue to be vigilant for signs of initial compromise, actively hunting post-compromise activity should be considered necessary for responding to this CVE.
December 14, 2021 Updates
A bypass was discovered in Apache's initial patch for CVE 2021-4428, which may allow attackers to carry out a DOS attack by adding malicious input data through a JNDI lookup pattern.
ExtraHop expects additional CVEs may be discovered in the coming days and will continue to provide updates to support detection and remediation.
Additional Log4Shell Detectors: Three new detectors, along with an updated threat briefing, are now available to Reveal(x) 360 and Reveal(x) Enterprise users (with cloud connection) to help detect Log4j attacks. While the detections are available in previous versions of Reveal(x), the upcoming release of Reveal(x) 8.7 improves the workflows of the new Log4Shell detectors.
- External LDAP Connection Detector: Similar to the other External [NFS|DB] Connection Detectors, this detection identifies LDAP connections made to an external server
- Incoming Malicious JNDI strings Detector: Added to the Log4Shell JNDI Injection Attempt detection, this detection identifies attempts to inject
- Log4Shell Activity: Added to the Outbound Log4shell Activity detection, this detector looks for outgoing requests for malicious content by identifying outbound activity seen by the Injection Attempt detector
Firmware Updates: ExtraHop has released firmware versions 8.5.4 and 8.6.5, and is scheduled to release version 8.7 later this week as part of our quarterly updates. All releases improve users' ability to detect Log4Shell exploit attempts by:
- Adding LDAP traffic classification to all ports, which enables external LDAP connections
- Adding IIOP and Java RMI traffic classification, which helps identify Log4Shell over these protocols
- Adding Request to External LDAP Server detection, which identifies LDAP connections made to an external server