Log4Shell Vulnerability

Summary:

On Dec. 9, 2021, Proof of Concept exploitation code for the remote code execution (RCE) vulnerability (CVE-2021-44228) in Apache Log4j was published to GitHub. Shortly thereafter, there was evidence of widespread exploitation, across the internet.

Apache Log4j is a widely used library, that allows for easy logging of events within Java applications. One commonly used feature is that the library can retrieve information from remote servers and update log messages with said information. An example of this would be converting a User ID number to an actual name within log messages. It’s this feature that led way to the Log4shell vulnerability, as there was inadequate input validation on what remote server URIs were valid. To exploit Log4shell, an attacker only needs to pass a crafted string into a field that ends up being processed by the Log4j library. Given the ease of exploitation and potential impact of successful exploitation, CVE-2021-44228 was given a CVSS score 10.

Response:

Vertek has reviewed its systems and has taken steps to mitigate identified vulnerable assets.  At this time no publicly facing systems are vulnerable to Log4shell, including the Vertek MTI Ticketing & Client Portals.

AT&T Cybersecurity has released a statement that no components of the AlienVault USM Anywhere platform, including sensors, are vulnerable.  By design, AlienVault USM Appliances are not publicly accessible and through Vertek’s testing, do not appear to be vulnerable.

Mitigation:

Due to the extreme risk posed by this vulnerability, Vertek recommends that immediate action be taken, following the guidance published by the vendors of vulnerable applications. Where such guidance is not available, restricting external access to the vulnerable applications is recommended where acceptable.

Additionally, if LDAP is not used by the vulnerable application, restricting outbound access to LDAP ports is a useful temporary stop-gap measure, since most active exploitation at this time is leveraging malicious LDAP connections to attacker owned servers. It should be noted while this mitigation may lower the overall risk, it does not fully mitigate it, as an attacker could host their server on a non-standard port to circumvent this mitigation.

Detection:

Vertek’s Threat Intelligence Team has created custom alarm rules to alert on inbound external traffic, attempting to exploit Log4Shell. Additionally,  AT&T Cybersecurity has published two IDS signatures to detect attempted exploitation.

At this time, Vertek is still working with AT&T Cybersecurity to verify whether the JOVAL and Greenbone vulnerability scanners included in USM Anywhere and USM Appliance can detect Log4shell, additional information will be provided in a future update.

For further guidance, security researchers at Huntress have published an easy-to-use tool that can be used to potentially identify vulnerable systems.  The tool is available on their GitHub but they also have hosted version available here.

Alarm Rule:

Sample Alarm Detection:

Affected Versions:

All versions of Log4j 2.x prior to 2.15.0 are potentially vulnerable, if using a specific JMS Appender and there is evidence that Log4j 1.x be vulnerable as well; although at a much lower risk. The reason being that the JMS Appender in Log4j 1.x only loads strings where the JMS Appender in Log4j 2.x can load serialized objects.

References:

• https://www.blumira.com/cve-2021-44228-log4shell/
• https://nakedsecurity.sophos.com/2021/12/10/log4shell-java-vulnerability-how-to-safeguard-your-servers/
• https://www.binarydefense.com/advice-for-defenders-responding-to-the-log4j-vulnerability-cve-2021-44228/
• https://log4shell.huntress.com/
• https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126