It has been months since we have had the type of security vulnerability that has sent security teams into a panic. Let’s all hope they used that time to get their minds right because CVE-2021-44228 is nasty. This is rated at a 10.0 on CVSSv3, which means the exploitability, impact, and scope metrics are all very high. With this exploit, an attacker can execute arbitrary code on any system that has a bad version of Log4j installed.
As bad as this news is, it gets even worse when you realize what it’s going to take to track down which machines are at risk. This library is used in many Java applications, so the vulnerability could be a part of any internal or 3rd party app and you would have no way of knowing. Tracking this vulnerability down will be a significant undertaking, and we can’t always wait around for your vendors to push out an update.
Is PDQ at risk?
Our Security team gave me this to say:
PDQ Deploy and PDQ inventory don't appear to be affected, but our Security Incident Response Team is evaluating all third-party tools and services for impact.
In non-security speak, that means our product does not contain Log4j in it, but we are making sure we are being very thorough and checking any tools we may use as well. If anything shows up later we will mitigate it ASAP.
Can we track the Log4j vulnerability?
There is not a perfect solution, but with the PowerShell Scanner, we can get a pretty good idea.
The code from a Reddit Thread by u/SSChicken that gave a great starting point. The original code can be put in as a PowerShell Scanner and will return a boolean result if any corrupted files are found. I did like that, but I was curious where the file that is vulnerable might be located, so I modified it slightly to return each file location for each vulnerable file found.
Loading...
To Create the Scanner, open up PDQ Inventory, Select New Scanner > PowerShell
In the Scanner window that opens up, we can either Save the PowerShell below into a ps1 file and link to that or paste the PowerShell right into the script editor.
Edit: We had to modify the script to account for an issue where a scanner not returning data did not clear out old entries, making it so the collections did not update after the found log4j files got removed. To work around this issue, if no files are found, we return a value of "No File". This means we have to change our dynamic collection as well(updated below).
###Get Vulnerable Hashes
$vulnerablesums = -split $(Invoke-WebRequest https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/raw/main/sha256sums.txt -UseBasicParsing).content | Where-Object {$_.length -eq 64}
###Get Hash and file location for each log4j*.jar file
$localsums = get-childitem "C:\log4j*.jar" -file -Recurse | Select-Object Fullname, @{Name = "Hash"; Expression = {(Get-FileHash -Path $_.FullName).Hash}}
###If Log4j*.jar is found compare hash to bad hashes
if(-not($null -eq $localsums)){$BadHash = Compare-Object -ReferenceObject $vulnerablesums -DifferenceObject $localsums.Hash -ExcludeDifferent -IncludeEqual -ErrorAction SilentlyContinue}
###Return FileLocation and hash for each vulnerable result
foreach($Entry in $localsums){
if($BadHash.InputObject -contains $Entry.Hash){
$result += $Entry
}
}
if($null -eq $result){
[pscustomobject]@{
FullName = "No File"
Hash = " "
}
}Else{
[pscustomObject]$result
}Give it a name and select OK.
This scanner will be looking at some system files, so change the Scan As from Scan User to Local System and select OK.
Since this scanner is looking at your entire C drive for a specific file name it can take a long time to finish scanning. In a lab against 52 machines that do not have very large drives, it took a little under 10 minutes to complete. Larger environments could be looking at an even longer time, so you may need to break up your scan groups if you are timing out from this scan. It is worth noting that the default timeout per computer is 10 minutes, so if your larger machines are taking longer than this and you want to make sure they get scanned, you can increase the timeout in Preferences > Performance.
Now that we have completed a scan, let’s check what the results look like and how we can build a collection to track machines that are at risk. It turns out our lab was not vulnerable, which is great for security, but terrible for showcasing, so we manually downloaded 2.12.1 so we can show some results.
Seen below, it found two files that are a problem. Hopefully this will help us track down what application may be using these .jar files, and we can either work on upgrading to 2.15.0 so we can continue using these safely, or we can remove the offending software if it is no longer needed.
To generate a Collection of all found at-risk machines, we are going to build a new Dynamic Collection and look for anything under FullName of the New Scanner Table for any entry not titled “No File”. Select the name of your scanner from the filter dropdown.
If the scanner fails to find a file it adds this as the FullName entry, this allows us to show only machines where a file was found.
Conclusion
Log4j is a very serious vulnerability. It is remotely executable, easy to exploit, and not easy to determine if you are vulnerable. This scanner is a helpful tool that can find several of the offending files, but I can’t guarantee that it will find everything. I would use this to try and track down some computers that are at risk but make sure you install any software updates that come through. This upcoming Patch Tuesday may just be a busy one.
