Log4j CVE-2021-44228

Gee, would really love a report for a SQL Query export. I am not a SQL guy - I inherited Rapid7. I need to provide proof. I am scanning literally thousands of endpoints - would really appreciate if Rapid7 provided us the query to export proofs per host…

Can anyone help how to identify the log4j 1 version files using windows authenticated check.

When is VMware Templates available? We know these hosts are vulnerable but are not showing via Rapid 7

1 Like

Look at the Report Card report. That may be what you are looking for.

I have also seen the “vulnerability has been deleted” banner but I did not pay much attention to it. I’m also curious why we’re seeing it.

@JuiceBox we all have been there. I would suggest using the nexpose out-of-the-box SQL samples, a cup of coffee or tea and so searching the internet for examples. You can cut and paste and create some SQL masterpieces with some headbanging on the wall and some time.

Below I started this out with one of the examples in nexpose called vulnerability details, then removed what I did not want(removed sites because I am scoping to asset group), Then added in what I did want. 2 key things on this one. There is a filter for a list of nexpose ids, this puts the focus on just the log4 vulns. Then I wanted to have the filename out of the proof for my use case.

Try this SQL to report on log4. Nexpose is not so great on out-of-the-box reporting on a single vulnerability or a few vulnerabilities. You pretty much have to do it in SQL or completely outside the product.

This is a report that shows the filename, proof, and hostname. It should exceed what you are looking for. Note: This report is not for remote instances and if new nexpose ids come out they may need to be added.

WITH 
   vuln_references AS ( 
      SELECT vulnerability_id, array_to_string(array_agg(reference), ', ') AS references 
      FROM dim_vulnerability 
         JOIN dim_vulnerability_reference USING (vulnerability_id) 
      GROUP BY vulnerability_id 
   ) 


SELECT  array_to_string(regexp_matches(proofAsText(favi.proof), '([^/]+)\)$', 'g') , ',') as filename
,
da.ip_address, da.host_name, da.mac_address,  da.last_assessed_for_vulnerabilities,
   dv.title AS vulnerability, dvs.description AS status, favi.date AS discovered_date, 
   CASE WHEN favi.port = -1 THEN NULL ELSE favi.port END AS port, 
   dp.name AS protocol, dsvc.name AS service, proofAsText(dv.description) AS vulnerability_description, 
   proofAsText(favi.proof) AS proof, dv.severity, round(dv.riskscore::numeric, 0) AS risk, 
   round(dv.cvss_score::numeric, 2) AS cvss_score, vr.references, dv.exploits, dv.malware_kits, dv.pci_status 
FROM fact_asset_vulnerability_instance favi 
   JOIN dim_asset da USING (asset_id) 
   JOIN dim_vulnerability dv USING (vulnerability_id) 
   JOIN dim_vulnerability_status dvs USING (status_id) 
   JOIN dim_protocol dp USING (protocol_id) 
   JOIN dim_service dsvc USING (service_id) 
   JOIN vuln_references vr USING (vulnerability_id) 

where nexpose_id in(
'apache-log4j-core-cve-2021-44228',
'apache-log4j-core-cve-2021-45046',
'apache-log4j-core-cve-2021-45105'
)
ORDER BY da.host_name, da.ip_address
6 Likes

Hey gang,

Any updates on VMware vulnerability checks ?

Also, another question for any others having success detecting log4j via unauthenticated checks via windows or linux?

Thanks.

1 Like

Seconding this .

Thank you @troy_newcomb !!

This is exactly what I was looking for related to ‘where’ the log4j findings were located on any given host.

I loosened the regex for filename so hopefully it extracts only the path from ‘proof’. This should support cross-platform paths (Linux, MacOS, Windows).
array_to_string(regexp_matches(proofAsText(favi.proof), '\((.+)\)', 'g') , ',') as filename,

I also expanded the regex concept to include the vulnerable software. It extracts the log4j version found in ‘proof’.
array_to_string(regexp_matches(proofAsText(favi.proof), ':\ (.+?)\ \(', 'g') , ',') as software,

2 Likes

Hey @ChromeShavings, sorry for the delay here! I believe this is similar to what some were seeing regarding the check for CVE-2021-44228 that was deleted in the InsightVM UI. Our team double checked everything and the check wasn’t actually deleted. If you’re on the latest product version and have restarted, it shouldn’t be an issue for CVE-2021-45105 either.

We currently don’t have checks specifically for VMware right now, but this is something we’re working on. We plan to add checks for everything in our recurring coverage list, based on the details/fixes that the vendors provide.

I can let you know as soon as we have more info on VMware specifically.

I have inbound port 13456/tcp open inbound to my scan engines and tried to telnet to the port for verification but that fails. Checking on the scan engines with netstat, I do not see a listener on 13456.

I have latest version 6.6.122 and even checked for the listening port at the moment a scan with the log4j check enabled was running. Has anyone ever seen one of their scan engines listening on 13456 for unauthenticated network scan call backs?

Hi Holly,

Yes please!

Thanks!

1 Like

In this case, the scan engine is going to do a packet capture to identify connection attempts against 13456/TCP, rather than opening a listener. The “Remote scanning” section on this blog post talks through it in more detail, in case you’re still trying to confirm the status of the remote check. Hopefully that helps a little.

@holly_wilsey

Does IVM give us the capability to detect jar files nested within other jar files ?

Currently, InsightVM is not able to detect Log4j in nested JAR files. We are exploring some other options related to this functionality, but at the moment, this would not be detected.

Do we know for sure that the we should be concerned about nested jar files? As in, does the vulnerability still exist for nested jar files?

The vulnerability would still exist, in this case. The tricky part about nested jar files is that the Windows file system scans are already very resource intensive, and if we were to do recursive checks and search jars in jars, scans would require exponentially more in terms of time and resources.

That said, we’re still researching and making updates to these checks so we can continue to improve the log4j coverage.

We had some specific ‘log4j’ only template/scans running along with our regularly schdeules scans.

Two questions hoping someone can help with…

    • Do we need to be updating and adding to the log4j specific scan? (ie going to templates, vulnerabilities and searching for more ‘log4j’ to add)?
    • Wanting to confirm that a current template includes log4j checks but find understanding the displayed/not displayed selections extremely un user friendly - we have this template trimmed for only by check types of ‘Microsoft hotfix’ ‘rpm’ and ‘patch’ - would log4j fall under these choices?
      checktypes_OS

I have gotten a few false positives from the remote check on Windows systems involving JAR files. It’s random if it’ll get flagged or not. That being said, the remote check tends to not work on systems I know are vulnerable for some reason.