Hey folks, I know there’s been some questions regarding the updated vulnerability check against Windows. The remote check that we released last night is intended to be platform-independent, so you can target Windows, Linux, and other OS’s as needed. There’s currently not an ETA for a Windows-specific authenticated check.
The remote Windows check requires a content update to 1.1.2352. If this check is failing for you, can you confirm that you’ve updated to this content version?
I’ve been in touch with our teams about these updates and they’re continuing to work to try to provide the best possible coverage for this vulnerability, so I really appreciate everyone’s patience here.
There’s the additional complication that there are a truckload of applications that have this problem. VMWare, for instance. VMWare Horizon is effected by this and at the moment we don’t have any way to track the ongoing remediation effort.
Same issue Console and Engine are up-to-date. Vulnerabilities are not shown. Even strange behavior that 10 instances were found (I assume via the insight agent) and after rescan with the engine it dropped back to zero, log4j*.jar files are however still on the same systems.
That’s behavior I’ve seen before. A system allowed my scan account to authenticate but it didn’t have the proper rights. So the agent data was very complete, but the “authenticated” scan wiped it out with bad data. Looking in the scan history you can still see the agent results. After the next agent check-in, the agent data will be the freshest and things will look correct again.
I wonder if the agent check is working and the scan check is not? Although currently I have zero results even with the agent deployed to everything Windows.
Alrighty, our team has released some additional info regarding remote checks and their requirements:
How does the remote check work?
The remote check is triggered to run on the following ports: 80, 443, 8080, 8888. It also triggers on an NMAP fingerprint of HTTP(S). So for the best coverage, enable Nmap service fingerprinting in your scan templates. Otherwise, the remote check will only work on the four ports we listed above. Note that enabling Nmap service fingerprinting may lead to increased scan times.
What limitations are there to the remote check?
Our remote check sends a payload that, if the scan target is vulnerable, makes the scan target attempt to open a connection to the scan engine. This approach relies on bi-directional networking and requires the scan engine and scan target to be able to “talk” to each other. In some cases, such as scanning through a VPN or NAT, that required bi-directional networking is not available. Notably, this is the same caveat that many other remote checks have. Networking is important, and if our check can’t reach the vulnerable target properly because something is interfering with that network communication, the check will logically not be able to deliver “vulnerable” results.
We’re going to continue updating our original blog post with info as well, so you can continue to check there for additional details.
Not sure if this has been asked yet, but we have a scan site ready to roll in our environment. Just a matter of Change Management approval to run the cred scans. Does the cred scan need sudo+su access to acquire this data? Or will low level user creds work? It’s just basically reading the log for the vuln, right? No need to elevate? Thanks in advance.
There currently aren’t any updates to Insight agents for Windows. To detect this vulnerability on Windows, we recommend using the remote check which is touched on in the blog post. I posted some more about this check above to give some details on how exactly it works, in case you encounter any issues with it.
For authenticated checks we’re actually using the find command for detection, so the user that the scanner authenticates with needs to have root privileges (or be set to elevate to superuser).
One more caveat for authenticated checks - mitigations for the vulnerability indicated in Apache’s advisory (setting log4j2.formatMsgNoLookups to “true” or removing the JndiLookup class from the classpath) are not currently taken into account by our authenticated check.
We’re continuing to update our checks and recommendations as we learn more. Right now the blog page I linked is the best place to refer to if you’re looking to follow along, but if that changes, I’ll post that, as well.
Hey Holly, sorry if its been asked but what port(s) does the scan engine list for the call backs from the scan target on? In heavily segmented internal networks there is likely going to be at least one firewall in the way of this. Knowing the listening port(s) could open the door for accurate scanning.
Hello, I have not been able to get the remote checks to successfully work on Windows. What errors in the scan data should I be looking for to find if it’s a network communication issue?
There currently aren’t any updates to Windows agents, as we’re recommending that folks use the remote check that’s mentioned in our blog post when it comes to Windows assets. For a little more detail on the remote check and its limitations, you can check out this post up above.
No worries! Checking with the team, the scan target tries to make a connection back to the scan engine on port 13456.
We actually received some reports that the remote check wasn’t installed 100% correctly when doing a content update. Because of this, we released product version 6.6.119 at about 6 PM EST to ensure the remote check for CVE-2021-44228 is available and functional. For this to fully take effect, you’ll need to update, then restart your scan engines and consoles.
So the best thing to do first would be to confirm your product version and restart scan engines + consoles to help verify whether the remote check is working.
Hi Holly, confirmed the console is version 6.6.119 and restarted the security console and all scan engines. Re-scanned the the Windows assets and no luck. I haven’t seen anyone else confirm that the remote checks on Windows actually work so I’m concerned I’m not the only one. Thanks
For us upgrading to version 6.6.119 is making no difference, Assessment using scanner is not working at all(Both authenticated and unauthenticated) : Even after following article with all requirement.
Agents assessment is working, but we all know its limited to Linux at this stage.
This is one of the requirement for unauthenticated check
“” The scan target must be able to make a connection back to the scan engine over port 12345. If this is blocked on the network, the vulnerability cannot be properly evaluated.""
I’m in the same boat in terms of being on 6.6.119 and being unable to detect anything with either definition.
Now that we have a remote check, can I assume that running a scan on external IPs and using the Rapid7 Hosted Scan Engine as that will have been updated & restarted would give us the best chance to assess our public footprint? I’ve scanned with this engine and I’m still finding nothing.
Has anyone detected anything in their environment?
I’m letting the team know and I’ll report back as I get more info.