Is there a feed yet for ongoing release notes for the log4j detection updates? We’re starting to get MS Defender alerts for some of the R7 log4j scanning activity, which I believe is due to last night’s detection changes. I’m being asked for release note updates, but not finding detailed (ongoing) update information.
We do have InsightVM-specific release notes here, though they may not be as detailed as you’re looking for regarding log4j.
https://docs.rapid7.com/release-notes/insightvm/20211215/
We have been updating our blog post with the latest log4j info, so that’s currently the best place to look as we continue with releases and updates.
If that changes, I’ll let you know and likely add it to the Log4J Info thread.
Thanks - I have been constantly following Log4J thread already. The regular product release notes do not contain sufficient technical detail regarding the R7 detection updates or methodology.
My leadership and coworkers are grilling me pretty hard on your product & I’m struggling to provide sufficient technical responses. I’m doing what I can to extract info from the main thread, but like others noted, we’re having detection failures even when there are no physical firewalls in between the scan engines and the targets and no local firewalls running on the scan engines to block the TCP/13456 return traffic.
With insufficient logging to properly troubleshoot and the lack of technical details to troubleshoot other possible contributors for the skew in expected results - it’s putting me in a very uncomfortable position as the “corporate expert” for R7 products.
Understood, it’s a difficult situation all-around. We’ll be sure to share updates regarding the checks we’ve released as development continues, since it’s something that’s ongoing. Out of curiosity, are you using hosted engines for your scans?
And are there any particular questions you have that would make your life a little easier? I’d like to relay to our teams and answer if at all possible, or help clarify the existing info that’s out there if it’s unclear.
For internal network scans we’re running all engines within the same network segments as the targets to avoid crossing over any physical firewalls. Externally all of our scan engines are running out of Linode.
We’re not trying to assess our external footprint with R7 as we’re using Censys.IO for that.
Specific questions would be around what R7 is attempting to assess and how. We’re getting MS Defender alerts very sporadically, so there’s some inconsistency and it’s unclear if that’s due to network scanning, authenticated scanning at the OS level, or coming from the agent.
Alright, so it sounds like you’re looking for more detail on how exactly the checks work to perform the assessment? I’ve got some more details here I can share regarding the authenticated check, hopefully this helps a little.
Authenticated check
This uses the find command on Linux/Unix systems to identify vulnerable versions of the Log4j JAR files. It’s going to do a full filesystem search for any JAR files on the Apache Log4j 2.x version stream with a version lower than 2.16.0 and report back as vulnerable if found. It gets version info by using the unzip command to examine the JAR’s manifest file.
More Details
- The check does not account for some of the mitigations for the vulnerability listed in Apache’s advisory (setting log4j2.formatMsgNoLookups to “true” or removing the JndiLookup class from the classpath).
- Yesterday (Dec 15) we released an update that added the capability to fingerprint version information if it’s present in the JAR’s filename, in case the
unzipcommand is not available on your system.
For the remote/unauthenticated check, we detail a good portion of the logic in our blog post under the “Remote scanning” section, so I don’t want to echo that info too much if you’ve already read it. Any details not covered there that you’re looking to learn?
We’ve passed along the feedback regarding the remote check, as well, so I can share any updates there with you as we have them.