Monday, May 9, 2016 At 1:24PM
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:
-
The target web application is served from the Local Intranet Zone.
-
Protected mode is turned OFF for Local Intranet Zone (default).
-
The victim is authenticated on the target web application.
Attack PoC:
-
The victim receives an email with a web page attached.
-
The victim opens the web page with Internet Explorer.
-
The victim clicks on “Allow Blocked Content” button.
-
(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
Author: Andrea Scaduto
©Aon plc 2023
