We found that the initial release of the check only deployed the .vck referencing the .nse script for the check and the update from last evening deployed the sp-apache-log4j-rce-vuln.nse nmap script. We’ve set the engines to allow inbound on 13456 and the next item I recommend in general set a search in your log monitoring for denies and connection attempts back to your scan engine addresses. The hosts may not show as vulnerable in the console but at least you’ll know which systems are getting triggered.
Also keep in mind that the check is looking at 3 header types that may or may not trigger your services. X-Api-Version, User-Agent, and Referer the jndi:ldap call will be TCP out to 13456 SecPod Technologies listed as the script author has this writeup for the basics of the detection even if it doesn’t go over the .nse script in detail. Discover The Extremely Critical Apache Log4J Vulnerability (CVE-2021-44228) - SecPod Blog I would also be mindful in general of virtual hosts vs. default hosts on systems.
for _ , interface in ipairs(interface_list) do
socket = nmap.new_socket()
socket:set_timeout(9000)
-- call to get appropriate pattern to check from packet captured, Should be Berkeley Packet Filter expression
pattern = "dst host " .. saddr .. " and src host " .. host.ip .. " and dst port 13456"
socket:pcap_open(interface, 128, true, pattern)
for i=1,3 do
headers = {["X-Api-Version"] = "${jndi:ldap://".. tostring(ip_address) ..":13456}",
["User-Agent"] = "${jndi:ldap://".. tostring(ip_address) ..":13456}",
["Referer"] = "${jndi:ldap://".. tostring(ip_address) ..":13456}"}
url="/"
response = http.get(host, port, url, {header = headers})
if(response and response.status) then
response_present = true
end
status, _, _, _ = socket:pcap_receive()
if(status == true) then
vulnerable = true
break
end
end
socket:pcap_close()
socket:close()
We currently do not have an ETA for detection via the Windows agent, primarily because of performance concerns. In our experience and testing, searching Windows filesystems for JAR files like we do with the find command on Mac/Linux can result in serious performance issues, and we want to avoid releasing something that could potentially destabilize your systems.
That said, we’re continuing to research and update our recommendations, so I’ll let you know if we have any additional info to share regarding the agent.
I went ahead and shared your feedback with the team. Currently we’re using the log4j-core.*.jar check because it is part of log4j 2.x, which is impacted by this CVE. Thus far version 1.x (which should use the older log4j*.jar) is not officially indicated as being impacted by this CVE.
We are still researching this though, and may update our checks as needed.
The correct port is 13456. We had a miscommunication yesterday regarding the port number here, but have now confirmed it is 13456.
Thanks for confirming (and for everyone else who has). I’ve let the team know about this with the remote check, and we’ll share any updates as we have them.
Could this be released in the “unsafe” category and we can use it at our own risk? I’d rather be able to scan our servers outside of business hours and ensure we have accurate coverage of this vuln.
Same Issue, Windows R7 agent didn’t identify any vulnerable assets. Even remote scan too didn’t flag any assets with vulnerability. Agents and Scan engines are on the latest versions, but no luck.
So applying these checks in the template is supposed to give us feedback on the windows systems in our environment? As long as we upgrade to the new version of the console?
Where in the logs can I see the remote check happening? I would like to confirm it is because from what I can tell, it’s not working. I have the latest content update from this morning. I have a support case open but I rather not wait 48 hours for a response.
Edit your custom template and on “Vulnerability Checks”, you should be able to see latest individual checks if you have latest update.
Please note that I didn’t manage to find anything, so I guess that these checks are not working correctly at the moment.
Interestedly enough, I’m now seeing a single Windows device being flagged by the remote check for the first time. Maybe they fixed something from the content update last night?
It seems like a looooot of people are confirming that the remote check doesn’t work properly for windows systems. This is getting really, really frustrating to report at the standups that I’m sure we’re all having on a daily basis. Not a great look.
I don’t know how it’s acceptable that we have no authenticated or agent direct .jar check yet for Windows systems. At least Unix-like systems can identify vulnerable .jar files and go from there. We shouldn’t have to rely on a likely inaccurate remote check. This vulnerability can be exploited in a multitude of different ways, there is no feasible way that this remote check is getting good coverage.
The other issue that I’m finding is that the check that seems to reliably return (for root-access linux scans) is just looking at the version of log4j. Most of the fixes that I’ve seen so far have been to mitigate the problem by changing settings. Which obviously won’t satisfy that check, because the vulnerable version will remain present even though the risk has been eliminated.
@mike You are seeing windows systems being flagged now?
Also, with the windows agent not having a check i wonder if we can scan them with credentials in the console, put them back in as normal, and then scan with the custom template with updated console .119?
