Re: Java RMI service finderprint?

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

On 06/14/2011 10:08 AM, Patrik Karlsson wrote:
> > Folks,
> >
> > I'm looking at finding different Java RMI servers on my network.
> >
> > With some help from Brandon we put together this fingerprint:
> >
> > ##############################NEXT PROBE##############################
> > Probe TCP java-rmi q|\x4a\x52\x4d\x49\x00\x02\x4b|
> > rarity 7
> > ports 1024-65535
> >
> > match java-rmi m|^\x4e\0[\x00-\x0f]([0-9.]+)\0| p/Java Remote Method
> > Invocation/ i/Client IP: $1/
> >
> > But, I noticed that these already existed:
> >
> > ##############################NEXT PROBE##############################
> > Probe TCP JavaRMI q|\x4a\x52\x4d\x49\0\x02\x4b|
> > rarity 8
> > ports 706,1098,1099,1981
> >
> > match jrmi m|^\x4e..[0-9.]+\0\0..$|s p/Java RMI/
> > match jrmi m|^\x4e..([\w._-]+)\0\0..$|s p/GNU Classpath grmiregistry/
> > h/$1/
> >
> > There really isnt a well known port for Java RMI. So... I'm wondering what
> > history there is for the choice of ports and if its possible to open up
> > the
> > idea of expanding these to look at all the non-priv ports.

I don't know the full answer, but I guess that 1098 and 1099 comes from
them being default ports for the java rmi registry (primary and secondary).

> I skimmed through the nmap-service-probes file and couldn't find another
> case where such a broad range was specified.
> Wouldn't it have a considerable impact on overall scan times?
> I think this is another case that would qualify for the force or "named
> probe" approach where selected probes or scripts could be selected to run
> against every open port.
> I tried to look at implementing and estimating the effort for writing a
> PoC for "named probes" but didn't get very far and I'm back working on
> some more scripts instead.

This has been discussed before on the list; e.g
http://seclists.org/nmap-dev/2010/q3/288 . I think "named probes" are a
great idea for helping out here. If someone was to do some proper
research regarding the prevalence of rmi in the wild, it would probably
be easier to make these kinds of calls.
Perhaps a GSOC idea for next year? Scan the interwebz, and optimize the
probes, rarities and port numbers. Plus: find new fingerprints to
investigate manually.

Regarding the fact that rmi-dumpregistry looks at "rmi" but the service
is called "jrmi" : that would be  my bad. But I'll have to ask someone
with cvs access to fix it.. ?
Also, looking at the example output from
http://seclists.org/nmap-dev/2010/q3/913 , I see that the script reports :

PORT     STATE SERVICE REASON
1099/tcp open  rmi     syn-ack
| rmi-dumpregistry: 
|   jmxrmi
|     javax.management.remote.rmi.RMIServerImpl_Stub
|     @127.0.1.1:40353
|     extends
|       java.rmi.server.RemoteStub
|       extends

|_        java.rmi.server.RemoteObject


Using the "rmi"-notation for service. I guess it too must be changed to
"jrmi". Thanks for the feedback!

Regards,
Martin Swende

> > Thanks,
> > gabe
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
> //Patrik
>
> --
> Patrik Karlsson
> http://www.cqure.net
> http://www.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/

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