Re: NSE: RMI Dumpregistry

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

On 08/03/2010 08:18 PM, David Fifield wrote:
> On Sun, Jun 20, 2010 at 12:31:33AM +0200, Martin Holst Swende wrote:
>   
> > I have (inspired by [1]) implemented an nse script which connects to a
> > Java RMI Registry and dump out the names of all bound objects. It then
> > loops over those names and performs lookup, which retrieves some more
> > info, namely the class hash, the implemented interfaces and superclass
> > hierarchy.
> >
> > I imagine this can be quite useful since it may tell quite a bit about
> > the application - depending on how it uses the registry. For example, if
> > the app uses JMX (Java Management eXtensions) which is a kind of
> > framework to administer any java application remotely, the registry will
> > contain a "jmxconnector" object. There may be quite a handful of
> > applications which could be fingerprinted by the object names in the
> > registry, but I have not performed extensive testing on that.
> >
> > Also, if the objects are of a public type, i.e you can download the
> > class-files from somewhere, it is a giveaway that it is possible to
> > explore the app further using native java RMI instead, and interact
> > directly with the application. If they are proprietary or hidden, the
> > interface name or object name may still provide useful input for
> > fingerprinting.
> >
> > The script uses a library for RMI, which is included in the attachment.
> > I have written quite a lot of documentation inside the library, so I'll
> > keep it short here. It can invoke simple methods over RMI, and one thing
> > I think would be very nice to use it for as a next project, is to write
> > a bruteforcer for jmx. It seems to be pretty simple (the network dump I
> > looked at while connecting to a JMX console with JConsole showed the
> > password in plain text - so it seems to not even to be a
> > challenge-response process). It should also be possible to use the
> > library to skip the registry-lookup and  connect directly to other
> > stuff, if you know what the application is (and know what object id's
> > are addressable and how their method signature look) - e.g write another
> > script to interact with Neo4j or some other RMI based java app.
> >
> > Files are attached, but also available from
> > http://martin.swende.se/hgwebdir.cgi/nsescripts/
> >     
> Forgive me for taking so long to respond to this. I like the script and
> library. Here are the results of my testing. I tried running the test
> RMI server from
> http://download.oracle.com/javase/1.5.0/docs/guide/rmi/hello/hello-world.html,
> but apparently all that is needed is to run the rmiregistry command.
>
> First, here is running against localhost, with the rmiregistry from Java
> IcedTea 1.6.0.
>
> Initiating NSE at 12:04
> NSE: NSE Script Threads (1) running:
> NSE: Starting rmi-dumpregistry against 127.0.0.1:1099.
> NSE: RMI:RMI-Ack received (host 127.0.0.1, port: 54010)
> NSE: RMI:Registry connection OK nil
> NSE: RMI:Invoking object 0, hash 44154dc9d4e63bdf, opNum 1, args nil
> NSE: RMI:Ignoring responsetype: 77
> NSE: RMI:Reading ordinary object
> NSE: RMI:Reading TC_CLASSDESC
> NSE: RMI:Classname: "java.rmi.MarshalException"
> NSE: RMI:Reading TC_CLASSDESC
> NSE: RMI:Classname: "java.rmi.RemoteException"
> NSE: RMI:Field description: name: detail, type: Ljava/lang/Throwable;
> NSE: RMI:Reading TC_CLASSDESC
> NSE: RMI:Classname: "java.io.IOException"
> NSE: RMI:Reading TC_CLASSDESC
> NSE: RMI:Classname: "java.lang.Exception"
> NSE: RMI:Reading TC_CLASSDESC
> NSE: RMI:Classname: "java.lang.Throwable"
> NSE: RMI-ERR:Not implemented, readTypeString(TC_REFERENCE)
> NSE: RMI:Field description: name: false, type: primitive type: ()
> NSE: RMI:Field description: name: L, type: primitive type: (~)
> NSE: RMI-ERR:ERROR; not impl: UNKNOWN
> NSE: RMI:TC_classdesc is other 100
> NSE: Finished rmi-dumpregistry against 127.0.0.1:1099.
>
>
> Here it is, with a packet trace, running against the rmiregistry that
> comes with Debian Etch. From the exception messages that version
> detection causes, it appears to be the one from libgcj.
>
> Initiating NSE at 12:10
> NSE: NSE Script Threads (2) running:
> NSE: Starting rmi-dumpregistry against 192.168.0.2:1099.
> NSE: Starting skypev2-version against 192.168.0.2:1099.
> NSE: TCP 192.168.0.21:34165 > 192.168.0.2:1099 | CONNECT
> NSE: TCP 192.168.0.21:34166 > 192.168.0.2:1099 | CONNECT
> NSE: TCP 192.168.0.21:34165 > 192.168.0.2:1099 | 00000000: 4a 52 4d 49 00 02 4b                            JRMI  K
>
> NSE: TCP 192.168.0.21:34166 > 192.168.0.2:1099 | 00000000: 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 30 0d 0a GET / 
> HTTP/1.0
> 00000010: 0d 0a
>
> NSE: TCP 192.168.0.21:34165 < 192.168.0.2:1099 | 00000000: 4e 00 09 6c 6f 63 61 6c 68 6f 73 74 00 00 04 4b N  
> localhost   K
>
> NSE: RMI:RMI-Ack received (host localhost, port: 1099)
> NSE: TCP 192.168.0.21:34165 > 192.168.0.2:1099 | 00000000: 00 09 31 32 37 2e 30 2e 30 2e 31 00 00 00 00      127.0.0.1
>
> NSE: RMI:Registry connection OK nil
> NSE: RMI:Invoking object 0, hash 44154dc9d4e63bdf, opNum 1, args nil
> NSE: TCP 192.168.0.21:34165 > 192.168.0.2:1099 | 00000000: 50 80 00 00 05 77 22 00 00 00 00 00 00 00 00 00 P    w"
> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00000020: 01 44 15 4d c9 d4 e6 3b df                       D M   ;
>
> NSE: Finished rmi-dumpregistry against 192.168.0.2:1099.
> NSE: TCP 192.168.0.21:34165 > 192.168.0.2:1099 | CLOSE
> NSE: TCP 192.168.0.21:34166 > 192.168.0.2:1099 | CLOSE
> NSE: Finished skypev2-version against 192.168.0.2:1099.
> Completed NSE at 12:10, 30.01s elapsed
> Nmap scan report for 192.168.0.2
> Host is up, received arp-response (0.00032s latency).
> Scanned at 2010-08-03 12:08:08 MDT for 163s
> PORT     STATE SERVICE REASON  VERSION
> 1099/tcp open  unknown syn-ack
> 1 service unrecognized despite returning data. If you know the service/version, please submit the following 
> fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
> SF-Port1099-TCP:V=5.35DC18%I=7%D=8/3%Time=4C585B19%P=i686-pc-linux-gnu%r(J
> SF:avaRMI,10,"N\0\tlocalhost\0\0\x04K");
>
>   
Just running the rmiregistry would suffice, however, it would not
produce anything useful since the objective is to dump out the names of
the objects in there. I am not sure about the errors above, but there
are several parts of RMI which are not implemented, also Patrik Karlsson
pointed out to me that I had left the socket timout to 0.5 s (what I use
when developing locally).

My implementation of java deserialization was based on OpenJdk
implementation, and I tried to keep the structure as close to the
original implementation as possible. However, the resulting library is
not very beautiful code (the java serialization parts), and it turned
out that Patrik had a java deserialization library "lying around" (which
you may have seen in his latest mail). I will make necessary changes and
change my RMI-library to use that (or a modified version of it) instead,
since it is written in a very nice OO-fashion and is not as messy as the
openjdk based version. Also, I think it is more complete.

After my changes, I will perform testing with the same setup you used also.

>   
> > ps. One problem I run into pretty often is that RMI is often not
> > detected, since different apps tend to open ports on different places.
> > They are usually only found using --version-all, so it makes it
> > difficult to run the script. Would it be possible to include the
> > rmi-payload less restrictively?
> >     
> If it's limited to a few dozen common ports, we can just enumerate all
> of them specifically. If it really varies a lot, and rmiregistry is
> really common, then we can reduce the rarity.
>   

It is not rmiregistry I am talking about, specifically, but RMI services
in general. There are loads of rmi services - databases, fat clients,
backup systems, consoles etc, and they are found on a lot of different
ports (the registry are probably just a handful of ports).

It would be interesting to make a test.
1. Scan (-sV) a random port on a random host.
2. Each time an open unidentified port turns out, do "-sV --version-all"
on it.
3. Each time one port goes from unidentified to identified by
--version-all, add a point on the scoreboard for that service-probe (or
service, perhaps).
4. Continue until a list has stabilised - if any services are very much
ahead of the rest, those should get lower rarity.

My guess is that rmi would pop up close to the top. Has anyone done
testing like this?

/Martin


> David Fifield
> _______________________________________________
> 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/