Verify VULNID 103811 EJBInvokerServlet / JMXInvokerServlet Marshalled Object

A security system vendor gave us two vms of their product to put on our network. I ran a Non destructive Full and Fast scan (via OSSIM) on the network and their device triggered VULNID 103811 EJBInvokerServlet / JMXInvokerServlet Marshalled Object, which is Severity 10. I told them and they gave many reasons, a different reason every time I questioned the previous reason.

After many questions, I asked them "Is this a false positive? Is our scanner actually not detecting unauthenticated access to EJBInvokerServlet or JMXInvokerServlet? "

and I gave them this link to check the actual script: https://vulners.com/openvas/OPENVAS:1361412562310103811

Their latest answer is "I tested the exploit on Friday with our new architect the same linked in the vulnerability mentioned in your email below and it’s a false positive, it doesn’t give me a php prompt like it should.

Is that a good answer? Since they didn’t get a PHP prompt, does that mean the vulnerability is not present?

Thank you

Not sure if they tested what the VTS is checking for or if they used the linked exploit from Exploit-DB.

The NASL check doesn’t give you a PHP prompt but rather checks if one of the two servlets are installed and accessible without authentication. How reliable the exploit from Exploit-DB is and how universal it can be used, I don’t know. Sometimes a little tweaking is needed to get things running. But I guess the vendor should have all the information to determine if his servlets are indeed safe or not.

So quite difficult to say if this is indeed a false positive or not. Maybe ask the vendor why this servlets need to be accessible without authentication firsthand. Or what other reasons he has to believe (besides an exploit he runs doesn’t give the results he expects) that he is safe (e.g. never versions, some configuration measures, etc).

2 Likes

Thanks very much ckuerste. Perhaps I was incorrect in supplying that NASL from exploit-db, although it says it is from OpenVAS.

Is what the VTS is checking for different from the NASL script? Or, what steps can I take (I have a knowledgeable coder available) to verify this finding?

Thanks

Peter

I think you are confusing something here.

The VTS (or NASL) script is indeed from OpenVAS/GVM. But this is a vulnerability check and not an exploit for this vulnerability. As stated above this will never give you a PHP prompt but rather check for the existence of this servlets and if it is accessible without authentication.

An actual exploit which might give you a PHP prompt is linked in the VTS which is located on Exploit-DB but has.

So:
VTS/NASL script -> indication that the servlet is present and might be vulnerable
Exploit from Exploit-DB -> tries to exploit the vuln and might give you a prompt

Your vendor should have the needed information if their product is actually vulnerable or not and if not, why so (servlet version, countermeasure, etc). Stating that it didn’t give them a prompt is IMHO not prove.

1 Like

Thanks very much. I understand better now!

Is it possible JBoss has been updated, and even though the servlets are accessible by the VT, they are not vulnerable to unauthenticated use? And time to take another look at this VT?

Peter

The vendor said they will conceal the servlets from outside the machine, because they don’t need to be reachable from outside.