Sunday, December 12, 2021

Log4j, Log4Shell or LogJam CVE- 2021-44228 RCE

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.



Issue Found on update

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
 


And another issue discovered: Web infrastructure company Cloudflare on Wednesday revealed that threat actors are actively attempting to exploit a second bug disclosed in the widely used Log4j logging utility, making it imperative that customers move quickly to install the latest version as a barrage of attacks continues to pummel unpatched systems with a variety of malware.

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.

More Details Here:
https://thehackernews.com/2021/12/hackers-begin-exploiting-second-log4j.html

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/log

This 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

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Syslog/Apache_log4j_Vulnerability.yaml

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

PoC:  https://t.co/yShp4iRTxJ

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/


Fortinet  detection solution https://community.fortinet.com/t5/FortiAnalyzer/Technical-Tip-Using-FortiAnalyzer-to-detect-activities-related/ta-p/201026


Try hackme box for practice : https://tryhackme.com/room/solar


Happy Hunting.



4 comments:

Hey, it would be nice if you´re making a Hyperlink to Emys Tweet to make it more obvious and easier to find her. In the Tweet from her where some People confused who wrote the Text. But that said thanks for the Explenation for detecting log4j.^^

Thanks updated the post with link from twitter where the info were collected mainly.

Thanks for your fast response.^^

Microsoft Sentinel queries
Microsoft Sentinel customers can use the following detection queries to look for this activity:

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.

Azure WAF Log4j CVE-2021-44228 hunting
This hunting query looks in Azure Web Application Firewall data to find possible exploitation attempts for CVE-2021-44228 involving Log4j vulnerability.

Log4j vulnerability exploit aka Log4Shell IP IOC
This hunting query identifies a match across various data feeds for IP IOCs related to the Log4j exploit described in CVE-2021-44228.

Suspicious shell script detected
This hunting query helps detect post-compromise suspicious shell scripts that attackers use for downloading and executing malicious files. This technique is often used by attackers and was recently used to exploit the vulnerability in Log4j component of Apache to evade detection and stay persistent or for more exploitation in the network.

Azure WAF matching for CVE-2021-44228 Log4j vulnerability
This query alerts on a positive pattern match by Azure WAF for CVE-2021-44228 Log4j exploitation attempt. If possible, it then decodes the malicious command for further analysis.

Suspicious Base64 download activity detected
This hunting query helps detect suspicious encoded Base64 obfuscated scripts that attackers use to encode payloads for downloading and executing malicious files. This technique is often used by attackers and was recently used to the Log4j vulnerability in order to evade detection and stay persistent in the network.

Linux security-related process termination activity detected
This query alerts on attempts to terminate processes related to security monitoring. Attackers often try to terminate such processes post-compromise as seen recently to exploit the CVE-2021-44228 vulnerability.

Vulnerable machines related to Log4j CVE-2021-44228
This query uses the Azure Defender Security Nested Recommendations data to find machines vulnerable to Log4j CVE-2021-44228.

Suspicious manipulation of firewall detected via Syslog data
This query uses syslog data to alert on any suspicious manipulation of firewall to evade defenses. Attackers often perform such operations as seen recently to exploit the CVE-2021-44228 vulnerability for C2 communications or exfiltration.

User agent search for Log4j exploitation attempt
This query uses various log sources having user agent data to look for CVE-2021-44228 exploitation attempt based on user agent pattern.

Network connections to LDAP port for CVE-2021-44228 vulnerability
This hunting query looks for connection to LDAP port to find possible exploitation attempts for CVE-2021-44228.

Linux toolkit detected
This query uses syslog data to alert on any attack toolkits associated with massive scanning or exploitation attempts against a known vulnerability

Post a Comment

Twitter Facebook Favorites More