Re: NSE: RMI Dumpregistry

[David Fifield <david () bamsoftware com>]

On Sun, Aug 08, 2010 at 09:17:41PM +0200, Martin Holst Swende wrote:
> > 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.

Okay, I will consider this deferred until you test with Patrik's library
(and I catch up with all of Patrik's submissions).

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

I'm not aware of any test like this. Perhaps we should reduce the rarity
of the JavaRMI probe, which is currently at 8. Making it 7 or lower
would cause it to run by default. Even with that, it would help to make
a larger list of common RMI ports, so that the RMI probe can be
prioritized for them. Right now we only have the ports

ports 706,1098,1099,1981

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