Re: rmiregistry default configuration vulnerability script

[Aleksandar Nikolic <nikolic.alek () gmail com>]

> 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:
> http://dev.metasploit.com/redmine/projects/framework/repository/revisions/master/changes/modules/auxiliary/scanner/misc/java_rmi_server.rb
>
> 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
> generation.

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
ClassNotFoundException
with localized message for class loading disabled.
Can anyone suggest a configuration where this would be the case ?


Thanks,
Aleksandar
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/