Re: Java RMI service finderprint?

[David Fifield <david () bamsoftware com>]

On Tue, Jun 14, 2011 at 08:22:02AM -0700, 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.
>
> 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.

This is what --version-intensity is for. If you want more probes to be
sent, increase the number. The default intensity is 7, just below the
rarity vlue of the JavaRMI probe which is 8.

Rather than declaring the probe to be valid for almost every port, it
would be better to just decrease the rarity. But keep in mind that this
is going to slow down everybody's scans. I haven't yet seen evidence
that Java RMI is common enough to justify doing that. Is --version-all
good enough to work around this?

> 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?

That's what --version-all does.

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