On December 28, 2021, Apache disclosed a new vulnerability (CVE-2021-44832). This is a medium severity vulnerability (CVSS score: 6.6) that allows for remote code execution (RCE) in Apache Log4j2 versions 2.0-beta7 through 2.17.0, excluding security fix releases 2.3.2 and 2.12.4. Apache released Log4j2 versions 2.17.1, 2.12.4, and 2.3.2 to patch the vulnerability and resolve the issue.
For the latest information on how to update your Forescout products, please refer to KB Article #12049 on our portal.
For more information: Apache CVE: CVE-2021-44832
On December 9, 2021, Apache published a zero-day vulnerability (CVE-2021-44228) for Apache Log4j being referred to as “Log4Shell”. This “critical” vulnerability (CVSS score: 10) allows a remote attacker to take control of an affected system. When exploited, this vulnerability allows an attacker to run arbitrary code on the device, giving full control over to the attacker. Any device exploited should be considered compromised, potentially along with any devices that trusted the compromised device. The vulnerability has been actively exploited.
On December 14, 2021, Apache confirmed another vulnerability that was identified impacting Apache Log4j utility (CVE-2021-45046). According to reports, this flaw (CVSS score: 9) could result in remote code execution, which stemmed from an “incomplete” fix for CVE-2021-44228.
Vulnerability CVE-2021-45046 has been actively exploited.
On December 18, 2021, a third vulnerability was identified. Tracked as CVE-2021-45105 (CVSS score: 7.5), the high severity Denial of Service (DoS) vulnerability affects all versions of the tool from 2.0-beta9 to 2.16.0.
Forescout has identified the affected components and is in the process of updating its systems and products. Forescout’s security team immediately commenced an investigation of its networks and has found no evidence of compromise at this time and has updated rules and signatures of Forescout’s security solutions to detect and block any attempt to exploit our platforms and keep our defenders on high alert.
Why are these Vulnerabilities Challenging?
Log4j is a logging library present in many Java applications and the vulnerability is a consequence of how Log4j processes log messages.
It allows the use of “lookup” features, where the user providing data to be logged can specify where the content of the data comes from. Instead of a simple string, for instance, it can be a call to a remote server. That allows attackers to inject calls to malicious servers that hosts malware or an instruction to leak sensitive information (such as access tokens) to attacker-controlled servers.
These remote calls are enabled by a Java feature called Java Naming and Directory Interface (JNDI), which supports protocols such as the Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS), Remote Method Invocation (RMI), and Common Object Request Broker Architecture (CORBA). Technically, an exploit is a string of the form ${jndi::} that must be injected by an attacker into a vulnerable log4j instance.
Many Internet-facing machines, such as web servers, accept user input that is logged by a backend running Log4j without sanitization. That happens often even if the webserver itself does not run Log4j, but some business application uses information coming from the user via the webserver. This allows attackers to inject the malicious strings via HTTP requests, for instance, which is the biggest attack surface observed so far.
There are two complicating factors for this vulnerability. First, Log4j is not a single vulnerable application but a widely-used component, present in products ranging from databases to web conferencing systems. Therefore, identifying vulnerable assets in a network is challenging. Second, attackers have quickly found many ways to obfuscate exploits, so that understanding if and how your organization is or was attacked is not easy. For instance, one valid exploit is ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://} which is not easy to immediately match to the ${jndi::} template we mentioned above.
Protecting Your Network – Mitigations
Identify Vulnerable Devices
Vulnerable software/devices can be identified by:
- Matching asset inventories with vendor advisories.
- Analyzing software bill of materials (SBOM) manifests – which are still very rare – or software build pipeline dependency manifests – which are common in environments such as Maven – to identify the use of the vulnerable component.
- Searching the file systems of machines to identify class files, especially the JndiLookup.class which is used to access the remote services.
- Analyzing log files to identify entries coming from log4j and map them back to applications.
Patch or Change Configurations
After vulnerable devices have been identified, Forescout recommends applying the latest security updates from Apache. Apache has released a new version of Log4j, version 2.17.0, to address the vulnerabilities.
- Apache CVE: CVE-2021-44228
- Apache security advisory: Apache Log4j Security Vulnerabilities
Mitigation Risk on the Network:
If sensitive devices are identified that cannot be immediately patched (e.g., a patch is not available), Forescout recommends mitigating the risk as follows.
- Use application tagging to identify those applications which you haven’t validated as patched and apply strict policies to them.
- Configure a firewall to allow outgoing traffic to a trusted whitelist of addresses and protocols, thus preventing attackers from communicating outside of the network.
- Carefully monitor for failed logins and token anomalies.
- Detect exploitation attempts by inspecting log files for the characteristic URL patterns. As mentioned above, attackers are currently using obfuscating techniques to avoid detection. A non-exhaustive list of exploit patternsthat might help with detection includes:
- ${jndi:ldap://}
- ${jndi:ldaps://}
- ${jndi:rmi://}
- ${${::-j}ndi:rmi://}
- ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://}
- ${${lower:jndi}:${lower:rmi}://}
- ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://}
- ${jndi:dns://}
Investigate Targeted Devices
If a device was the target of an exploit found by monitoring the network as described above, you can further investigate the incident by checking the logs for strings starting with “${jndi” or any of the exploit patterns above (there are grep regular expressions to help with that).
Once you have determined the device was actually compromised, proper containment, eradication and recovery processes should be taken, which include disconnecting the device, removing malware or malicious artifacts that have been dropped and determining when the system can be returned to production.
How Forescout Can Help Mitigate Log4shell
Forescout R&D Teams have developed the following artifacts to help mitigate Log4Shell:
Assess Your Risk: Finding Vulnerable Devices
eyeSight customers can install the Security Policy Templates (SPT) plugin version 21.0.11. The SPT allows to scan Windows and Linux hosts to identify which of those run applications that use the vulnerable Log4j library.
The SPT enumerates all Java Archive (JAR) files – packaged Java applications and libraries – on a scanned host and searches for the JndiLookup class on the found JAR files. When the class is found, it searches for version information available on build manifests (e.g., Maven properties.pom), file names (e.g., log4j-core-2.1.10), file hashes or even timestamps to try to determine whether the application is vulnerable or not.
Scanned hosts are grouped into Vulnerable, Potentially Vulnerable, Not Affected and Unknown.
We also intend future versions of the SPT to further help with forensic capabilities by scanning known log files for exploit patterns. Notice this will not be part of the first SPT release.
It is paramount to identify vulnerable and violated hosts. eyeInspect customers can leverage the richness of data collected and the analytical capabilities of the tool to investigate the network behaviors. Special attention should be given to egress traffic related to protocols like LDAP, DNS, and RMI. It is possible to build easily multiple analytical dashboards to assess the traffic and device behaviors.
These powerful logging and analysis capabilities are precious also to identify exploits happened while there was no threat detection: with eyeInspect it is easy to identify hosts that started using uncommon protocols or with suspicious behaviors, e.g. a node which started communicating yesterday through LDAP with an unknown server on the Internet.
Identify Attacks: Detecting Ongoing Exploits
eyeInspect customers can update their Threat Detection Add-Ons script to version v.1.6 containing a detection strategy for CVE-2021-44228 exploitation attempts on HTTP. This is supported from eyeInspect 4.2.0 onwards.
Figure 1 shows an example of an alert raised when an exploit is detected.
There is also a flash update of the OT Vulnerability & IoC Database to help detection of IoCs related to CVE-2021-44228. Some Log4Shell callbacks are reported to run over Tor; eyeInspect has a large list of Tor exit node IP addresses (6700, very recently updated). This update adds additional IP addresses reported as malicious on various sources and this list could have updates in the next days.
These Add-On tools will help you detect exploit attempts of the log4j vulnerability and identify indicators of already infected systems attempting to reach out to malicious IP addresses identified by various threat intel sources.
Figure 1: Example of alerts in case of exploitation attempts.
Protect Your Organization: Segmenting the Network
eyeSegment customers can setup their systems to whitelist LDAP, DNS, and RMI traffic, which are being exploited in the wild, to only legitimate servers.
eyeSight can also help to isolate devices that are known to be vulnerable but cannot be patched by placing them in specific VLANs.
While it’s not possible to block OT networks in general, customers could set rules in the eyeInspect anomaly detection engine to raise alerts if LDAP, RMI or other sensitive protocols are used against non whitelisted destinations.
