Understanding Script Injection Attacks in the My Computer Zone
Script injection (persistent XSS) can also happen on the local hard disk. Many applications write files to the local hard disk with contents that could be specified by an attacker. Following are a few examples.
Example: Script Injection in Winamp Playlist
A security researcher who goes by the name DownBload found a script injection bug in Nullsoft Winamp versions 2.76 and 2.79 and posted the details to Bugtraq ( http://www.securityfocus.com/bid/5407 ). Recent versions of Winamp include a fix for this bug. Down-Bload found that Winamp didn t validate or encode the MP3 file properties used in creating an HTML playlist. The HTML playlist is stored on the local hard disk, and Winamp automatically loads the file using the Internet Explorer rendering engine (Trident ”discussed later in this chapter). Many people wouldn t think that creating an HTML playlist through Winamp could compromise the local machine, but in this case it could.
How can you find bugs like this? The first step is understanding in a little more detail how the application works. If you create an HTML playlist of nonmalicious MP3 files, you will see that the artist and title information is displayed (see Figure 10-12).
Figure 10-12: Nullsoft Winamp displaying the artist and title information in a playlist
Likely the playlist displayed is HTML because it is created by an option named Generate HTML Playlist, but it is important to know whether Winamp is using Trident. Only Internet Explorer uses the concept of a My Computer zone. Remember, this zone has the lowest security settings. The Spy++ tool included with Visual Studio can be used to find out more information about the window displaying the playlist. Super Password Spy++ ( http://www.codeguru.com/Cpp/I-N/ieprogram/security/article.php/c4387 ) is similar to the Visual Studio Spy++ and is freely available. Press Ctrl+F inside Spy++ to open the Find Window dialog box. This dialog box, shown in Figure 10-13, allows you to drag the Finder Tool over a window to obtain more information about it. Dragging the Finder Tool over the Winamp Playlist window shows the window s class is Internet Explorer_Server. This is the window class used by Trident. Now you know Winamp is using the Internet Explorer rendering engine to display HTML.
Figure 10-13: The Find Window in Spy++
The artist and title information is part of the file properties for MP3 files. These properties can be modified in Windows Explorer by right-clicking a file and choosing Properties. Figure 10-14 shows that the artist s name has been modified from Artist to Artist <SCRIPT>alert(document.location)</SCRIPT>.
Figure 10-14: The properties of an MP3, which can be modified in Windows Explorer
An attacker hopes that the artist property isn t validated or encoded and included in the playlist. To test this theory, the newly modified MP3 with script as the artist can be loaded in Winamp and an HTML playlist can be generated. In this case, the theory proves true and the script runs successfully (Figure 10-15). The script contained code to echo the URL of the page it is running inside. In this case, the script displays the location as WHT16.tmp.html inside the temporary directory. Script running from this location means that it is running in the My Computer zone.
Figure 10-15: Script included in the MP3 file properties running in the My Computer zone when the HTML playlist is displayed
This example is a good one because it shows the importance of understanding where the data used to create HTML comes from. File properties of other formats are often used when creating an HTML page. Don t just look for local files to contain HTML content when searching for local XSS and script injection attacks. Sometimes the HTML content is dynamically written by an application using the DOM. Often this HTML runs in the My Computer zone. If you are able to run script in a scenario like this, check the document.location to help determine in which zone your code is running.
Non-HTML Files Parsed as HTML
Internet Explorer has an interesting feature that has caused many security issues. Regardless of the extension and content type of a document, Internet Explorer examines the first 200bytes of the document and makes its own decision on whether the content is HTML. If the browser sees content that appears to be HTML in the first 200 bytes, it parses the file as HTML. This has caused many security problems for applications writing files to the local hard disk on the Windows platform. When an application takes data from an untrusted source and places that data in the first 200 bytes of a file on the local hard disk, and the file location can be guessed by an attacker, there is the potential for a script injection bug in the My Computer zone. In Windows XP SP2 and later, Internet Explorer respects the Multipurpose Internet Mail Extensions (MIME) type and extensions of files and does not examine arbitrary files for HTML content. However, even on systems that have Windows XP SP2 installed, applications that host Trident might not exhibit the behavior of respecting MIME types.
| More Info | For more information about the Internet Explorer sniffing behavior, see http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/moniker/overview/mime_handling.asp . For more information about the change in Internet Explorer for Windows XP SP2 and later, see http://www.microsoft.com/windows/IE/community/ columns /improvements.mspx . |
To clarify, the following is an example of a Windows Media Player bug found by a security researcher named http-equiv. (The original message sent to Bugtraq can be found at http://www.securityfocus.com/bid/5543/ .) Http-equiv found that Windows Media Player allowed an attacker to place an .asx file in a predictable location on the victim s machine. Before the file was placed, some validation occurred on the file s contents. Http-equiv found that he could pass the validation check by creating a valid .asx file, and then append arbitrary data to the end of it. A valid .asx file could be made with less than 200 bytes. This allowed him to place HTML data after the end of the valid .asx data. If Internet Explorer was asked to open the file, it would examine the first 200 bytes of the file, find HTML included, and render it as HTML in the My Computer zone. Because the file was placed in a predictable location, an attacker could easily place the file on the user s hard disk and then redirect Internet Explorer to open the file. This bug has been fixed in more recent versions of Windows Media Player.
In this scenario, the attacker could place the file on the victim s machine by using a Windows Media Player feature to install Windows Media Download Packages ( http://www.microsoft.com/windows/windowsmedia/howto/articles/downpacks.aspx ). A Windows Media Download Package is a compressed ZIP file that uses the .wmd extension. When a .wmd file is opened in Windows Media Player, some validation is performed on the contents; if the contents appear valid, the files are unzipped into a subdirectory inside the My Music directory on the user s hard disk. The subdirectory name is the same as the name of the .wmd file.
Http-equiv s example .asx file, contained in the .wmd file, took advantage of several other bugs to get his executable to run. For simplicity, this text focuses on how to get script running. An .asx file can be created as shown in the following code and can be placed, along with a music file (test.wma in this example), inside a ZIP file named demo.wmd (included on the companion Web site).
<ASX version="3"> <ENTRY> <REF HREF="test.wma" /> </ENTRY> </ASX> <IMG SRC="javascript:alert(document.location)">
This file passes as a valid .asx file and is unzipped on the victim s machine in the directory named C:\Documents and Settings\ username \My Documents\My Music\Virtual Albums\demo. Then, the victim needs to be redirected to the file and the .asx file will run script.
In the Windows Media Player example, people that knew about the Windows Media Download Packages functionality understood that the files placed inside the .wmd file would be extracted onto the user s machine. However, finding script injection bugs where untrusted data is placed inside non-HTML files isn t always as straightforward. We have found many bugs in locations where it wasn t well known that untrusted data was being placed in non-HTML files. We found these bugs by using FileMon (discussed in Chapter 4) and by examining what is being written to the files.
| Changes in Internet Explorer in Windows XP SP2 | The Internet Explorer team looked carefully at how users were being attacked through Internet Explorer and the other applications hosting Trident (the Internet Explorer rendering engine). To better guard against attack the team changed the behavior of several features, and these changes are part of Windows XP SP2. For a full explanation of these changes, see http://download.microsoft.com/download/6/6/c/66c20c86-dcbe-4dde-bbf2-ab1fe9130a97/windows%20xp%20sp%202%20white%20paper.doc . Many of the changes attempt to limit HTML scripting attacks, especially those occurring in the My Computer zone. The Internet Explorer team made some big changes to help thwart these attacks. Because many applications use the Internet Explorer rendering engine to display HTML content, the team needed to ensure that these applications weren t broken by the security changes. To accomplish this, by default, only the Windows Explorer and Internet Explorer processes are affected by the security changes. Other processes can opt-in by setting registry keys for specific options. See http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx for the specifics of how these registry keys can be set. If your application hosts Trident, you should investigate whether you can opt-in to the security changes. If you don t opt-in, attackers might use your application as an attack vector when attempting to exploit a bug in another application. Some of the larger security changes related to the browser in Windows XP SP2 include the following:
Important test cases related to the Windows XP SP2 changes When testing your application, you should perform two important categories of tests related to these changes. First, if you are hosting Trident, opt-in to the more secure functionality. Test this by setting the registry keys to the more secure settings (as described at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx ) and use your application. Second, verify that your application s security model is as tight as are the Internet Explorer changes in Windows XP SP2. Many times functionality similar to the browser functionality is implemented, and programmers use the security model of the browser as a guide for how their security should work. For example, allowing links from the Internet zone to the My Computer zone might have been allowed in the browser at the time the programmer introduced similar functionality into the product you are testing. In Windows XP SP2, links such as this are blocked. If your application doesn t provide the same security protections , it might be used by an attacker as a way to work around some of the Windows XP SP2 mitigations. Issues like this are important to find and fix. |
EAN: 2147483647
Pages: 156