Nmap Development mailing list archives
Re: Java RMI service finderprint?
From: Martin Holst Swende <martin () swende se>
Date: Tue, 14 Jun 2011 19:37:58 +0200
On 06/14/2011 05:22 PM, Gabriel Lawrence wrote:
So right. The standard RMI registry is going to be on 1099. And it sort of makes sense there. The interesting aspect, and one very useful, is that the JMX interfaces use an arbitrary user assigned port for its listener. Turns out this listener is just a special RMI Registry so connecting to it and dumping it using the rmi-dumpregistry script turns out to be very useful. JMX can expose the internal state of a service and allow for remote changes to that service. Finding instances of this misconfigured listening to anything and willing to talk unauthenticated or lamely authenticated is a valuable thing for someone doing a security audit of a site.
Hm. I'm not sure if I understand you completely. To my understanding, most normal applications which use rmi uses a regular rmi registry. The registry contains an object called "jmx-connector". See the first output-example in the source code (does not 'survive' into the nsedoc, I just noticed - only the last @output makes it): http://nmap.org/svn/scripts/rmi-dumpregistry.nse The 'next step', which I started at, would be to write an authentication-script for the jmx-connector, and use the bruteforce library to perform credentials guessing against the jmx service. I abandoned it for other things (as I recall it, authentication is a multistep process where the return values of the first call must be handled correctly - which was not trivial. Writing a bruteforcer based on java seemed much more logical, so I kind of let it go) - but I may make another effort, it would be pretty cool to have around.
I understand that the nmap team is looking at ways to scale scans massively... I also get with service fingerprinting that sending lots of strange junk at certain ports has unwanted results (see printers), but I also think that the expectation of a user using service fingerprinting is that nmap is trying everything reasonable against a service. Maybe this is an opportunity to add a flag to ignore ports and try all service fingerprints against a listener that didn't fingerprint in the original pass? I'm trying to think of ways to balance the expectation an auditor focusing on one site has vs the need to be able to scan an entire organization in a reasonable timeframe...
This is bordering on 'named probes', which has been discussed here. But perhaps something like this: nmap -sv --named-probes GetRequest-rmi <target> <ports> Where a user can specify probes just like ports, in intervals (Foo-Bar) or separated (null, GetRequest) or single (rmi).
BTW, Martin great script! Thanks for putting it together!
Thanks! Always nice to get positive feedback from 'the real world'!
Gabe
/Martin _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Java RMI service finderprint? Gabriel Lawrence (Jun 13)
- Re: Java RMI service finderprint? Gabriel Lawrence (Jun 13)
- Re: Java RMI service finderprint? David Fifield (Jun 15)
- Re: Java RMI service finderprint? Martin Holst Swende (Jun 15)
- Re: Java RMI service finderprint? David Fifield (Jun 15)
- Re: Java RMI service finderprint? Martin Holst Swende (Jun 15)
- Re: Java RMI service finderprint? Martin Holst Swende (Jun 16)
- Re: Java RMI service finderprint? David Fifield (Jun 15)
- Re: Java RMI service finderprint? Gabriel Lawrence (Jun 13)
- Re: Java RMI service finderprint? Martin Holst Swende (Jun 14)
- Re: Java RMI service finderprint? Gabriel Lawrence (Jun 14)
- Re: Java RMI service finderprint? Martin Holst Swende (Jun 14)
- Re: Java RMI service finderprint? Gabriel Lawrence (Jun 14)
- Re: Java RMI service finderprint? David Fifield (Jun 15)
- Re: Java RMI service finderprint? Gabriel Lawrence (Jun 15)
- Re: Java RMI service finderprint? David Fifield (Jun 15)
- Re: Java RMI service finderprint? Martin Holst Swende (Jun 15)