Log4Shell

Same

https://www.pdq.com/blog/log4j-vulnerability-cve-2021-44228/

In my case I cannot create a dynamic collection, does anyone know why?

That means the PowerShell Scanner hasn't returned anything. It either didn't find anything, or you haven't run it yet. Collections can't be created until at least 1 target returns data.

I understand, thanks.

Using the PowerShell script from the PDQ blog post I'm getting an access denied on my Dutch language installs even though I'm executing as Local System:

[14/12/2021 9:54:25] ERROR: Toegang geweigerd (access denied)
At line:4 char:14

Line 4, char 14 is this:

get-childitem "C:\log4j*.jar" -file -Recurse | Select-Object Fullname, @{Name = "Hash"; Expression = {(Get-FileHash -Path $_.FullName).Hash}}

When I run just the get-childitem "C:\log4j*.jar" -file -Recurse command as a seperate Scanner, it returns nothing even though I have a log4j.test.jar file in C:\ subfolder.

Does anyone know of a way to run the script that was provided in the blog WITHOUT using the github we call.  I was able to access the site manually and download the text into a text document, but I dont think my firewall is letting PDQ go out to github, so looking for a way to run it so it looks at the hashes on my file server instead.

I had a similar problem with my Proxy, so I downloaded the text file and hosted it in an internal ISS and pointed in the script to the to the text file.

MP82, I think there is a typo in the get-childitem command. 

"C:\log4j*.jar"

would only look for that file in the root of C:\

I think a better command would be:

get-childitem -path "c:\" -filter "log4j*.jar" -file -recurse | <rest of command here>

Or am I the only one that thinks the original is a typo? 

jordan.hammond are you the author?  Can you help verify please?

So I was able to get it pull the hashes locally by changing the first line to

Ray Holtz, You are correct that your version is best practice. I updated the blog with that change to the code, as well as a section about the collection when no file is found from earlier in this thread. The process for the blog to show the update is a bit inconsistent, but the changes should show soon.

Where and what version would you recommend we download for the test like you did.

I downloaded 2.12.1 from here https://downloads.apache.org/logging/log4j/

jordan.hammond thanks for the updates. PDQ Inventory wasn't flagging a system I tested it with earlier, it does on another one.

Is there a way to automate this script to scan all drives on a system?

MP82 I had false negatives as well, I think the reliance on the hash table is where I ran into issues. Some of my 2.11s and 2.9s didn't match the hash table, but were still vulnerable. I ended up with a file monitor and just combed through the devices based on the existence of the .jar file.

nick.franzen Try replacing Get-ChildItem line with this:

foreach ($drive in $(Get-PSDrive -PSProvider FileSystem) ){
Get-ChildItem -Path $drive.Root -filter "log4j*.jar" -file -recurse -erroraction silentlycontinue | Select-Object Fullname, @{Name = "Hash"; Expression = {(Get-FileHash -Path $_.FullName).Hash}}
}

nick.franzen Bobby's is better, I am removing so make sure his is highlighted

Can we add a way (another step? another line of code?) to the end of this process to confirm that a given scanned station has completed the scan (as opposed to timed out or stalled on a file) that we can then put in a dynamic collection to prevent re-scan?  

I locked down some of my servers with early Printnightmare things that is now stalling my scanner.

Not having much luck with this PS script and scanner in my environment. Not sure what I'm missing.

To test I ran the PS against my HPE IMC server which is impacted by VCE-2021-44228 (Bulletin), I can search for log4j*.jar manually with results but  get NULL in the scanner even after a successful scan of the server in question.

What happens if you manually run that PowerShell script on the computer in question?  There's a PowerShell version requirement that it be higher than 4 I believe and you may be running into that.  To verify, open up PowerShell and just try to execute get-filehash.

jeb.gardner I ended up having the same issues, I kept getting odd errors depending on what I did. What worked for me was taking everything out except the "Get-ChildItem" piece, running the scan, then making a collection based on the hashes.

Full disclosure, I still got some false negatives only looking at the hash table on Mubix's github, so I made a separate collection for any servers that had "log4j-core-2" files that weren't version 2.16 and combed through those manually.

EDIT: Here's what my dynamic collection looks like, you won't be able to set it until you have scanned at least 1 PC successfully.

JC -

Running 5.1.XX PowerShell, below is output from the script and get-filehash.

jeb.gardner 1.x was found not to be vulnerable, so the hash for those files was not included, it is only comparing against hashes from 2.0 up to the latest version. 

Jordan,

There's no way to capture the version as well as the hash, correct?

joshua.campbell It looks like it generally has the version in the name of the file, so on the selection you might be able to do a calculated property to trim that down and end up with the version, but it would still get excluded from the final if the hashes do not match the list, so it would not return with the scanner

Thanks jordan.hammond.  I'm just trying to think of how to edit the collection to filter the 1.x out.

As far as performance goes, if we had the Scan as part of a Deploy Package, would we still need to possibly make the Performance change in PDQ Inventory?

joshua.campbell I believe the scan step in deploy is still kicking of an Inventory scan, so any setting Inventory has is what it will run by.

I think it might be possible to edit the collection, but it would take some regex. Using the name in the filter where it looks for a pattern of 1.numbers should be possible, but regex can be a nightmare.

Anyone else getting "Access is denied" running this as Local System?  

Hey, the scan works for me and testsystem were also detected. Are all vulnerable versions stored in the Github text file ? Thanks for your efforts