Log4j CVE-2021-44228

InsightVM
182

@holly_wilsey I just want to confirm the only way to detect on windows for log4j is indeed configuring the authenticated(credentials & Wmi feature enabled on hosts) and non authenticated (using port 13456) templates?

183

That’s correct, those are the available checks for Windows. This page has a good amount of info regarding those checks and configuring them for your environment.

https://docs.rapid7.com/insightvm/apache-log4j/

There’s also a section there that mentions how you can use the Insight agent to detect the CVE, beginning with version 3.1.2.38.

https://docs.rapid7.com/insightvm/apache-log4j/#other-ways-to-detect-log4shell-in-your-environment

184

Thank you Holly, even the agent relies on WMI feature. Can you explain why that feature is needed and what its for ? I think i saw this where it does rely on wmi… Authenticated does not right, but it does rely on port 13456 ?

185

WMI is something that allows for both local and remote management of Windows machines. For instance, you could use it to remotely run a process, or see what applications are installed on a particular machine.

We recommend having WMI enabled when doing authenticated Windows scans since it’ll help ensure you get the most accurate assessment possible. In the case of the Log4j check, it’s required to be able to perform that detection. There’s some more info here on the usage of WMI in the context of Windows authenticated scans:

https://docs.rapid7.com/insightvm/authentication-on-windows-best-practices/

As for the Log4j auth vs. unauth’d checks - the authenticated one would require WMI to be enabled, while the unauthenticated (which is where the scan target attempts to open a connection to the engine on port 13456) does not require WMI.

1 Like
186

Troy, do you have something similar to this for spring4shell? Thanks

187

@tony_nyamu, you might try just changing the following in that SQL query:

1 Like
188

I had tried using below but the report is blank

where nexpose_id = ‘spring-cve-2022-22965%’

189

@tony_nyamu

try this

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  
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 like 'spring-cve-2022-22965%'
ORDER BY da.host_name, da.ip_address
1 Like
190

Worked like a champ! Thanks, @troy_newcomb!

191

Apologies if this is remedial. We are just beginning to leverage SQL reports. When I attempt to run this in SQL Query Export the validation checks out but when ran the query returns the error “relation “dim_asset” does not exist”. Any help is appreciated, thank you.

192

@jmpalmer

Maybe try one of the out-of-the-box examples and see if the validation and preview work for you.

SELECT ds.name AS site_name, da.ip_address, da.host_name, da.mac_address, dos.description AS operating_system, dht.description, dos.asset_type, dos.cpe 
FROM dim_asset da 
   JOIN dim_operating_system dos USING (operating_system_id) 
   JOIN dim_host_type dht USING (host_type_id) 
   JOIN dim_site_asset dsa USING (asset_id) 
   JOIN dim_site ds USING (site_id)
1 Like
193

The test worked. Went back and tried the full query again and it ran. Really not sure what I did wrong before, but everything seems to work. Thank you for the response!

194

Is there anyone still not patched to this? I think this vulnerability should go to years Top 10 as minimum…

195

Is there anyone still not patched to this?

The intersection of “people who know they’re vulnerable to Log4Shell” and “people who would publicly admit that they’re vulnerable to Log4Shell” is probably not densely-populated.

I think this vulnerability should go to years Top 10 as minimum…

Definitely a vulnerability for the ages!