False Negative Results
Closed this issue · 10 comments
I am running the Windows version 0.3.1 against a vSphere server that I know is vulnerable. I verified that the vSphere server is vulnerable using the script and steps outlined here: https://kb.vmware.com/s/article/87081
However the log4jScanner tool is reporting 0 callbacks. Any idea what might be going wrong?
Update: The Windows Firewall is disabled for all profiles
Update 2: I also should have mentioned, I'm running cmd.exe as an administrator, and using "netstat -anbo" I verified that log4jScanner.exe is successfully opening TCP port 5555, 0.0.0.0:5555
C:\Users\user\Downloads>log4jScanner-v0.3.1.exe scan --cidr 192.168.1.153/32
INFO Server URL: 192.168.1.164:5555
INFO Starting internal LDAP server on 0.0.0.0:5555
INFO Scanning 1 addresses in 192.168.1.153/32
Progress [1/1] ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ 100% | 0s
¯ Stopping LDAP server (10s)
Total requests: 3
INFO Summary: 192.168.1.153:5480 ==> 200
INFO Summary: 192.168.1.153:443 ==> 200
INFO Summary: 192.168.1.153:80 ==> 200
Total callbacks: 0
Type,IP,Port,StatusCode
request,192.168.1.153,5480,200
request,192.168.1.153,443,200
request,192.168.1.153,80,200
time="2021-12-21T10:17:00-06:00" level=info msg="Server URL: 192.168.1.164:5555"
time="2021-12-21T10:17:00-06:00" level=info msg="Starting LDAP server on 0.0.0.0:5555"
time="2021-12-21T10:17:00-06:00" level=info msg="Listening on 0.0.0.0:5555\n"
time="2021-12-21T10:17:00-06:00" level=info msg="Trying: 192.168.1.153"
time="2021-12-21T10:17:00-06:00" level=info msg="request,192.168.1.153,5480,200"
time="2021-12-21T10:17:00-06:00" level=info msg="request,192.168.1.153,443,200"
time="2021-12-21T10:17:00-06:00" level=info msg="request,192.168.1.153,80,200"
time="2021-12-21T10:17:14-06:00" level=info msg="gracefully closing client connections..."
time="2021-12-21T10:17:14-06:00" level=info msg="all clients connection closed"
time="2021-12-21T10:17:14-06:00" level=info msg="Summary: 192.168.1.153:5480 ==> 200"
time="2021-12-21T10:17:14-06:00" level=info msg="Summary: 192.168.1.153:443 ==> 200"
time="2021-12-21T10:17:14-06:00" level=info msg="Summary: 192.168.1.153:80 ==> 200"
@proferosec This is kinda a big deal. No scratch that, this is a big deal.
Hey @wright546 , does vSphere is running a vulnerable web server? on which port?
This tool sends a web request to the vulnerable servers and records a callback.
@xFreed0m Default ports, vanilla installation. Should be TCP ports 80, 443, and 5480.
@TechStudent11 I'm definitely not ruling out that I'm doing something wrong, in fact that's my assumption. I just don't know what it is.
The tool is communicating with webservers on open ports from the list, then sends a request with the vulnerable payload inside. if the webserver logs the request with log4j, the vulnerability triggers and a callback is sent back to the server.
if you dont get any callbacks:
- maybe the network is blocked from target to host? maybe there are some FW rules preventing the callback?
- i am not familiar with vSphere web service, but we might not hit the right port, or send a request to the right place. we assume that the web servers logs the requests, but it might not. if it does not log these requests - the vulnerability wont trigger
to summarise - if you get a callback, that is definitive proof that the server is vulnerable. but if you dont, it does not mean it is not vulnerable.
the purpose of the tool is to discover vulnerable servers fast, to hasten response - not to find all them, which will probably be too difficult
I verified that the vSphere server is vulnerable using the script and steps outlined here: https://kb.vmware.com/s/article/87081
Looking at the script it looks like you didn't just verify you also mitigated. Read the script it is a workaround to the vulnerability and once you run it, it should not be vulnerable.
Anyhow if you look at our tool its a scan to check if root logging is vulnerable in multiple places but it won't deep dive into each section of a webserver. Its not a replacement for a full manual test with tools such as Burp Suite etc.
@GelosSnake I used the "-r" switch when I ran the VMWare script, it was a "dry run" that only reported vulnerable files but did not fix them.
@guybarnhartmagen @GelosSnake Thank you for your responses. I guess this issue can be closed.
@GelosSnake there is no need for my response to be "down-voted". I'm saying that if you get a negative when really it's a positive.
@wright546 just to clarify some terms. False Negative means that we report a vulnerable server as non-vulnerable. I think you misunderstood what the tool provides.
we provide only evidence for True Positives. in other words, if you get a "SUCCESS" that is positive confirmation that this server is vulnerable. if you dont get that confirmation, it does not mean that the server is no-vulnerable, it means that we were not able to test it.
we dont support false negative, because we cannot do a definitive test for the vulnerability of the server, which is why:
- we clearly state this in the README
- we suggest, strongly, that you check and verify all other servers
- we recommend to prioritize the servers discovered by the tool, as they are definitely vulnerable, and all others are potentially vulnerable
i hope this helps, and also explains why the use of "False Negative", is probably a misunderstanding on your part on what the tool claims, and achieves.