java.lang.ClassNotFoundException: com.sun.corba.se.spi.logging.LogWrapperBase

[executionByFork]

Bug: ClassNotFoundException always printed

$ java -jar rmiscout-1.4-SNAPSHOT-all.jar -h
java.lang.ClassNotFoundException: com.sun.corba.se.spi.logging.LogWrapperBase
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:315)
        at com.bishopfox.rmiscout.RMIScout.disableAccessWarnings(RMIScout.java:75)
        at com.bishopfox.rmiscout.RMIScout.main(RMIScout.java:170)
usage: rmiscout [-h] MODE ...

Bruteforce and exploit RMI interfaces

named arguments:
  -h, --help             show this help message and exit

Modes of operation:
  MODE
    wordlist             Dictionary attack on RMI interfaces using a prototype wordlist
    bruteforce           Bruteforce attack on RMI interfaces
    exploit              Exploit RMI methods using type-mismatch deserialization attack
    probe                Use GadgetProbe  to  enumerate  classes  available  on  the remote
                         classpath
    invoke               Invoke methods using primitives or Strings
    list                 List available registry names

It seems any time that the rmiscout jar is run, the above stack trace about LogWrapperBase is printed. It seems as if the jar is working fine other than printing the error, but this is also the first time I am attempting to use it so I'm not sure if any functionality is affected.

I do have a server with an RMI port open according to nmap

...
41428/tcp open  java-rmi       Java RMI
...

However when running java -jar rmiscout-1.4-SNAPSHOT-all.jar list TARGET_IP 41428, the tool reports the following:

-- (LogWrapperBase exception snipped out) --
Server is offline or does not use RMI, RMI-SSL, or RMI-IIOP

Because of the exception, and the fact that nmap reports the port as an RMI service, I am worried that rmiscout is not working properly.

This jar file was directly downloaded from the repository releases page, v1.4 specifically. https://github.com/BishopFox/rmiscout/releases/tag/v1.4

Java version:

$ java --version
openjdk 11.0.7-ea 2020-04-14
OpenJDK Runtime Environment (build 11.0.7-ea+9-post-Debian-1)
OpenJDK 64-Bit Server VM (build 11.0.7-ea+9-post-Debian-1, mixed mode, sharing)

I am running Kali Linux if that matters for some reason.

$ uname -a
Linux hostname 5.7.0-kali1-amd64 #1 SMP Debian 5.7.6-1kali2 (2020-07-01) x86_64 GNU/Linux

[the-bumble]

Hi @executionByFork,

Happy to help!

The warnings are happening because RMIScout dependencies require JRE 8 (e.g., CORBA and ysoserial) so functionality is limited on newer JREs. For more details, see the troubleshooting section: https://github.com/BishopFox/rmiscout#troubleshooting

I've seen a few false positives for RMI from nmap (e.g., JNDI services). Would you mind sharing the results of the nmap rmi-dumpregistry script?

nmap --script rmi-dumpregistry <host> -p <port> -Pn

Thank you!

Jake

[executionByFork]

Hm, it seems the nmap script returns no output when used on that host and port (besides port info). The nmap script does return output when used on another host, which has RMI over the typical port 1099. So, I think this may actually be a false positive RMI finding from nmap.

Just to clarify, this nmap script always returns information when the service on the given port is RMI, right? So if no information is returned from the script, it can be assumed that the service is not RMI? Or are there instances you are aware of in which this script will return no output for an actual RMI port?

[the-bumble]

Yes, my guess is that it is likely a false positive RMI finding from NMAP. It's possible there may be a string literal "RMI" in the server response that is causing a false positive.

It's possible that it's a proprietary protocol and does not use JRMP/IIOP. Here was a previous instance of such a finding: https://github.com/BishopFox/rmiscout/issues/9#issuecomment-752239382

I hope that helps!

Jake