Suspected False-Positive Eclipse Jetty

false_positive
#1

Hello,

I have a client who uses Eclipse Jetty and they are getting the following result upon scanning:

NVT: Eclipse Jetty Server Fake Pipeline Request Security Bypass Vulnerability (OID: 1.3.6.1.4.1.25623.1.0.813551)
Vulnerability Detection Result
Installed version: 9.4. Fixed version: 9.4.11.v20180605 Installation path / port: 9876/tcp

They have confirmed that they have version 9.4.12.v20180830 installed on the server in question. Based on the scan, it appears as though only the major version number, 9.4, is being detected by the scan. Is it possible that the scanner is detecting the version number incorrectly?

Thank you!

#2

Hi,

and thanks for your report. It would be great if you could share the output of HTTP Server type and version (OID: 1.3.6.1.4.1.25623.1.0.10107) from the scan against the target in question.

#3

I’m actually using a third-party service, Network Detective, to run the scan, and so I can only see the scan failures without many details. They said they’re running the openvas scanning platform and to contact you for assistance :slight_smile:

I can probably download the virtual appliance and run a scan that way if needed. Let me know.

Thanks

#4

Hi,

it’s not absolutely required to run a “full” scan against this target. If you have direct access to the system and have a linux box at hand you could query the servers header with something like this:

curl -I http://targetip:9876

But i think i might have already found the issue:

Most common Jetty Server banners looks like this:

Server: Jetty(9.4.12.v20180830)

https://www.shodan.io/search?query="9.4.12.v20180830"

but there are also quite a lot out there using something like the following:

Server: Jetty(9.4.z-SNAPSHOT)

https://www.shodan.io/search?query="9.4.z-SNAPSHOT"

The regex used initially in Jetty Version Detection (OID: 1.3.6.1.4.1.25623.1.0.800953) hasn’t taken this into account and has build up and registered a wrong Jetty version ending with a dot which might have caused this.

I just have submitted an improved version of the Detection-VT into our SCM. If the previous described issue happens against the target in question as well then this should be fixed in one of the next feed updates.

Thanks again for your report.

#5

Ok, thank you so much. I’ll run another scan here in a few days and see if the issue is resolved.