Cisco ASA Remote Code Execution – Verifying CVE-2016-1287

Remote Code Execution on Cisco ASA

A year ago ExodusIntel disclosed a vulnerability affecting the IKE implementation in Cisco’s ASA products. The error is due to an overflow in the checking of reassembled IKE fragments, and allows remote code execution from an unauthenticated attacker. More information on the technical aspects of this can be found at ExodusIntel’s blog here. As Cisco ASAs are widely used in the industry, we started to see this vulnerability come up in many penetration tests, but it was hard to verify beyond the fact that a scanner found this issue. The consulting team here at NetSPI, as well as our clients, wanted a more verbose verification that this vulnerability was present.

Creating the Verification Tool

In order to get a concrete verification for this, I first read through all the write-ups on the vulnerability. After I had a solid foundation of the flaw itself, I used vulnerability scanners to test a vulnerable ASA in our lab environment and did a packet capture. With this packet capture, and the scanner plugins I was able to figure out a good way to verify the presence of the vulnerability. I implemented a similar verification in Python which included output showing where the fragmentation reassembly fails. The ASA will either respond with an incomplete IKE notify packet, indicating the ASA is vulnerable, or it will drop the invalid fragments and it will not respond, demonstrating that the patch has been applied. Examples of both of these scenarios can be seen below, note that these would typically be externally facing IP addresses, but as they were in a testing lab the WAN interface was on an internal network.

Vulnerable ASA

pentest ~ $ python3
This tool is used to verify the presence of CVE-2016-1287, an unauthenticated remote code execution vulnerability affecting Cisco's ASA products.
No attempt will be made to execute code, this simply observes behavior of affected versions when malformed fragments are sent to the ASA.
Continue? [y/N]
[*] Sending Initiator Request
[*] Received Response
[+] Valid SA found. Moving on
[*] Sending first fragment
[*] Sending second fragment
[*] Notify Payload found. Printing Notify payload data.
Next payload: NONE
Critical bit Not Critical
Payload length: 8
Protocol ID: IKE
SPI Size: 0
Notify Message Type: Invalid Syntax
Notification DATA: missing
[+] Notification data is missing. ASA is vulnerable.
00000000: 66 53 54 71 45 49 58 64  75 6A FD C0 52 32 52 96  fSTqEIXduj..R2R.
00000010: 29 20 22 20 00 00 00 00  00 00 00 24 00 00 00 08  ) " .......$....
00000020: 01 00 00 07                                       ....

Patched ASA

pentest ~ $ python3
This tool is used to verify the presence of CVE-2016-1287, an unauthenticated remote code execution vulnerability affecting Cisco's ASA products.
No attempt will be made to execute code, this simply observes behavior of affected versions when malformed fragments are sent to the ASA.
Continue? [y/N]
[*] Sending Initiator Request
[*] Received Response
[+] Valid SA found. Moving on
[*] Sending first fragment
[*] Sending second fragment
[*] IKE Fragment was dropped indicating the ASA is not vulnerable.

The code can be found on NetSPI’s GitHub here.


Defeating CSRF Protections Through Expired cross-domain.xml Domains

When someone buys a domain name the usual purchase length is one year, with certain DNS providers allowing multi-year purchases.  Large entities can quickly lose track of all their domains and keeping track of when those domains expire can be an even bigger hassle.  When you add Flash integration into the mix it starts becoming a security issue.

Adobe Flash has been known to have many vulnerabilities in the past, and my favorite is actually a feature.  Flash has the feature of respecting a cross-domain policy for inter-site communication; the crossdomain.xml file lists valid external domains that can make requests to the Victim Site (VS).  An example crossdomain.xml looks like this:

<allow-access-from domain=""/>
<allow-access-from domain=""/>
<allow-access-from domain=""/>

Any of those sites have full cross-domain access to the VS.  Many blogs have covered the topic of overly-permissive cross domain policies with rules like <allow-access-from domain=”*”/>  that allow access from any site.  This blog will cover the topic of expired domains that are allowed in cross-domain files, allowing an attacker to purchase that domain and gain full cross-domain access.

Cross-Domain Scanner

As stated before, cross-domain exploitation has been well documented so I will link tutorials on defeating CSRF on the expired domains below, here is how we can go about discovering those domains using my crossdomainscanner python script located here.


~$ git clone
~$ cd crossdomainScanner
~$ pip install -r requirements.txt

I’ll start with identifying the VS I would like to scan, for this demo I’ll be using  A VS can be found any number of ways and we can verify it has a cross-domain policy by accessing   We’ll then feed this into the cross-domain scanner with the command:

python -v

Once the script is finished it will tell us if there are any expired domains in the policy.

Possible expired domains:

We now know that can gain cross-domain access to, instantly eliminating any CSRF protection that might have existed on the site.


The best way to exploit this is to take advantage of the CSRF bypass.  Purchase the expired domain, make someone visit your site, and if they are logged in on the VS you can make requests under the context of their account.  This will be done by creating a Flash application for manipulating requests, more on that here.  If the VS does not have any valuable APIs the cross-domain access does not warrant a valid finding, since nothing can be exploited from it.


Out of the Top 5000 Alexa domains:

  • 222 allow cross-origin requests from any domain (*)
  • 20 allow cross-origin requests from expired domain names
  • 20 allow cross-origin requests from domains with invalid TLDs (.local, .des, etc…)


As a site owner/maintainer it is best to run this script against your own domain and remove or repurchase any expired domains allowed in your crossdomain.xml file.  For long-term monitoring it would be good to incorporate this tool into your development pipeline so that it gets checked at least once every production deployment.  A permanent fix would be to remove Flash integration with the website, since Flash is already being deprecated in certain browsers.

References is linked above for a Flash tutorial

In my time researching I discovered a similar tool for this written by @IAmMandatory, you can find that here.


Attacking JavaScript Web Service Proxies with Burp

JavaScript Web Service Proxies are an alternative to WSDL (Web Services Description Language) files for interacting with WCF Web Services. The proxy files function as a description of the web service methods, exposing the available service methods as well as their parameters. JavaScript Service Proxies, or JSWS (JavaScript Web Services) as I will be calling them for brevity’s sake, are a component of an AJAX framework and can typically be used in place of WSDLs for the same web services. JSWS uses JavaScript to model the descriptor file, and JSON in transit making it a good alternative to WSDL’s XML as JavaScript and JSON are heavily integrated into all browsers. The client side application will either load the JSWS upon need, or it may be embedded into the page. The JSWS contains JavaScript code that will instruct the browser in the creation of the JSON request. An example of one of these files can be seen below.

NewsSite.AdGroups.Advertisement=function() {
this._timeout = 0;
this._userContext = null;
this._succeeded = null;
this._failed = null;
_get_path:function() {
 var p = this.get_path();
 if (p) return p;
 else return NewsSite.AdGroups.Advertisement._staticInstance.get_path();},
GetAds:function(SubsectionID,AdGroupID,Element,iCounter,succeededCallback, failedCallback, userContext) {
return this._invoke(this._get_path(), 'GetAds',false,{SubsectionID:SubsectionID,AdGroupID:AdGroupID,Element:Element,iCounter:iCounter},succeededCallback,failedCallback,userContext); }}
NewsSite.AdGroups.Advertisement._staticInstance = new NewsSite.AdGroups.Advertisement();
NewsSite.AdGroups.Advertisement.set_path = function(value) { NewsSite.AdGroups.Advertisement._staticInstance.set_path(value); }
NewsSite.AdGroups.Advertisement.get_path = function() { return NewsSite.AdGroups.Advertisement._staticInstance.get_path(); }
NewsSite.AdGroups.Advertisement.set_timeout = function(value) { NewsSite.AdGroups.Advertisement._staticInstance.set_timeout(value); }
NewsSite.AdGroups.Advertisement.get_timeout = function() { return NewsSite.AdGroups.Advertisement._staticInstance.get_timeout(); }
NewsSite.AdGroups.Advertisement.set_defaultUserContext = function(value) { NewsSite.AdGroups.Advertisement._staticInstance.set_defaultUserContext(value); }
NewsSite.AdGroups.Advertisement.get_defaultUserContext = function() { return NewsSite.AdGroups.Advertisement._staticInstance.get_defaultUserContext(); }
NewsSite.AdGroups.Advertisement.set_defaultSucceededCallback = function(value) { NewsSite.AdGroups.Advertisement._staticInstance.set_defaultSucceededCallback(value); }
NewsSite.AdGroups.Advertisement.get_defaultSucceededCallback = function() { return NewsSite.AdGroups.Advertisement._staticInstance.get_defaultSucceededCallback(); }
NewsSite.AdGroups.Advertisement.set_defaultFailedCallback = function(value) { NewsSite.AdGroups.Advertisement._staticInstance.set_defaultFailedCallback(value); }
NewsSite.AdGroups.Advertisement.get_defaultFailedCallback = function() { return NewsSite.AdGroups.Advertisement._staticInstance.get_defaultFailedCallback(); }
NewsSite.AdGroups.Advertisement.set_enableJsonp = function(value) { NewsSite.AdGroups.Advertisement._staticInstance.set_enableJsonp(value); }
NewsSite.AdGroups.Advertisement.get_enableJsonp = function() { return NewsSite.AdGroups.Advertisement._staticInstance.get_enableJsonp(); }
NewsSite.AdGroups.Advertisement.set_jsonpCallbackParameter = function(value) { NewsSite.AdGroups.Advertisement._staticInstance.set_jsonpCallbackParameter(value); }
NewsSite.AdGroups.Advertisement.get_jsonpCallbackParameter = function() { return NewsSite.AdGroups.Advertisement._staticInstance.get_jsonpCallbackParameter(); }
NewsSite.AdGroups.Advertisement.GetAds= function(SubsectionID,AdGroupID,Element,iCounter,onSuccess,onFailed,userContext) {NewsSite.AdGroups.Advertisement._staticInstance.GetAds(SubsectionID,AdGroupID,Element,iCounter,onSuccess,onFailed,userContext); }
var gtc = Sys.Net.WebServiceProxy._generateTypedConstructor;
if (typeof(NewsSite.AdGroups.AdGroupInfo) === 'undefined') {

After the file is loaded the subsequent request will be formatted in the following way.

Json Request

A side effect of this file instructing the browser in how the requests must be formatted is that it can also aid an attacker in enumerating web service methods and potential injection points. Before these can be used, it is important to understand when JSWS is in use, and how to identify it.

Identifying JSWS

There are multiple different ways to identify when these services are being used in an application. The application may request a JSWS file allowing it to be identified through proxy logs by looking for The application may also request the same file with the debug information, The jsdebug file will contain additional information about the datatypes of the parameters needed, and which parameters are required. Even if the application is not requesting the jsdebug file it is likely still available.

Alternatively, the application may be using the PageMethods technique, which means the JSWS will be embedded directly into the page.

This will typically be on an aspx page rather than asmx, but it could be present with any extension. This method can be identified by searching server responses for the ‘PageMethods’ string, or by inspecting proxy logs for the method calls (e.g.

The JSWS Extension

After identifying that this technology is being used an attacker is able craft all the request variations the web service will accept, but this takes time and can be quite tedious. After starting to see JSWS in assessments more often, I decided to create a Burp extension that would automate this process. The tool is modeled after Eric Gruber’s Wsdler, and functions in the same way. The JSWS extension can be downloaded from, and is available in the BApp store.

To use this tool, simply right click on the request or response containing the JSWS and click Parse JSWS. If the application is loading the JSWS file, the file should already be in the proxy logs.

Parse Jsws

It is recommended to parse the jsdebug file rather than the js file, as it will give the user more information about which types of parameters to tamper with.

If the application uses the PageMethods representation of JSWS, right click on the request or response containing the PageMethods code and click Parse JSWS.

The JSWS extension will then open a JSWS tab, as well as a subtab for the service just parsed. Under this tab are two panes, the top containing all available methods, and the bottom containing the JSON template.

Jsws Tab

From here the request can be handled as any JSON request, and can be sent to Repeater for manual testing, or Intruder and Scanner for automated testing.


The extension does not currently detect the presence of JSWS through passive scanning. This is being implemented and will be released in a future build. For any feature requests or bugs you may find please email me or create a ticket on Github.