In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Sivathmican Sivakumaran and John Simpson of the Trend Micro Research Team detail a recent code execution vulnerability in Adobe ColdFusion. The bug was originally discovered and reported by Moritz Bechler of SySS GmbH. The following is a portion of their write-up covering CVE-2019-7839, with a few minimal modifications.
A remote code execution vulnerability has been reported in Adobe ColdFusion. This vulnerability is due to the JNBridge binary protocol port being exposed without any authentication.
A remote unauthenticated attacker can exploit this vulnerability by sending a crafted JNBridge binary protocol message to an affected server. Successful exploitation results in remote code execution as the root or SYSTEM user.
The Vulnerability
Adobe ColdFusion is an application development platform by Adobe Systems. It is an IDE used to develop web applications and supports a full scripting language, ColdFusion Markup Language (CFML). Since ColdFusion MX 6.0, the server component runs within a Java Runtime Environment (JRE).
JNBridge is 3rd-party software that provides interoperability between Java and Microsoft .NET frameworks. Java and Microsoft .NET frameworks can communicate with each other via the JNBridge Binary Protocol, SOAP Protocol, or in-memory communication. ColdFusion 2016 and ColdFusion 2018 ship with JNBridge. This JNBridge server uses the JNBridge Binary Protocol and listens on TCP port 6093 or 6095 by default.
The JNBridge Binary Protocol is not publicly documented and the following was derived through reverse engineering jnbcore.jar
. A JNBridge Binary Protocol message has the following format:
The Data
field contains a class name, method name, method signature and method arguments data as length-value encoded UTF-16 strings. Upon receiving a JNBridge Binary Protocol message, the server will invoke the method specified by the Data section with the specified arguments.
The JNBridge Server is accessible on TCP port 6093 or 6095 without any access control. JNBridge by design allows instantiation of arbitrary classes and invocation of arbitrary methods. When the JNBridge server receives a JNBridge Binary Protocol message, BinaryRequestHandler.handleRequest()
is called. handleRequest()
extracts the class, method, method signature and method arguments data by calling deserializeCall()
. This data is stored in a CallArgs
object. The server then attempts to invoke the specified method by calling JNBDispatcher.call()
. call()
will select an appropriate internal method based on the requested method signature. For example, a call to a static method with a void return value results in a call to voidStaticCall()
. voidStaticCall()
will select the specified class and invoke the specified method by reflection using java.lang.reflect.Method.invoke()
.
Source Code Walkthrough
The following code snippet was taken from jnbcore.jar
in ColdFusion 2018 update 3 which ships with JNBridgePro v7.3.1 (.NET 4.0/4.5/4.6-targeted). Comments added by Trend Micro have been highlighted.
From BinaryRequestHandler.class
:
From JNBDispatcher.class
:
The Exploit
Here’s a quick video showing the exploit in action:
The Patch
Adobe addressed this bug with APSB19-17, which was released in June 2019. The update disables remote access to connections made in the .NET-to-Java direction within JNBridge. To enable remote access, the client IP address must be whitelisted within neo-dotnet.xml.
Since JNBridge allows arbitrary code execution by design, it is impossible to distinguish normal traffic from attack traffic. As recommended by the vendor, the best remediation would be to block all JNBridge Binary Protocol messages to TCP port 6093 or 6095.
Special thanks to Sivathmican Sivakumaran and John Simpson of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.
The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.