Focus: Checking for LOG4J vulnerability

Important upddate 15/12-2021: Please be aware that the recent fix/patch for log4j was incomplete and did not fully mitigate the vulnerability. A new CVE has been released: https://www.cve.org/CVERecord?id=CVE-2021-45046


This has been a busy weekend with the zero-day vulnerability in Apache Log4j logging framework. It has been compared to the Heartbleed exploit and some refer to it as one of the most serious exploits in 10 years.

You can find a ton of articles describing both impact and cause so I’ll skip straight to what was important to me; Finding out if my servers were affected.

The first thing I wanted to check was if anyone had tried to exploit this vulnerability on my Linux server. You can run through all you log files and check for this pattern:

egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log

If you get some results like this you should check if the logs belong to a system using log4j framework

Update 14/12-2021: This cross platform tool was recommended to me as it can both search for vulnerable files and patch/fix them: https://github.com/logpresso/CVE-2021-44228-Scanner

If you want to search manually you can use this useful Linux onliner I found is this ‘find’ command that will search for all your .jar files and check if they are using the log4j framework:

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"

It might take a while for the search to complete but if you get results you should make sure to replace this with a patched version.

If you are running Windows Server you can search for similar files using PowerShell

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

There are currently 16.000+ systems identified using log4j, you can find the list here: https://mvnrepository.com/artifact/log4j/log4j/usages

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.