Compilation of log4j OSINT findings, including Detection, Attack Surface, Mitigation, IoCs.
-
This vulnerability makes it possible for any attacker who can inject text into log messages or log message parameters into server logs to load code from a remote server. The targeted server then executes that code via calls to the Java Naming and Directory INterface (JNDI).
-
JNDI interfaces with a number of network services:
- Lightweight Directory Access Protocol (LDAP) - default port 389
- Secure LDAP (LDAPS) - default port 636
- Domain Name Service - default port 53
- Java's Remote Interface (RMI) - default port 1099
- Common Object Request Broker (CORBA)
-
As of 13.12.2021, the attacks so far were either cryptominers and automated botnets (Mirai, Tsunami and Kinsing)
-
Best fix is to upgrade to the patched version, but the challenge is to find where log4j was deployed as a component &/or wait for vendor to patch.
-
Short term:
- Good: block outbound LDAP & RMI ports
- Better: block outbound LDAP & RMI protocols (regardless of port)
- Best: block all outbound traffic
-
Long term:
- Identify and update instances of Log4J or mitigating the issue by changing settings in Log4J, (either through XML or YAML configuration files in the root of Log4J’s path settings, or programmatically). That may require code changes in products where Log4J is embedded.
- Apache Log4j v2.0 -> v2.14.1
- Anyone using Apache Struts framework is likely vulnerable
https://www.govcert.admin.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ - by @TychoTithonus (Royce Williams).
A compilation of exploit examples. https://github.com/YfryTchsGD/Log4jAttackSurface
Resources by Florian Roth (comment section also contains usefull info) https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
https://github.com/Neo23x0/log4shell-detector
/.({|%7B)[Jj][Nn][Dd][Ii]./
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
https://twitter.com/ThinkstCanary/status/1469439743905697797 You can use a point & click canarytoken from https://canarytokens.org to help test for the #log4j / #Log4Shell issue.
- visit https://canarytokens.org;
- choose the Log4shell token;
- enter the email address you wish to be notified at;
- copy/use the returned string...
- Generate a DNS token https://canarytokens.org/generate#
- Wrap that token in Prefix: ${jndi:ldap:// Suffix: /a}
- Use that value in search forms, profile data, settings etc. of your apps
- Get notified when you triggered a reaction
Details on their page https://log4shell.huntress.com/
https://twitter.com/ET_Labs/status/1469339963871354884
"How to detect if affected: Start netcat parallel to your app: "nc -lp 1234", then type the following into app where it gets logged (e.g. the query string of your search): "${jndi:ldap://127.0.0.1:1234/abc}" If you then see garbage/emojis in the netcat console your're vulnerable!"
- Upgrade log4j versions to log4j-2.15.0-rc1
- URL: https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/
- Release notes: https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0
- Announcement: https://logging.apache.org/log4j/2.x/security.html
- Users should switch log4j2.formatMsgNoLookups to true by adding:"‐Dlog4j2.formatMsgNoLookups=True" to the JVM command for starting the application
- Disabling lookups at the command line is partial mitigation in some of these cases (doesn't require vendor action, but may screw up the app's logging if it actually uses the feature -- and of course, requires local admins to control the command line).
"I've written a simple (i.e. standalone, no dependencies) Java program which patches JndiLookup.lookup() to return a fixed string and not parse its arguments. This should fix CVE-2021-44228 (i.e. RCE in Log4j) without restarting your JVM process." https://github.com/simonis/Log4jPatch "This is a POC of a simple tool which injects a Java agent into a running JVM process. The agent will patch the lookup() method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string "Patched JndiLookup::lookup()". This should fix the CVE-2021-44228 remote code execution vulnerability in Log4j without restarting the Java process. This has been currently only tested with JDK 8 & 11!"
https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217
Source: Greynose.io
https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
Community API https://docs.greynoise.io/reference/get_v3-community-ip
API call: curl -X POST https://threatfox-api.abuse[.]ch/api/v1/ -d '{ "query": "taginfo", "tag": "log4j" }
URL: https://threatfox.abuse.ch/browse/tag/log4j/
https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8
"Please find the following raw CVE-2021-44228 Log4J / Logshell payloads GreyNoise has detected thus far." https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890
More payloads https://gist.github.com/yt0ng/8a87f4328c8c6cde327406ef11e68726
https://twitter.com/GreyNoiseIO/with_replies
"Seeing 45[.]155[.]205[.]233 do the initial scan with an base64 encoded string. When decoded tries to do a curl wget bash etc....to setup a shell. Stage 2,3 and 4 also seen with final payloads: nspps/Kingsing malware via following ip's 44.240.146.137 45.137.155.55 185.154.53.140 185.191.32.198"
45.155.205.233 - Russian IP seen exploiting. https://twitter.com/VessOnSecurity/status/1469950517010968582 https://twitter.com/entropyqueen_/status/1469961345848299520