Explaining #log4j for non-technical people, because the internet is burning down and y'all might want to know what's happening and why there's all this "${jndi:ldap" stuff out there.
Log4j is a popular logging library used in Java programming language. A logger is a piece of software that saves data on a computer. It is used to monitor what is happening, determine if the software runs smoothly, or catch information to help debugging when things go wrong.
It logs a lot of information. When you browse to a website, it will write down what IP address you have, what browser you are using (firefox, chrome, edge... ), when you made the request, what page you accessed... and more!
So, this log4j library is used in A LOT of Java software, and there is approximately 3 billion devices that run Java. Quick math: that's huge.
Log4j is present in web servers, your phones, possibly on your smart fridge and plenty of other places...
A logger is supposed to just write down what happens to a hard drive, or send it to another server to store it. But in the case of log4j, there are a few things that are performed before writing anything. One of the things it does is look for patterns like ${something} and will try to replace it with another piece of information. It is used to add context, for example, ${date} would be replaced by today's date.(I have no idea if this example works, it's just to keep it simple)
So when there's a ${jndi: pattern, it will try to replace it.
Except that this pattern triggers another mechanism that loads a resource from another computer, anywhere on the internet, we just have to tell it where to get the data from. This data can be a malicious software.
Due to some internal Java mechanism, this malicious software is automatically run on the computer that used log4j. This means that at this point hackers can make the targeted computer do (almost) whatever they want. This gets really bad because we don't need to know which computer to target.
Remember when I said the web servers logs what browser you use? Well, we can just tell it that our browser is "${jndi: [...]", and if it uses log4j it will trigger the vulnerability.
In real life that would be the same as giving the keys to your house to a random stranger you just saw pass in front of you, without even realizing it. So... yeah. #log4j the above simple explanation by Emy| eq in tweeter entropyquween_
So this is big and affected a lot of companies with servers confirmed to be vulnerable to Log4Shell attacks include the likes of Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase, and possibly thousands more.
Apache has released Log4j 2.15.0 to address the maximum severity CVE- 2021-44228 RCE vulnerability. https://t.co/PzSkXJUxEi
Workaround so far: Upgrade log4j or if you cannot upgrade then you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
Note that this workaround only works for log4j2 version 2.10...2.15. If companies have an older library version of log4j2 (note that having an older version inside .jar archive does count) this workaround is not safe to use.
Mitigation for previous releases (>=2.10): set system property "log4j2.formatMsgNoLookups" to "true" or remove the JndiLookup class from the classpath.
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. https://www.cve.org/CVERecord?id=CVE-2021-45046 |
The new vulnerability, assigned the identifier CVE-2021-45046, makes it possible for adversaries to carry out denial-of-service (DoS) attacks and follows disclosure from the Apache Software Foundation (ASF) that the original fix for the remote code execution bug — CVE-2021-44228 aka Log4Shell — was "incomplete in certain non-default configurations." The issue has since been addressed in Log4j version 2.16.0.
Detection:
A. Test and detect vulnerable applications. by John Hammond
https://log4shell.huntress.com/
The explain-like-I'm-five breakdown is that you simply copy and paste the generated JNDI syntax into _anything_ (typically form fields, application input boxes, logins, anything) and check if it received a connection. NO code is ran on other than making this connection to test.
B. How to test your apps for #log4shell vulnerability
1. Generate a DNS token https://t.co/vCzVG0O03i
2. Wrap that token in
Prefix: ${jndi:ldap://
Suffix: /a}
3. Use that value in search forms, profile data, settings etc. of your apps
4. Get notified when you triggered a reaction https://t.co/1w6jmF9qgy
C. I know that using regex is dumb and shit, but it's just first-line defense. This one I is capable to detect obfuscated payloads and should produce very few false positives:
\${(\${(.*?:|.*?:.*?:-)('|"|`)*(?1)}*|[jndi:(ldap|rm)]('|"|`)*}*){9,10}
D. If you are looking for Vulnerable Software on Linux, Docker Container, Kubernetes Pods the following command may help you.
find -name "*.jar" -exec sh -c 'unzip -l "{}" | grep -i --color=always JndiLookup.class' ; -print
find -name ".jar" -exec sh -c 'unzip -l "{}" | grep -i --color=always log4j-core-2..jar' ; -print
E. A quick and dirty way by Jay Minton you can find his other awesome work here https://www.jaiminton.com/#
To find jar files that have a JndiLookup.class in PowerShell (change drive).
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path
Running the following in PowerShell as Admin on Windows should mitigate the issue for any instances >=2.10
[Environment]::SetEnvironmentVariable("LOG4J_FORMAT_MSG_NO_LOOKUPS","true","Machine")
For forensic examiners, it's not known how practical exploitation is, but both Cellebrite BlackLight and Autopsy use components that leverage the vulnerable log4j class.
Elasticsearch for BlackLight (possibly inspector also), and Apache Solr for Autopsy keyword searching.
F. You can use these commands and rules to search for exploitation attempts against log4j RCE vulnerability CVE-2021-44228
Grep / Zgrep
This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders
sudo egrep -I -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/logThis command searches for exploitation attempts in compressed files in folder /var/log and all sub folders
sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+'Grep / Zgrep - Obfuscated Variants
These commands cover even the obfuscated variants but lack the file name in a match.
This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders
sudo find /var/log/ -type f -exec sh -c "cat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -I -i 'jndi:(ldap[s]?|rmi|dns):'" \;This command searches for exploitation attempts in compressed files in folder /var/log and all sub folders
sudo find /var/log/ -name "*.log.gz" -type f -exec sh -c "zcat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'" \;Guidance from Microsoft: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
Microsoft Sentinel queries Possible exploitation of Apache log4j component detected
This hunting query looks for possible attempts to exploit a remote code execution vulnerability in the Log4j component of Apache. Attackers may attempt to launch arbitrary code by passing specific commands to a server, which are then logged and executed by the Log4j component.
Cryptocurrency miners EXECVE : This query hunts through EXECVE Syslog data generated by AUOMS to find instances of cryptocurrency miners being downloaded. It returns a table of suspicious command lines.
Microsoft Sentinel also provides a CVE-2021-44228 Log4Shell Research Lab Environment for testing the vulnerability: https://github.com/OTRF/Microsoft-Sentinel2Go/tree/master/grocery-list/Linux/demos/CVE-2021-44228-Log4Shell
CURATED Intel: IOC and report https://github.com/curated-intel/Log4Shell-IOCs
https://crowdsec.net/log4j-tracker/
Other info:
This repo seems to have a good few high traffic sites being vulnerable for CVE- 2021-44228 https://github.com/YfryTchsGD/Log4jAttackSurface
Customers can run commands and rules to search for exploitation attempts against log4j RCE vulnerability CVE- 2021-44228 can be found here https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Patch: https://t.co/rVSq2EZfoT
Technical breakdown: https://t.co/QWRkh6rk4y
Crowdstrike blog https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/
And more
https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217
https://gist.github.com/yt0ng/8a87f4328c8c6cde327406ef11e68726
https://urlhaus.abuse.ch/browse/tag/log4j/
