mailing list archives
Re: rmiregistry default configuration vulnerability script
From: Aleksandar Nikolic <nikolic.alek () gmail com>
Date: Sat, 26 May 2012 12:40:18 +0200
I have been working on exactly the same kind of module because I do
not like having to rely on Metasploit for checking for this vulnerability.
Too late. :(
Since I have been working on this for a bit, I have a couple of thoughts
to offer though.
The point about the check is a very valid one. I have had the same
thoughts as Patrick on this one. This is the way the check is done in
the Metasploit scanner - not the exploit - as well:
My current working version actually checks for both the "RMI class
loader disabled" string AND for a "java.lang.ClassNotFoundException"
for the class the check attempted to load - dummy in your case.
If there is a ClassNotFoundException for the class we attempted to
load, it should be a positive indication that the target is vulnerable.
That is IMHO more reliable than just checking for the string above.
The problem is that ClassNotFoundException gets thrown
even in the secure setup, just with a different message.
It might make sense to follow Metasploit and use random strings
at least the .jar. One of my todo's is to also randomize the class
name. msrpc.random_crap() seems to work OK for random string
I believe the reason for random name in Metasploit is simple
signature evasion, they always use random strings for payloads.
Would this be necessary?
Besides, again , that class name (dummy) string
appears in both vulnerable and secure setup.
Anyway, it wouldn't be much of a trouble to add that.
So far, I was unable to get vulnerable rmiregistry to throw a
with localized message for class loading disabled.
Can anyone suggest a configuration where this would be the case ?
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/