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