Our Vision

To give customers the most compelling IT Support experience possible.

Our Mission

Our mission is simple: make technology an asset for your business not a problem.

Our Values

We strive to make technology integrate seamlessly with your business so your business can grow. As your technology partner, when your business grows ours will grow with you, therefore, we will work hand in hand with you to support your growth.

Our Values

We develop relationship that makes a positive difference in our customers Business.

Our Values

We exibit a strong will to win in the marketplace and in every aspect of our Business

Showing posts with label Log4j. Show all posts
Showing posts with label Log4j. Show all posts

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.



Twitter Facebook Favorites More