mailing list archives
Re: rmiregistry default configuration vulnerability script
From: David Fifield <david () bamsoftware com>
Date: Sun, 27 May 2012 21:56:22 -0700
On Sat, May 26, 2012 at 12:40:18PM +0200, Aleksandar Nikolic wrote:
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 ?
I suspect that even if the exception message is localized (it may not
be), that the English text will account for almost all installations.
But it seems that the rmiregistry source should be public; can you check
quickly to see how this exception is thrown? If not, let's not worry too
much about it.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/