Friday, August 12, 2011

Internet Explorer: Your personal computer is public property

A successful compromise will result in an attacker being able to blindly read every single file in the local drive.
–Either text and binary files (thanks MSXML2.DOMDocument.3.0!)
–Cross-domain information (Navigation history, Cookies)
–SAM backup files
–Recently opened files
–Personal pictures
–Other files, depending on the computer compromised (wwwroot in IIS, Configuration files for other applications)

Internet Explorer Internals
-Every browser has its own idiosyncrasies
-For the purposes of this presentation, it is convenient to review some design features of Internet Explorer
1.Security Zones
2.Zone Elevation
3.MIME type detection

Security Zones
-Enable administrators to divide URL namespaces according to their respective levels of trust and to manage each level with an appropriate URL policy Different treatment for web content depending on its source
-Five different sets of privileges (zones)
1.Restricted Sites
3.Trusted Sites
4.Local Intranet
5.Local Machine

Zone Elevation
-It occurs when a Web page in a given security zone loads a page from a less restrictive zone in a frame or a new window
-Internet Explorer behaves different based on which is the less restrictive zone up to which is trying to elevate the Local Machine zone is blocked the Intranet or Trusted Sites zones prompts for a confirmation
3.from the Restricted Sites zone to the Internet zone is allowed

MIME type detection
-Tests URL monikers through the FindMimeFromData method
-Determining the MIME type proceeds as follows:
1.If the suggested MIME type is unknown, FindMimeFromData immediately returns this MIME type as the final determination
2.If the server-provided MIME type is either known or ambiguous, the buffer is scanned in an attempt to verify or obtain a MIME type
3.If no positive match is obtained, and if the server-provided MIME type is known
4.If no conflict exists, the server-provided MIME type is returned. If conflict exist, the file extension is tried.
5.Otherwise defaults to text/plain or application/octet-stream

Features (vulnerabilities) enumeration
-Hiding the key under the doormat
-A chip off the old block
-Two zones, the same place
-How to put HTML/script code in remote computers
-Everything that glitters is not gold

Hiding the key under the doormat
-Internet Explorer cookies and history files are stored in different files and folders under %USERPROFILE%
-As a security measure, these files are stored inside randomly named folders with random file names
-These random names and locations are logged inside different mapping files named index.dat
%USERPROFILE%\Local settings\History\History.IE5\index.dat
%USERPROFILE%\Local settings\IECompatCache\index.dat
-These files are not entirely text formatted
-As these files work as maps to other files, access to these files would reveal the actual locations of mapped files and folders

A chip off the old block
-Internet Explorer resembles Windows Explorer in many aspects (both of them implement the Trident layout engine and both of them support UNC paths for SMB access)
-This way, Internet Explorer allows to access special files and folders, same as Windows Explorer does

Any web page in the Internet zone or above can include an HTML tag as follows:
-It will trigger an SMB request against
-As part of the challenge-response negotiation, the client sends to the server the following information about itself:
1.Windows user name
2.Windows domain name
3.Windows computer name
4.A challenge value chosen by the web server ciphered with the LM/NTLM hash of this user’s password

Two zones, the same place
-Internet Explorer will determine the security zone of a given UNC address as belonging to:
1.The Internet security zone if this path contains the IP address of the target machine
2.The Local Intranet security zone if this path contains the NetBIOS name of the target machine

-It makes sense, as SMB names just can be resolved in the same network segment
-\\NEGRITA is in the Local Intranet zone
-\\ is in the Internet zone
-This is one of the root causes of the problems the Microsoft staff has into closing the attack vectors exposed here
-After several discussions with MSRC team members, they stated this issue is kind of a dead end, and cannot be fixed
-According to the Security Zones scheme, a page in a given zone can not redirect its navigation to a more privileged zone
-This behavior is known as Zone Elevation
-Now, consider the following dialog:

-In this case Internet Explorer will erroneously (due to this ambiguity) apply Zone Elevation restrictions and the redirection will effectively occur
-There is another way to bypass Security Zone restrictions
-Suppose that ( was explicitly added to the Restricted Sites Security Zone
-Then this URI will be treated with the privileges of that zone
-However, if the same resource is requested using the UNC notation, it will be treated as belonging to the Internet Security Zone (e.g. \\\index.html)
-Restricted Sites restrictions to a given resource are bypassed if it can be accessed using a different protocol [file: | https: | ...]

How to put HTML/script code in remote computers
-There are different ways for remote servers to write HTML/script code in clients hard drives
1.Navigation history files
3.Mapping files (Internet Explorer index.dat)

-Problems in the design/implementation of these feature
1.Contents are saved as they were received, with little or no sanitization/overhead, into these files
2.Internet Explorer allows rendering the contents of non-pure HTML files skipping the parts that can not be rendered

Everything that glitters is not gold
-The way Internet Explorer decides how to treat a given file is known as MIME type detection
-It basically uses an algorithm to find and launch the correct object server/application to handle the requested content
-Is based on information obtained from
1.The server-supplied MIME type, if available
2.An examination of the actual contents associated with a downloaded URL (FindMimeFromData)
3.The file name associated with the downloaded content (assumed to be derived from the associated URL)
4.Registry settings (file extension/MIME type associations or registered applications) in effect during the download

-Problems in the design/implementation of this feature:
1.The server-provided MIME type is returned when the following conditions are true:
-no positive match is obtained from the FindMimeFromData() buffer scan
-server-provided MIME type is known
-no conflict exists (format is either text or binary)

2.Has been probed (more than once) not to behave deterministically when accessing the same resource through different methods
-direct navigation
-frame/iframe reference

Turning features into vulnerabilities to build an attack
-In and of itself each of these bugs may not seem like something you should be concerned about
-The combined use of them by an attacker may lead to some interesting attacks

Case 1: Attacking local networks with shared folders

Case 2: Attacking the Internet user

Overall Impact
-By chaining the exploitation of a series of weak features an attacker is able to store HTML and scripting code in the victim’s computer and force the victim’s browser to load and render it
- is in the Internet Zone, but as the code is actually stored in the victim’s computer, it can access other files in the same computer (in this case, the victim’s computer)
1.SAM backup files
2.All of the victim’s HTTP cookies and history files
3.Source files in Inetpub\wwwroot
4.Recent files, personal pictures (thumbs.db maps these files)
5.Any other file on the local system (system events, configurations)

These attack scenarios have been proven to work:

-The only difference is in the way Internet Explorer is tricked into rendering its internal tracking files as HTML
-That is the only thing Microsoft is fixing. This is a design problem. They are just blocking our proof of concept
-That is why we are breaking it over and over again

Solutions and Workarounds
-Internet Explorer Network Protocol Lockdown
-Set the Security Level setting for the Internet and Intranet zones to High
-Disable Active Scripting for the Internet and Intranet zone with a custom setting
-Only run Internet Explorer in Protected Mode
-Use a different web browser to navigate untrusted web sites

Thursday, June 30, 2011

Attacking VMWare Guest Machines

Vulnerability Discovery
-Vulnerability identified on 5/14/09
-Reported to VMware on 5/15/09
-VMware responded on 5/21/09
-CVE-2009-3733 reserved on 10/20/09
-VMSA-2009-0015 released on 10/27/09
-"Directory Traversal vulnerability"

-Originally identified on VMware Server 2.0.1 build 156745 (on Ubuntu 8.04)
-Thought to be localized to inside of NAT interface of Host (8307/tcp)
-Can steal VMs from within other VMs... if NAT.

-Web Access web servers also vulnerable
-Server (default ports 8222/8333) - ../ x 6
-ESX/ESXi (default ports 80/443) - %2E%2E/ x 6
-No longer requires NAT mode / Remotely exploitable
-Not as straightforward as originally thought
-Still trivial to exploit because...

Root Access Is Easy

How it works?

-Web server on 8308/tcp is vulnerable, but will only serve certain filetypes (xml, html, images, etc.)
-Web server on 8307/tcp is also vulnerable, but serves ALL filetypes
-Simply append /sdk to our URL request and we’ve got complete access to Host filesystem (including other Virtual Machines)
-ESX/ESXi - ALL web servers return ALL filetypes (no /sdk)

Vulnerable Versions
-VMware Server 2.x < 2.0.2 build 203138 (Linux)
-VMware Server 1.x < 1.0.10 build 203137 (Linux)

-ESX 3.5 w/o ESX350-200901401-SG
-ESX 3.0.3 w/o ESX303-200812406-BG
-ESXi 3.5 w/o ESXe350-200901401-I-SG

Guest Stealer
-Perl script remotely ‘steals’ virtual machines from vulnerable hosts
-Supports Server, ESX, ESXi
-Allows attacker to select which Guest to ‘steal’
-Utilizes VMware configuration files to identify available Guests and determine associated files

-/etc/vmware/hostd/vmInventory.xml (default location)
-Gives us Guest inventory & location information

-Patch, patch, patch
-Hosts are an attractive target (compromise one = access many)
-Better yet...Segment, segment, segment
-Segment management interfaces
-Segment systems of different security levels
-Don’t share physical NICs between different security levels
-Virtualization is not always the "best answer"

No comments: