Home page logo

nmap-dev logo 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):

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'!
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

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