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.
The code can be found on NetSPI's GitHub here.
[post_title] => Cisco ASA Remote Code Execution - Verifying CVE-2016-1287
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => cisco-asa-remote-code-execution-verifying-cve-2016-1287
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-13 00:05:37
[post_modified_gmt] => 2021-04-13 00:05:37
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=6836
[menu_order] => 603
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[1] => WP_Post Object
(
[ID] => 6814
[post_author] => 33
[post_date] => 2017-02-14 07:00:21
[post_date_gmt] => 2017-02-14 07:00:21
[post_content] => 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.
[post_title] => Attacking JavaScript Web Service Proxies with Burp
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => attacking-javascript-web-service-proxies-burp
[to_ping] =>
[pinged] =>
[post_modified] => 2021-06-08 21:47:45
[post_modified_gmt] => 2021-06-08 21:47:45
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=6814
[menu_order] => 605
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
)
[post_count] => 2
[current_post] => -1
[before_loop] => 1
[in_the_loop] =>
[post] => WP_Post Object
(
[ID] => 6836
[post_author] => 33
[post_date] => 2017-02-28 07:00:47
[post_date_gmt] => 2017-02-28 07:00:47
[post_content] =>
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 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.
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.
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.
