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 cisco_asa.py 10.10.1.100:500
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]
y
[*] 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 cisco_asa.py 10.10.1.100:500
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]
y
[*] 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.
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:
Any of those sites have full cross-domain access to the VS. Manyblogshave 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.
I’ll start with identifying the VS I would like to scan, for this demo I’ll be using https://jakereynolds.co. A VS can be found any number of ways and we can verify it has a cross-domain policy by accessing https://jakereynolds.co/crossdomain.xml. We’ll then feed this into the cross-domain scanner with the command:
python scanner.py https://jakereynolds.co -v
Once the script is finished it will tell us if there are any expired domains in the policy.
Possible expired domains:
asdaasdasfwkjhcjhbwrgkljsv.com
thisisanexpireddomainaswell.es
jakereynoldsexpireddomain.com
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.
Findings
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…)
Recommendation
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 certainbrowsers.
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.
After the file is loaded the subsequent request will be formatted in the following way.
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 https://some.domaim.com/WebService.asmx/js. The application may also request the same file with the debug information, https://some.domain.com/WebService.asmx/jsdebug. 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. https://some.domain.com/WebService.aspx/GetInformation)
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 https://github.com/NetSPI/JSWS, 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.
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.
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.
Conclusion
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.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover why security operations teams choose NetSPI.
Back
