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 12:21:22 +0200

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/


  By Date           By Thread  

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