Apache OpenMeetings "provides video conferencing, instant messaging, white board, collaborative document editing and other groupware tools using API functions of the Red5 Streaming Server for Remoting and Streaming."
For our testing, OpenMeetings was installed on Ubuntu 16.04 using the default-jre (OpenJDK 1.8.0_91) and version 3.1.1 downloaded on May 5, 2016 (apache-openmeetings-3.1.1.zip - 7055984f5f9fe617585f2cd443d95ec2). The normal installation process was followed (run red5.sh and use the webinstaller).
The guide for OpenMeetings states that TCP ports 5080 and 1935 are used by default. The guide also mentions that red5 server, the open source media stream that OpenMeetings builds upon, also "uses some ports internally. However those parts are not in use … by default".
A quick examination of the listening ports on the test box reveals:
pangolin@brazil:~/Downloads$ netstat -tlnp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN -
tcp6 0 0 :::9998 :::* LISTEN 6529/java
tcp6 0 0 :::1935 :::* LISTEN 6529/java
tcp6 0 0 :::9999 :::* LISTEN 6529/java
tcp6 0 0 :::8081 :::* LISTEN 6529/java
tcp6 0 0 :::5080 :::* LISTEN 6529/java
As you can see, it installs with Java listeners on additional ports including TCP 8081, 9998, and 9999.
RMI Registry
Nessus has a useful little script called rmiregistry_detect.nasl. With a small tweak you can point it at any port (e.g. TCP 9999 in this case) and you see:
----------[ Executing ./rmiregistry_detect.nasl ]------
Here is a list of objects the remote RMI registry is currently
aware of :
rmi://127.0.1.1:9998/red5
----------[ Finished ./rmiregistry_detect.nasl ]------
And there we have it, there is an RMI Registry bound to 0.0.0.0:9999. To red5 users, this shouldn’t be surprising. In fact, googling "red5 rmi" leads to articles talking about it as far back as 2009.
RMI Registry Exploitation
We won’t rehash all of the Java deserialization discussion over the last years, but it is well established at this point that RMI Registries are vulnerable to deserialization attacks. That means an attacker just needs the correct libraries to be on the Classpath. Fortunately for attackers, OpenMeetings appears to collect ‘em all! Collections, BeanUtils, FileUpload, Wicket-Util, Groovy, Spring, Jython, and c3p0 are all present. Oh happy days!
For exploitation, Chris Frohoff’s RMIRegistryExploit.java works here. However, for ease of use we’ve developed a Python script that will execute “touch /tmp/tenable_was_here” to demonstrate the issue for the vendor. We found it somewhat amusing that the connection is rejected by the server because it isn't from localhost, but that comes a bit too late:
java.rmi.AccessException: Registry.Registry.bind disallowed; origin /192.168.1.10 is non-local host
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:421)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:272)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
Sample output:
pangolin@brazil:~$ python openmeetings_rmi.py 192.168.1.5
[+] Connecting to the RMI registry at 192.168.1.5:9999
[+] Initiating JRMI handshake
[+] Sending commons collections exploit payload
[+] fin
One might assume that system administrators would filter TCP port 9999. Perhaps, but a quick look at the OpenMeetings demo server showed that you can establish a TCP connection to that port.