Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] Red5 Server RMI Registry /red5 Java Deserialization Remote Code Execution

Critical

Synopsis

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.

Solution

red5 has released Red5 Server 1.0.8-M3 which addresses the issue. Apache has released OpenMeetings 3.1.2 which includes an updated Red5 implementation, mitigating the flaw.

Disclosure Timeline

2016-05-05 - Issue Discovered
2016-05-23 - Submitted to ZDI for consideration, case bainesjr0009 opened
2016-05-26 - ZDI declines as they have no interest in this product.
2016-05-30 - Issue reported to Apache via security@apache.org
2016-05-31 - Apache replies, will close port 9999 on demo server.
2016-05-31 - Tenable asks about disabling the 0.0.0.0 binding by default and upgrading Commons Collection library
2016-06-03 - Vendor says RMI registry removed in 1.0.8-M2 pre-release of red5-server
2016-06-15 - Tenable confirms turning off 0.0.0.0 binding is good, generally acks Apache's last mail.
2016-07-20 - Ping vendor for 1.0.8 release ETA
2016-07-21 - Apache thinks ~2 weeks, working through other build issues, other lib vulns
2016-08-18 - Ping Apache for update.
2016-08-18 - Vendor says addressed in commit e78d67d
2016-08-18 - Ask Apache if that is included in OpenMeetings 3.1.2 release
2016-08-18 - Vendor and Apache confirms fix in Red5 1.0.8-M6 and OpenMeetings 3.1.2

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email advisories@tenable.com