Twitter
« AirWatch Vulnerabilities from the GDS Archives | Main | Convert2FPR: Introducing ESLint and PMD support. »
Monday
May092016

Local Request Forgery

This post explains how to abuse Internet Explorer’s Local Intranet Zone using malicious web pages served from the local disk. In corporate environments this could lead to impersonation of the victim on internal web applications and exfiltration of data outside the corporate network. 

Internet Explorer renders web pages in Security Zones; each zone comes with security settings that reflect the level of safety of that zone. 

When Internet Explorer opens a web page, the Urlmon DLL determines the zone from which the page was loaded. There are four predefined security zones:

  • Local intranet zone: all sites inside an organisation.

  • Trusted sites zone: all sites considered trusted.

  • Restricted sites zone: all sites considered not trusted. 

  • Internet zone: all Internet sites (not in the Trusted or Restricted zones)

In addition to the above four zones, the hidden My Computer zone includes all files served from network shares, the local hard disk and removable drives.

 

Cross-Site Request Forgery (CSRF) is an attack that abuses the inherent trust a web server places in the browser. Generally, any request within an authenticated session is assumed to be made, directly or indirectly, by the user. The attack described below can be considered a variation of Cross-Site Request Forgery where the attacker can also read the response. Instead of coercing the user to visit a malicious Internet website, the attacker sends an email with a malicious HTML page attached; when the victim opens this page with Internet Explorer it is loaded from the local file system and Internet Exploror (IE) renders it in the My Computer security zone. This zone allows scripts to issue requests to any website bypassing both the Same Origin Policy (SOP) and Cross-Origin Request Sharing (CORS).

 

Since IE 7, Protected Mode adds an integrity mechanism to restrict write access to securable objects (like processes, files, and registry keys) with higher integrity levels. If Protected Mode is disabled cookies are included when (malicious) scripts issue HTTP requests. The Local Intranet Zone is used in many corporate environments for internal web applications. Note that Protected Mode is disabled by default for the Local Intranet Zone on all current versions of Internet Explorer. Consequently, the malicious web page attached to an email described above can include JavaScript to target an internal application to which the victim is authenticated. This JavaScript will bypass SOP and CORS, because the page is rendered in the My Computer Zone, which enables the attacker to perform requests and read responses.

 

Demo Application

A simple demo web application was built as a Proof-of-Concept. The application is served from the Local Intranet Zone domain www.corporate.internal as shown in the screenshot below:

 

Monet HR is a web application used for HR purposes, it allows employees to view and manage their personal data such as personal and employment information, compensation, holidays, etc. 

 

The demo application exposes a single Servlet to authenticated users:

http://www.corporate.internal/monet/logged/userHandler

The servlet allows the user to perform two actions:

  • getCSRF (retrieves the CSRF token associated with user’s session)

  • getInfos (retrieves user’s information, it requires a CSRF token)

 

Pre-Requisites:

  1. The target web application is served from the Local Intranet Zone.

  2. Protected mode is turned OFF for Local Intranet Zone (default).

  3. The victim is authenticated on the target web application.

 

Attack PoC

  1. The victim receives an email with a web page attached.

  2. The victim opens the web page with Internet Explorer.

  3. The victim clicks on “Allow Blocked Content” button.

  4. (only for demo purposes) The victim clicks on “Steal Infos”, this triggers the malicious script.

 

The page served from the local file disk is rendered in the My Computer Zone, and can therefore bypass the Same Origin Policy and Cross Origin Resource Sharing. It can send requests to any application in the Local Intranet Zone, and cookies will be included in the request.

  1. When clicking on the button Steal Infos the JavaScript first issues an XHR to http://corporate.internal/monet/logged/userHandler to retrieve the CSRF token. This violates CORS (the script sends a cross-domain POST request with content type application/json but no preflight OPTIONS request is performed). It also violates SOP as the script can read the response coming back from a different origin.

  2. Having retrieved the CSRF token the JavaScript issues another request to the demo application, requesting the user’s information (a CSRF token is required in the JSON object). Again the JavaScript violates CORS and SOP, as it sends a POST request (with application/json content type) and it can read the user’s personal information back
  3. The malicious page then exfiltrates the stolen data to a third party website (lrfpoc.herokuapp.com) using a POST request with content type application/json (thus still in violation Cross-Origin Resource Sharing) and can read the response to that request as well (still violating SOP).

The above explanation can be referenced in the screenshot below where request and responses are printed in the DOM.

 The attacker can then view the exfiltrated data on a domain outside of the corporate network:

 

Mitigation:

The attack described above may be considered a variation of Cross-Site Request Forgery. However, server-side CRSF mitigations are not applicable. The demo application employed in the PoC required the submission of an anti-CSRF token, but since the malicious JavaScript can bypass SOP and CORS, it can read the CSRF token and use it in the request.

As this is a client-side issue, the only effective mitigation is to ensure that Internet Explorer enforces SOP and CORS by enabling Protected Mode for the Local Intranet Zone. Since Internet Explorer 7.0 on Windows Vista, this can be achieved through Group Policy Objects (GPO).

Source: http://gpsearch.azurewebsites.net/#911

 

Reader Comments (2)

Hello,

The attack you present here is a part of a research that i published in 2012 called "AJAX Hammer" in an OWASP convention, followed by a whitepaper and code demos. In my research i covered this, and much more:

OWASP Presnetation:
https://prezi.com/6vnl6so07b-c/ajax-hammer/

Whitepaper:
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/hasc-research/AJAX%20Hammer%20-%20Harnessing%20AJAX%20for%20(Direct)%20Dynamic%20CSRF.pdf

PoC Movie:
https://www.youtube.com/watch?v=JHJ1WW4Fcvw

Demo Code:
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/hasc-research/AJAX-CSRF-Demo-Code.zip


This post should acknowledge my work.


Oren Ofer
May 10, 2016 | Unregistered CommenterOren Ofer
Oren, I was unaware of your work on the subject. Thank you for these pointers and the interesting research.
As you say, your work is clearly broader than the specific topic this post outlines, and in fact I focused on the enterprise aspect of it: taking for granted many enterprises rely on Zones as a protection mechanism, do they know about the related risks? In particular this research followed a working POC demonstrated to a client, which generates an interesting debate about how to interpret and assess the browser's internal protection mechanisms, like IE’s Protected Mode.
What is extremely interesting to me is that two researches, in different moments, followed the same research path but for completely different reasons: from what I can infer, your research is in the direction of a comprehensive study on the interaction of browser's native protection, Javascript/HTML related vectors and Cross* attacks, while mine was driven by a compliance problem, really.
May 14, 2016 | Unregistered CommenterAndrea Scaduto
Comments for this entry have been disabled. Additional comments may not be added to this entry at this time.