Java AMF3 deserialization vulnerability analysis-vulnerability warning-the black bar safety net

AMF Action Message Format is a binary serialization format, before the main Flash application in using this format. Recently, the Code White found to have multiple Java AMF library in the presence of vulnerabilities, and these vulnerabilities will lead to unauthenticated remote code execution. Since the AMF has been widely used, so there may be a number of manufacturers of products will be affected by these vulnerabilities, such as Adobe, Atlassian, HPE, SonicWall and VMware, and so on.
Currently, the vulnerability-related information has been reported to the U.S. CERT, please refer to us-CERT VU#307983）
Overview
Currently, the Code White is mainly for the following several popular Java AMF to achieve:
Flex BlazeDS by Adobe
Flex BlazeDS by Apache
Flamingo AMF Serializer by Exadel (discontinued)
GraniteDS (discontinued)
WebORB for Java by Midnight Coders
And these, in turn, there is the following listed in one or more of the vulnerabilities:
XML external entity injection XXE）
Any object creation and property setting
Through the RMI implementation of the Java serialization
Vulnerability
In short, any remote attacker who is able to deceive and control server of the communication connection, then he will likely to the target host is sent to be able to execute arbitrary code serialized Java object, when the object on the target host, deserialized after the malicious code will be executed.
The first two vulnerabilities are not a new vulnerability, but there are still a lot of inventory in such vulnerability. In addition, the researchers also found a way to convert this design defect is converted into Java serialization vulnerability of the method.
! [](/Article/UploadPic/2017-4/2017473719284. png? www. myhack58. com)
We will be the above-mentioned vulnerability, in addition to the XXE for a detailed description, if you want to know about this XXE vulnerability of the detailed content, please refer to our previously published an article on the CVE-2015-3269: Apache Flex BlazeDS XXE Vulnerabilty action.
Description
AMF3 Action Message Format version 3, also is a kind of binary information encoding format, it is also a Flash application in the background interaction when the main use of a data format. The JSON is similar, it supports different data types. Taking into account the backward compatibility, AMF3 is actually regarded as the AMF of a development to achieve, and introduces new types of objects.
AMF3 object, the new function can be attributed to two new additions to the characteristic, and these two new features of dynamic and externalizable describes the object how to serialize operations:
Dynamic: a statement of the dynamic characteristics of the class instance; public variable members can be in the program runtime to dynamically add or Delete to the instance.
Externalizable: to achieve the flash. utils. IExternalizable and completely controls its members of the serialized class instance.
Note: Please refer to the official Adobe explanation given【portal】。
Dynamic characteristics
We can take the Dynamic characteristics of the JavaBeans features comparison: it allows us to through the class name and properties to create an object. In fact, many of the JavaBeans entity currently have implemented this technology, such as java. beans. Introspector, the Flamingo, Flex BlazeDS and WebORB, etc.
But note that this function will result in an exploitable vulnerability is generated. In fact, Wouter Coekaerts back in 2011 it has been such a presence in AMF implementation of vulnerability exposure, and also in the 2016 release of the corresponding vulnerabilities of exploit code and PoC.
Externalizable characteristics
We can get Externalizable characteristics depend on Java java. io. Externalizable interface for comparison. In fact, many manufacturers already have the flash. utils. The IExternalizable interface specification for the adjustment, in fact it is with Java java. io. Externalizable is not much different, this feature will allow we can efficiently implement java. io. Externalizable interface of the class to be reconstructed.
java. io. Externalizable interface defines two methods: namely readExternal java. io. ObjectInput and writeExternal java. io. ObjectInput, and these two methods will allow a java class to completely control the serialization and deserialization operations. This also means that, in the program running process does not exist in the default serialization to / deserialization behavior and the effectiveness of the detection. Therefore, with respect to java. io. Serializable, we use java. io. Externalizable to achieve serialization to / deserialization is more simple and efficient.
The EXTERNALIZABLE. READEXTERNAL converted to OBJECTINPUTSTREAM. READOBJECT
In OpenJDK 8u121 a total of fifteen class implements the java. io. Externalizable interface, and wherein the majority of the class’s task is merely to reconstruct a state of the object. In addition, the actual transfer to the Externalizable. readExternal java. io. ObjectInput method of the java. io. ObjectInput instance it is not java. io. ObjectInputStream instance.
In this fifth class, those with the RMI-related classes to attract our attention. Especially in the sun. rmi. server. UnicastRef and sun. rmi. server. UnicastRef2 because they will through the sun. rmi. transport. LiveRef. read(ObjectInput in, boolean)method to the sun. rmi. transport. LiveRef object to be reconstructed. In addition, this method also reconstruct a sun. rmi. transport. tcp. TCPEndpoint objects as well as a local sun. rmi. transport. LiveRef object, and in the sun. rmi. transport. DGCClient in to register. Wherein DGCClient responsible for achieving the client’s RMI distributed garbage collection system. DGCClient the external interface for the“registerRefs”method, when a LiveRef to the remote object need access to the virtual machine system, it needs to be in DGCClient in to register. On DGCClient more content please refer to the OpenJDK to the official document【portal】。
According to the official document description, LiveRef registration is made once the remote call is complete, and we think it will be possible to allow us through RMI to implement remote code execution RCE）！
In this call to the trace analysis, we found that the whole call process is very complex, it relates to Externalizable. readExternal, sun. rmi. server. UnicastRef/sun. rmi. server. UnicastRef2 And ObjectInputStream. the readObject and the sun. rmi. transport. StreamRemoteCall. executeCall (), etc. a variety of objects and methods.
! [](/Article/UploadPic/2017-4/2017473719653. png? www. myhack58. com)
Next, let’s see if we by a sun. rmi. server. UnicastRef object to an AMF message to be deserialized then what happens, the relevant code is shown below using a Flex BlazeDS: the
import java. io. ByteArrayInputStream;
import java. io. ByteArrayOutputStream;
import java. io. IOException;
import java. util. Arrays;
import flex. messaging. io. SerializationContext;

[1] [2] next