Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: rmiregistry default configuration vulnerability script
From: Marcus Haebler <haebler () gmail com>
Date: Sat, 26 May 2012 06:27:31 -0400

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]