Re: rmiregistry default configuration vulnerability script

[Marcus Haebler <haebler () gmail com>]

> > On Fri, May 25, 2012 at 8:48 PM, Aleksandar Nikolic
> > <nikolic.alek () gmail com>wrote:
> >
> > Hi All,
> >
> > I've written a script to test rmiregistry servers for this default
> > configuration
> > vulnerability which allows remote class loading and therefore remote
> > code execution.
> >
> > There is a Metasploit exploit for this vulnerability.
> >
> > To test it , you just need to run rmiregistry which comes with
> > any JRE installation (rmiregistry.exe on Windows, rmiregistry on Linux)
> > and then run the script against it.
> >
> > I've attached the script and a small patch for rmi.lua library as I needed
> > one function to add raw data as arguments to writeMethodCall.
> > The sciript contains already serialized data, it was easier to do it
> > that way then implement the whole serialization in the library.
> > For additional info , see references in the script.
> >
> > Please tell me if you have any comments and suggestions.
> >
> >
> > Thanks,
> > Aleksandar
> >
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
> On Fri, 25 May 2012 21:16:00, Patrik Karlsson <patrik () cqure net>
> wrote:
>
> Great job! I just tested it and it worked great for me.
> I'm wondering whether the match for "RMI class loader disabled" could be a
> problem if it's localized?
> Is there anything else you could match in the packet, like an error code or
> something?
>
> An alternative I initially thought of and tested was to use a http-link
> pointing to the scanning host and to pick it up with pcap. But that's
> probably not very solid as there may be firewalls or other device blocking
> the connect back request.
>
> //Patrik
> --
> Patrik Karlsson
> http://www.cqure.net
> http://twitter.com/nevdull77
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

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.

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.

Some developers like to start the RMI registry on other ports
than 1099. What that means for scans is that one should use
"--version-all" because the generic "Probe TCP JavaRMI"  is set
to "Rarity:8" in nmap-service-probes. Given the prevalence of
Java ecosystem in many enterprise networks, the rarity should
IMHO be set to 2. This way it would be picked up by a
"--version-light" scan.

Thoughts?

Thanks,

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