Vulnerabilities > CVE-2017-11238 - Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in Adobe products
Attack vector
NETWORK Attack complexity
MEDIUM Privileges required
NONE Confidentiality impact
PARTIAL Integrity impact
NONE Availability impact
NONE Summary
Adobe Acrobat Reader 2017.009.20058 and earlier, 2017.008.30051 and earlier, 2015.006.30306 and earlier, and 11.0.20 and earlier has an exploitable memory corruption vulnerability in the image conversion engine when processing Enhanced Metafile Format (EMF) data related to curve drawing. Successful exploitation could lead to arbitrary code execution.
Vulnerable Configurations
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Buffer Overflow via Environment Variables This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
- Overflow Buffers Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attackers' choice.
- Client-side Injection-induced Buffer Overflow This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.
- Filter Failure through Buffer Overflow In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered).
- MIME Conversion An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back.
Nessus
NASL family MacOS X Local Security Checks NASL id MACOSX_ADOBE_READER_APSB17-24.NASL description The version of Adobe Reader installed on the remote macOS or Mac OS X host is a version prior to 11.0.21, 2015.006.30355, 2017.011.30066, or 2017.012.20098. It is, therefore, affected by multiple vulnerabilities. Note that Nessus has not tested for these issues but has instead relied only on the application last seen 2020-06-01 modified 2020-06-02 plugin id 102430 published 2017-08-11 reporter This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/102430 title Adobe Reader < 11.0.21 / 2015.006.30355 / 2017.011.30066 / 2017.012.20098 Multiple Vulnerabilities (APSB17-24) (macOS) code # # (C) Tenable Network Security, Inc. # include("compat.inc"); if (description) { script_id(102430); script_version("1.7"); script_cvs_date("Date: 2019/11/12"); script_cve_id( "CVE-2017-3016", "CVE-2017-3038", "CVE-2017-3113", "CVE-2017-3115", "CVE-2017-3116", "CVE-2017-3117", "CVE-2017-3118", "CVE-2017-3119", "CVE-2017-3120", "CVE-2017-3121", "CVE-2017-3122", "CVE-2017-3123", "CVE-2017-3124", "CVE-2017-11209", "CVE-2017-11210", "CVE-2017-11211", "CVE-2017-11212", "CVE-2017-11214", "CVE-2017-11216", "CVE-2017-11217", "CVE-2017-11218", "CVE-2017-11219", "CVE-2017-11220", "CVE-2017-11221", "CVE-2017-11222", "CVE-2017-11223", "CVE-2017-11224", "CVE-2017-11226", "CVE-2017-11227", "CVE-2017-11228", "CVE-2017-11229", "CVE-2017-11230", "CVE-2017-11231", "CVE-2017-11232", "CVE-2017-11233", "CVE-2017-11234", "CVE-2017-11235", "CVE-2017-11236", "CVE-2017-11237", "CVE-2017-11238", "CVE-2017-11239", "CVE-2017-11241", "CVE-2017-11242", "CVE-2017-11243", "CVE-2017-11244", "CVE-2017-11245", "CVE-2017-11246", "CVE-2017-11248", "CVE-2017-11249", "CVE-2017-11251", "CVE-2017-11252", "CVE-2017-11254", "CVE-2017-11255", "CVE-2017-11256", "CVE-2017-11257", "CVE-2017-11258", "CVE-2017-11259", "CVE-2017-11260", "CVE-2017-11261", "CVE-2017-11262", "CVE-2017-11263", "CVE-2017-11265", "CVE-2017-11267", "CVE-2017-11268", "CVE-2017-11269", "CVE-2017-11270", "CVE-2017-11271" ); script_bugtraq_id( 100179, 100180, 100181, 100182, 100184, 100185, 100186, 100187, 100189 ); script_name(english:"Adobe Reader < 11.0.21 / 2015.006.30355 / 2017.011.30066 / 2017.012.20098 Multiple Vulnerabilities (APSB17-24) (macOS)"); script_summary(english:"Checks the version of Adobe Reader."); script_set_attribute(attribute:"synopsis", value: "The version of Adobe Reader installed on the remote host is affected by multiple vulnerabilities."); script_set_attribute(attribute:"description", value: "The version of Adobe Reader installed on the remote macOS or Mac OS X host is a version prior to 11.0.21, 2015.006.30355, 2017.011.30066, or 2017.012.20098. It is, therefore, affected by multiple vulnerabilities. Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number."); script_set_attribute(attribute:"see_also", value:"https://helpx.adobe.com/security/products/acrobat/apsb17-24.html"); script_set_attribute(attribute:"solution", value: "Upgrade to Adobe Reader 11.0.21 / 2015.006.30355 / 2017.011.30066 / 2017.012.20098 or later."); script_set_cvss_base_vector("CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C"); script_set_cvss_temporal_vector("CVSS2#E:H/RL:OF/RC:C"); script_set_cvss3_base_vector("CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"); script_set_cvss3_temporal_vector("CVSS:3.0/E:H/RL:O/RC:C"); script_set_attribute(attribute:"cvss_score_source", value:"CVE-2017-3124"); script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available"); script_set_attribute(attribute:"exploit_available", value:"true"); script_set_attribute(attribute:"exploited_by_malware", value:"true"); script_set_attribute(attribute:"vuln_publication_date", value:"2017/08/08"); script_set_attribute(attribute:"patch_publication_date", value:"2017/08/08"); script_set_attribute(attribute:"plugin_publication_date", value:"2017/08/11"); script_set_attribute(attribute:"plugin_type", value:"local"); script_set_attribute(attribute:"cpe", value:"cpe:/a:adobe:acrobat_reader"); script_end_attributes(); script_category(ACT_GATHER_INFO); script_family(english:"MacOS X Local Security Checks"); script_copyright(english:"This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof."); script_dependencies("macosx_adobe_reader_installed.nasl"); script_require_keys("Host/local_checks_enabled", "Host/MacOSX/Version", "installed_sw/Adobe Reader"); exit(0); } include("vcf.inc"); get_kb_item_or_exit("Host/local_checks_enabled"); os = get_kb_item("Host/MacOSX/Version"); if (empty_or_null(os)) audit(AUDIT_OS_NOT, "Mac OS X"); app_info = vcf::get_app_info(app:"Adobe Reader"); base_dir = app_info['path'] - "/Applications"; track = get_kb_item("MacOSX/Adobe_Reader"+base_dir+"/Track"); if (!isnull(track) && track == '2017') { constraints = [ { "min_version" : "17.8", "fixed_version" : "17.11.30066" } ]; } else { constraints = [ { "min_version" : "11", "fixed_version" : "11.0.21" }, { "min_version" : "15.6", "fixed_version" : "15.6.30355" }, { "min_version" : "15.7", "fixed_version" : "17.12.20098" } ]; } vcf::check_version_and_report(app_info:app_info, constraints:constraints, severity:SECURITY_HOLE);NASL family Windows NASL id ADOBE_ACROBAT_APSB17-24.NASL description The version of Adobe Acrobat installed on the remote Windows host is a version prior to 11.0.21, 2015.006.30355, 2017.011.30066, or 2017.012.20098. It is, therefore, affected by multiple vulnerabilities. Note that Nessus has not tested for these issues but has instead relied only on the application last seen 2020-06-01 modified 2020-06-02 plugin id 102427 published 2017-08-11 reporter This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/102427 title Adobe Acrobat < 11.0.21 / 2015.006.30355 / 2017.011.30066 / 2017.012.20098 Multiple Vulnerabilities (APSB17-24) NASL family Windows NASL id ADOBE_READER_APSB17-24.NASL description The version of Adobe Reader installed on the remote Windows host is a version prior to 11.0.21, 2015.006.30355, 2017.011.30066, or 2017.012.20098. It is, therefore, affected by multiple vulnerabilities. Note that Nessus has not tested for these issues but has instead relied only on the application last seen 2020-06-01 modified 2020-06-02 plugin id 102428 published 2017-08-11 reporter This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/102428 title Adobe Reader < 11.0.21 / 2015.006.30355 / 2017.011.30066 / 2017.012.20098 Multiple Vulnerabilities (APSB17-24) NASL family MacOS X Local Security Checks NASL id MACOSX_ADOBE_ACROBAT_APSB17-24.NASL description The version of Adobe Acrobat installed on the remote macOS or Mac OS X host is a version prior to 11.0.21, 2015.006.30355, 2017.011.30066, or 2017.012.20098. It is, therefore, affected by multiple vulnerabilities. Note that Nessus has not tested for these issues but has instead relied only on the application last seen 2020-06-01 modified 2020-06-02 plugin id 102429 published 2017-08-11 reporter This script is Copyright (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/102429 title Adobe Acrobat < 11.0.21 / 2015.006.30355 / 2017.011.30066 / 2017.012.20098 Multiple Vulnerabilities (APSB17-24) (macOS)
Seebug
bulletinFamily exploit description During my research into the Java Remote Method Invocation (RMI) protocol, the most common RMI service that I came across was Adobe ColdFusion’s Flex integration service which is used to support integration between Flash applications and ColdFusion components. A quick look at this service led to the discovery of two Java deserialization vulnerabilities, both leading to unauthenticated RCE in a service that runs under the local SYSTEM account by default. Adobe released a [security update](https://helpx.adobe.com/security/products/coldfusion/apsb17-30.html) on the 12th September 2017 for ColdFusion 11 and ColdFusion 2016 which can be installed through the ColdFusion Administrator application, however this update alone is not sufficient. Adobe ColdFusion comes bundled with its own Java runtime environment (JRE), which must be manually updated for the update to be effective. The end-of-life ColdFusion 9 is also known to be affected, however no supported fix was available at the time of writing. Update (13/10/2017): To clarify, this vulnerability affects the Java RMI service and does not affect HTTP(S) services exposed by ColdFusion. ### The Vulnerability: RMI and java.lang.Object The first thing I did when I started researching RMI was to write some code to enumerate RMI endpoints (which eventually became [BaRMIe](https://github.com/NickstaDB/BaRMIe)). The goal was to identify software that used RMI which I could investigate further. I used Shodan to find targets for enumeration, then enumerated those targets using BaRMIe. The following class was the most commonly exposed: ``` coldfusion.flex.rmi.DataServicesCFProxy ``` The problem with RMI services is that we can’t interact with them without access to the relevant Java interface or stub class, so I downloaded a trial version of Adobe ColdFusion 2016 and installed it in a virtual machine. With ColdFusion installed I did a recursive grep over the installation directory for the above class name “DataServicesCFProxy” which guided me to the file “lib/cfusion.jar”. I opened this file up in JD-GUI to find the class (interface) listed above. ``` package coldfusion.flex.rmi; import java.rmi.Remote; import java.rmi.RemoteException; import java.util.List; import java.util.Map; public abstract interface DataServicesCFProxy extends Remote { public abstract List fill(String paramString, Object[] paramArrayOfObject, Map paramMap) throws RemoteException; public abstract List sync(String paramString, List paramList, Map paramMap) throws RemoteException; public abstract Object get(String paramString, Map paramMap1, Map paramMap2) throws RemoteException; public abstract Integer count(String paramString, Object[] paramArrayOfObject, Map paramMap) throws RemoteException; public abstract boolean fillContains(String paramString, Object[] paramArrayOfObject, Object paramObject, Boolean paramBoolean, Map paramMap) throws RemoteException; } ``` Each of the five methods of this interface accept arbitrary Java objects as parameters either directly or indirectly (List and Map can both contain arbitrary Java objects). The RMI protocol uses Java serialization for method parameters so each of these five methods can be used as an entry point for a Java deserialization attack by passing a specially crafted object to the method. ### The Payload For a complete Java deserialization exploit we need two key components – the entry point (detailed above) and a payload. The payload consists of one or more classes with properties configured in such a way that some useful code is executed when the object is deserialized. For those not familiar with Java deserialization attacks, there’s an awesome tool called ysoserial which generates Java deserialization payloads using classes found in common Java libraries. Unfortunately the version of ColdFusion I had installed was not affected by any of the ysoserial payloads, and in fact Adobe released a [security update](https://helpx.adobe.com/uk/security/products/coldfusion/apsb16-16.html) in May 2016 which updated the bundled Apache Commons Collections library from version 3.2.1 to version 3.2.2, protecting ColdFusion against what is probably the best known Java deserialization payload. On further investigation I came across the file “libs/js.jar”, which is the Mozilla Rhino JavaScript library. There is a deserialization payload for this library available in ysoserial but it didn’t affect my lab environment. I also couldn’t find any information indicating that a deserialization issue had been fixed in this library (whereas details of the [Apache Commons Collections vulnerability](https://commons.apache.org/proper/commons-collections/security-reports.html) were published). Using Wireshark to look at the network traffic I spotted the following:  A “java.io.InvalidClassException” stating that the local class was incompatible and listing the “serialVersionUID” of both the local and remote classes. Helpful! The serialVersionUID field of a class is usually generated automatically by Java and is updated whenever [certain “incompatible” changes](http://docs.oracle.com/javase/6/docs/platform/serialization/spec/version.html#6678) are made to the class. Depending on usage, however, it is entirely possible for these changes to be made without introducing an incompatibility. I fired up a hex editor, loaded up the Mozilla Rhino payload bytes that I had generated using ysoserial, and searched for the local serialVersionUID listed in the exception. I modified the value to match the remote serialVersionUID and fired the payload off again whilst monitoring the network traffic with Wireshark. I had to repeat this process several times to fix all of the serialVersionUID values, but eventually I got this:  ### Outdated JRE The other of the two vulnerabilities is simply that ColdFusion comes bundled with an outdated version of Java. The bundled Java version does not attempt to validate the type of objects received in an RMI Registry.bind() request before deserializing them. It also fails to check that the bind request came from localhost prior to deserializing the object. This presents another entry point for Java deserialization attacks. id SSV:96733 last seen 2017-11-19 modified 2017-10-18 published 2017-10-18 reporter Root title Adobe ColdFusion Deserialization RCE (CVE-2017-11283, CVE-2017-11238) bulletinFamily exploit description In October 2017 I published an overview and video proof-of-concept of a [Java RMI/deserialization vulnerability](https://nickbloor.co.uk/2017/10/13/adobe-coldfusion-deserialization-rce-cve-2017-11283-cve-2017-11238/) affecting the Flex Integration service of Adobe ColdFusion. I held off on publishing all of the details and exploit code at the time because I spotted an additional exploit payload that could be used against a patched server. A further [security update](https://helpx.adobe.com/security/products/coldfusion/apsb18-14.html) has now been released by Adobe, so read on for more details. ### RMI and java.lang.Object The Java remote method invocation (RMI) protocol is almost 100% [Java serialization](https://nickbloor.co.uk/2017/08/13/attacking-java-deserialization/). When an object is requested from an RMI registry service and methods are invoked on that object, the data transmitted over the network is in the Java serialization format. ColdFusion’s Flex integration RMI service exposes an object of the following class: ``` coldfusion.flex.rmi.DataServicesCFProxy ``` This class can be found in the file “libs/cfusion.jar” in the ColdFusion installation directory, and looks like the following: Java ``` package coldfusion.flex.rmi; import java.rmi.Remote; import java.rmi.RemoteException; import java.util.List; import java.util.Map; public abstract interface DataServicesCFProxy extends Remote { public abstract List fill(String paramString, Object[] paramArrayOfObject, Map paramMap) throws RemoteException; public abstract List sync(String paramString, List paramList, Map paramMap) throws RemoteException; public abstract Object get(String paramString, Map paramMap1, Map paramMap2) throws RemoteException; public abstract Integer count(String paramString, Object[] paramArrayOfObject, Map paramMap) throws RemoteException; public abstract boolean fillContains(String paramString, Object[] paramArrayOfObject, Object paramObject, Boolean paramBoolean, Map paramMap) throws RemoteException; } ``` Each of these methods can be called with any Java object as a parameter. Note that containers such as List and Map can contain any Java object. No authentication is required to interact with this RMI service, so anyone who can reach the service over a network can supply arbitrary Java objects to it in an attempt to exploit a Java deserialization attack (e.g. by supplying [ysoserial](https://github.com/frohoff/ysoserial) payloads as method parameters). Unfortunately none of the ysoserial payloads worked against this entry point. In my previous post about ColdFusion CVE-2017-11283 and CVE-2017-11284 I talked about how I modified a ysoserial payload to successfully exploit this entry point and gain remote command execution using the Mozilla Rhino JavaScript library. In this case, the technique and entry point remain the same, but we’re targeting the [ROME](https://rometools.github.io/rome/) library which comes bundled with ColdFusion (see “libs/rome-cf.jar”). ### Exploitation – The Easy Way The following is a simple RMI client program that retrieves a ColdFusion DataServicesCFProxy object from an RMI registry service, then calls the remote count() method with null parameters: ``` package nb.barmie.demo; import coldfusion.flex.rmi.DataServicesCFProxy; import java.rmi.registry.LocateRegistry; import java.rmi.registry.Registry; public class CFRMIDemo { public static void main(String[] args) throws Exception { Registry reg = LocateRegistry.getRegistry(args[0], Integer.parseInt(args[1])); DataServicesCFProxy obj = (DataServicesCFProxy)reg.lookup("cfassembler/default"); obj.count(null, null, null); } } ``` The second parameter to the count() method is an array of java.lang.Object meaning we can supply arbitrary objects in that parameter and they will be deserialized on the server. We can use ysoserial at runtime to generate an arbitrary payload object and pass that to the count() method, however the ysoserial ROME payload is not compatible with the version of ROME that’s bundled with ColdFusion. If we try this, the server will complain that the server-side class is incompatible with the serialized object that was sent over the network. This is due to the serialVersionUID fields not matching, similar to how I described with the previous exploit that targeted Mozilla Rhino. The easiest way to exploit the ColdFusion RMI service, prior to the April 2018 update, is to rebuild ysoserial. Instead of building ysoserial against rome 1.0 (Maven dependency), build it against “libs/rome-cf.jar” from the ColdFusion installation directory. Having done so, the following code can be used to generate and deliver payloads: Java ``` package nb.barmie.exploit.standalone; import coldfusion.flex.rmi.DataServicesCFProxy; import ysoserial.payloads.ROME; import java.rmi.registry.LocateRegistry; import java.rmi.registry.Registry; public class CFRMIExploit { public static void main(String[] args) throws Exception { Registry reg = LocateRegistry.getRegistry(args[0], Integer.parseInt(args[1])); DataServicesCFProxy obj = (DataServicesCFProxy)reg.lookup("cfassembler/default"); obj.count(null, new Object[] { new ROME().getObject(args[2]) }, null); } } ``` Run the exploit with the parameters: host, port, command. ### Exploitation – The BaRMIe Way! Having done a lot of work on RMI security, I opted to implement an exploit in my RMI enumeration and attack tool, BaRMIe. It’s a more complex exploit but also more powerful. I’ll release this version of the exploit in the near future, but for now I’ll explain how it works for those who are interested! ### RMI Background A remote method invocation involves two network services and two distinct network connections. The first network service is the RMI registry service, usually found on TCP port 1099, which is essentially a directory service where Java object references are bound to names. Line 4 of the following code connects to an RMI registry service on 10.0.0.30:1099 and requests a reference to the object that is bound to the name “Foo”: Java ``` public class RMIList { public static void main(String[] args) throws Exception { Registry reg = LocateRegistry.getRegistry("10.0.0.30", 1099); SomeClass obj = (SomeClass)reg.lookup("Foo"); } } ``` The second network service is used to communicate with the object itself. When the object is bound to a given name in the RMI registry, the host and port where the object can be found are stored in the registry. When we retrieve an object reference from the RMI Registry, the data returned by the RMI registry service includes the host and port of the object’s network service. Line 5 in the following code connects to the RMI object service and invokes the method someMethod(): Java ``` public class RMIList { public static void main(String[] args) throws Exception { Registry reg = LocateRegistry.getRegistry("10.0.0.30", 1099); SomeClass obj = (SomeClass)reg.lookup("Foo"); obj.someMethod("String Param"); } } ``` ### Manning the Middle While I was building BaRMIe, I wanted to include as many exploit payloads (POP gadget chains) as possible without having to battle with dependencies and multiple versions of dependencies. The way I achieved this was to have hard-coded static payloads and generate dynamic sections on the fly (e.g. command strings and corresponding length fields). The problem was that there’s no way to natively pump arbitrary bytes down an RMI connection in such a way that the receiving server would deserialize those bytes. To achieve this, I built a proxy framework that allowed me to man-in-the-middle both connections. It works as follows: * Start an RMI registry proxy that forwards connections on to the target RMI registry * Call LocateRegistry.getRegistry() with the host and port of the RMI registry proxy, not the host and port of the RMI registry service * Call Registry.lookup() to retrieve a remote object reference via the RMI registry proxy (which forwards the request to the real RMI registry service) * When the RMI registry proxy detects a remote object reference being returned: * It starts an RMI method proxy to forward connections on to the real RMI object service * It modifies the remote object reference to point at the new RMI method proxy rather than the real RMI object service * When a method is invoked on the remote object reference, the connections now go through the RMI method proxy With remote method invocations going through a proxy, I have complete control over the protocol and I can manipulate things that the Java Virtual Machine would otherwise prevent me from manipulating. A great example of this is that a remote method which expects a parameter of type java.lang.String cannot be supplied with an arbitrary object parameter, however if we modify the outbound remote method invocation at the network level using a proxy then we can supply an arbitrary object and the server will deserialize it. Using an RMI method proxy, we can issue a call to a remote method in the normal way but with a placeholder parameter instead of a payload object. When the method proxy detects the bytes representing that placeholder object, it can replace those bytes with a stream of bytes representing an arbitrary deserialization payload ### Fixing the Payload When I first spotted the file “libs/rome-cf.jar” in the ColdFusion installation directory, the first thing I did was create an exploit in BaRMIe that used an RMI method proxy to inject two payloads based on the ROME payload from ysoserial. Neither of these were successful, however the server’s response stated that the local class was incompatible and gave me the serialVersionUID of the server-side class. By modifying my payload several times so that the serialVersionUID values in the payload matched those on the server, I achieved remote command execution against ColdFusion again. ### Bonus: Attacking “Internal” Services All this proxying might seem like a lot of effort given the easy exploit I detailed above but actually the supporting functionality was already present in BaRMIe so it only took half an hour to develop this exploit. There’s an additional bonus to controlling things outside of the restrictions of the Java Virtual Machine that I have touched on before, but which is definitely worth another mention. A lot of “internal” RMI services aren’t actually internal. You can bind objects to an RMI registry and be under the impression that they are bound to, for example, 127.0.0.1 or 10.0.0.30 or even host.yourbusiness.local. If an external attacker retrieves a reference to any of those objects using the easy exploit above then they won’t be able to attack the RMI service because they cannot access those internal addresses. By default, however, RMI object services bind to all network interfaces. Let’s say the external address of the target is 8.8.8.9 and the RMI registry returns an object reference pointing at the internal address of the target, 10.8.8.9:30001. By default, the same object can be accessed by connecting to the same port on the external address at 8.8.8.9:30001. By proxying the RMI registry connection, we can detect this and automatically modify RMI connections to enable attacks against objects that appear to be bound internally. id SSV:97346 last seen 2018-06-26 modified 2018-06-19 published 2018-06-19 reporter My Seebug title ColdFusion RCE(CVE-2018-4939)