Re: Java RMI service finderprint?

[Martin Holst Swende <martin () swende se>]

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/