@DeeAnn thanks for the information. Will this be updated so NAT is supported? It would be helpful if we could scan our systems from outside for this vulnerability.
Hi @damdam, welcome to the forum 
and thank you!
Iām not sure if itāll be updated for NAT support, but Iāll pass the request on to the developers.
(@all update on scan configs)
The specific scan configuration optimized for this vulnerability is still in development, but using the āFull and Fastā scanning option includes it (it just takes longer to run as it checks everything). The plan is to have the optimized scan configuration included with the feeds when it is released, but for now everything should work (just not as quickly).
1 Like
Thanks, I am a newbie, trying to learn the tool.
But why is the Severity N/A, What donāt I understand
Ran the new scans against our infrasturcture and we see the detection on windows servers that have no Java of any kind running. They are running Microsoft Certificate services. Could this be a false positive that needs to be addressed?
Hi there,
so, I can see the CVE and with a self-made ScanConfig, I can select the CVE-2021-44228 for Scan.
BUT, when I start the Scan, I am not able to see that the CVE was checked. Only 100% - no findings.
I tried this post:
https://community.greenbone.net/t/hint-self-created-scan-configs-copy-of-empty-scan-config-showing-no-results/331
It could be that the server has no vulnerability, but is there any possibility to show, that this CVE was used within the Scan? Or do I have to create a host with this spcific vulnerability, to check if the scan works correctly?
Hi @DeeAnn,
I have the same issue as @bbascou on a GSM. The CVE-2021-44228 seems to be missing in the library and not one Log4j entry is shown in any report.
Iām seeing similar issues - I have a web application that I have specifically deployed that I know is vulnerable, and a scanner specifically for log4shell that picks it up, and Greenbone is not identifying it as vulnerable. I see the port scan for the application, but no identified vulnerability.
1 Like
Exactly the same on our side.
Hi,
I updated everything but CVE-2021-44228 missing in CVEās list.
My intial scan (full and fast) using he updated NVTās ended up showing several false positives-- for example, against a host that only has PHP and ZERO java-anything on it. sigh
I have updated my greenbone feed things again and am now running a full scan using the dedicated log4j scan profile thatās there now.
@vnick , what app did you deploy as a should-be-positive test? Iād like to try that.
So, it seems I had earlier gotten nvtās etc that were (probably) still in the works this morning, a re-scan of hosts that showed (probable) false-positives scan OK this time. I updated all the feed/cert/scap etc this aftenoon.
In addition, the log4j-only scan I just completed found a bunch of the same thing on a handful of hosts I have-- basically elasticsearch 7.xx thatās impacted by log4j, and the info regarding the resolution (simple elasticsearch update to 7.16.x), with no oter hosts showing up. My elastic hosts are internal-use only and not exposed outward.
So, at least for now, Iām convinced the uupdated nvtās etc along with the log4j scan profile seem to work well now.
Clearly this is a moving target, and Iāll be asking the corporate IT dept here to run their nessus scanner against my stuff too. Thus far thei scanner is showing NOTHING, so I think other vendors have simila issues with getting this right. Easy to understand, this is not a fun thing.
Weāve deployed GCS as our main-vulnerability scanner for a fairly segmented HPC environment wherein most of our nodes are on seperate VRFs & VLANs. Because Greenbone has highly priveleged visibility to our most sensitive subnets inbound access to it is also quite locked down to the most priveleged staff VPN pool.
Is there any kind of a viable workaround for this? Because we have close to a thousand nodes in our infrastructure and we really would like to get some conclusive sense of which ones might be vulnerable. Reworking our routing tables etc for ths however is a non starter
Good Morning,
here I share my experiences with this situation:
Yesterday 15:00 CEST, I updated the feeds and started scanning immediately my infrastructure. It detected a handful of log4j alerts. However, something is a little fishy there:
-
The Payload contained the wrong IP-Address. We use an OpenStack-VM with a floatingIP attached to the vm of the scanner. This makes it some ākindā of NAT but is actually just a 1:1 mapping of the private to the floatingIP. Checking the nasl-code, it seems that
this_host()just returns the interface from the default routing behaviour. -
Since the IP is not reachable for the target host, this check should NEVER return positive on the greenbone side. However, in some random cases it does! Therefore it must be a false positive.
-
Iām not quite sure yet on why the opened socket by greenbone gets triggered. My nasl skills just started to develop since yesterday.
Good Morning,
We are seeing some surprising scan results, too.
For some reason, greenbone claims that mitigated systems are still vulnerable and that there was an inbound connection to the scanner on a specific port. However, the firewall log does not show this specific connection in its connection log.
This leads me to the conclusion that the detection is not 100% accurate yet.
Fairly new here so be gentle 
Im running GSA 20.08.1 with Apache (2.4.51) and just wondering whether the above CVE is affected? Iāve tried updating the CVE feed and itās not showing in GSA
1 Like
Hi everyone, thanks for your questions and issue reports
OOB (Out-of-band) communication/external interaction/segmented environments currently are not supported, but we are looking into it for the future. Please scan in each segment.
False positives- yep! Itās an issue (and weāre looking into it).
Vulnerability not showing up at all- the first thing I would check is that everything is up to date and you are using a Greenbone-provided scanning configuration.
2 Likes
For my environment:
- Yes, everything is up-to-date - running a reasonably recent scanner (21.4.2 - I know, 21.4.3 is out, but I have not updated to that, yet), and have run all of the feed sync jobs multiple times.
- I have tried both using the stock Greenbone scans (Full and Fast, which, according to the blog post should contain the detection of the CVE) and have also tried setting up custom scans and selecting specific log4shell scans. Neither seems to turn up results, including on a known-bad application.
@vnick thanks!
It looks like it has to do with headers and specific circumstances, they are going to add an additional check for the VT so it should show up scans.
2 Likes
Yesterday, while scanning an affected system, we were able to resolve the log4j vulnerability. Today, when I run the same scan on the same unmodified device, I no longer find this vulnerability. Is this a known issue?
When I run htop i can see that the log4j nasl is running 5 to 6 minutes.
Currently Installed: 21.4.3, with most recent feeds.
Thanks everyone for your hard work on this!