Process Explorer by Sysinternals gives you a great deal of information about a process, such as which files, registry keys, threads, and so forth it is currently using. This tool is useful if you want to see the files in use when running the application. After starting Process Explorer, you will see all of the running processes on the system in the upper pane and the handles they use in the lower pane. Figure 7-1 shows the handles that are used by the process msmoney.exe, which are shown after you start Microsoft Money 2005 and log on to an account.

Figure 7-1. Using Process Explorer to see the handles used by Microsoft Money 2005

As the output indicates, Microsoft Money creates several file handles that need to be examined for information disclosure vulnerabilities. It turns out that Money uses the user’s profile directory to store data, including temporary files, which helps protect the data.(See Figure 7-3.) If you double-click a file handle, the Properties dialog box lists detailed information about the file, including the security permissions set on the file. If files are created using weak permissions, even if the files exist for a short amount of time, an attacker can take advantage of this vulnerability.

The list of processes shown in Figure 7-1 is not complete enough to determine all of the files used by Microsoft Money. What about files that are accessed only when the application performs certain functions? Also, Process Explorer shows only the current files in use, so some files that are opened and closed quickly are listed only intermittently. For instance, sometimes developers write data to a temporary file, and then rename the file to the destination file. They assume this practice is safe because the window of opportunity might be small for an attacker to take advantage of the temporary file—but exploiting a temporary file whose existence is brief isn’t impossible, it’s actually pretty easy. This type of race condition attack, as it is called, is discussed in more detail in Chapter 13. To help catch these issues, you can use File Monitor.

File Monitor (Filemon) is another great tool by Sysinternals that supplies the details about all the file accesses that occur on the system. Because a lot of file accesses constantly take place on a system, it is useful to apply a filter for just the application you are testing. Upon starting Filemon, the dialog box shown in Figure 7-2 will appear to enable you to configure filtering.

Figure 7-2. Filemon Filter dialog box, which can be used to reduce the amount of information that is monitored

For example, you can set Filemon to capture only the file access for the application by entering a value in the Include text box. Also, you can configure Filemon to log only certain types of file operations, and you can use the Highlight feature to indicate file operations that contain certain values such as temp, log, backup, or windows so that you might easily spot potential problems. Figure 7-3 shows the files that Money accessed when starting the application, logging in, closing the application, and having the application automatically back up the data.

Figure 7-3. Output of Filemon while monitoring Microsoft Money 2005

Making sure the data is written to a safe location is the true defense against information disclosure bugs in a file. When the file has proper access controls, it makes it difficult for the attacker to obtain the data. In general, on computers that run the Microsoft Windows operating system, files that are user-specific should be written to the user’s personal profile directory. That way, the operating system sets the proper permissions on the file.

A logical place for developers to store temporary files is in the temporary folder. But which temporary folder? There is more than one: the user-specific temporary folder and the system temporary folders. The user-specific temporary folder generally is %USERPROFILE%Local SettingsTemp (for instance, this expands to “C:Documents and SettingsusernameLocal SettingsTemp”). The %TEMP% or %TMP% environment variables generally expand to this folder location, too. In addition, there is the system temp folder at %WINDIR%Temp and potentially others such as c: emp and c: mp. These, too, can be considered temporary folders, but they might not be safe, depending on what permissions are set on them and what the data is; they might not be safe for sensitive user data.

Insecure temporary folders can lead to several types of attacks. For example, if an application extracts a CAB file to a temporary location that has weak permissions, attackers have a window of opportunity to replace the data extracted to that location with their own data. If an administrator is using the application, the attacker might be able to exploit this bug to gain elevated privileges and then trick the administrator into running the attacker’s code.

The main point is that many times applications are designed to write data to a specific location without considering who else might have access to that location. As such, an attacker thinking maliciously might be able to take advantage of such weak access controls.

Even if files are written to a folder on which strict permissions are set, the application can change the permissions of the files at run time. Chapter 13 delves into more detail about permissions, but essentially you need to make sure the files location’s permissions are not weak.

On November 6, 2005, Thomas Wolff discovered a vulnerability in fetchmail, a Linux utility used to retrieve and forward e-mail on remote systems. In this information disclosure bug, the fetchmail program would write user names and passwords to its configuration file before closing it and properly setting permissions for the owner on that file. This race condition allowed an attacker to view its contents before the proper permissions were set.

If, for instance, an application has an auto-save feature that writes temporary data to the hard drive without the user’s knowledge, the file might be compromised if an attacker is able to determine its existence and access it. You must ensure filenames and paths are not predictable to prevent this sort of information disclosure bug.

Predictable names essentially are ones that can easily be guessed, such as for files created sequentially (file01.txt, file02.txt, etc.) or that use a simple naming scheme like username_date.txt (for example, bryan_20050101.txt).

Although there are application programming interfaces (APIs) that can be used to create random filenames, such as CreateTempFile, sometimes developers do not use them. And although a filename might look random, it might be predictable. For instance, an application might create a temporary file using the tick value of the system. If so, an attacker could exploit this vulnerability by guessing the tick count of the system. Also, if the attacker has permissions to list the folder contents, using random filenames would not improve security because the attacker could repeatedly enumerate the directory to obtain the random filenames. If an attacker does not have the ability to enumerate a folder, be sure not to use a predictable folder name.

When a file is created, sometimes metadata is saved along with it. For instance, most digital cameras store extra data from the camera in the picture itself. You can sometimes see this data by opening the picture file’s Properties dialog box and viewing the Advanced Summary. Figure 7-4 shows an example of metadata stored in a JPEG taken with a digital camera. You might not think this is a big deal, but metadata could contain more sensitive data in different types of files.

Figure 7-4. JPEG metadata from a picture taken with a digital camera

A Microsoft Office Word document could also contain metadata that discloses such information as the author name, e-mail addresses, machine name used to create the file, and phone numbers. Many times the application injects this information automatically for the user without the user’s knowledge. Imagine if you created such a Word document for your application to describe the End User License Agreement and shipped it with your product. Your private information as the author would be disclosed unintentionally.

You can view a file’s properties in Windows Explorer, although this might not display all of the metadata that the file contains. Even worse, if you have used the Track Changes feature in Word, even data that is deleted from the document is still embedded in the file and can be viewed. To prevent this sort of unintentional information disclosure, you must check the file’s binary data itself to be sure it does not contain metadata.

Several tools are available to enable you to examine the contents of a file:

Even a simple Word document that contains only the word world as its contents contains a lot of information. Figure 7-5 shows the output of running Strings on such a file.

Figure 7-5. Output of Strings on a Word document containing the word world

Figure 7-6 illustrates the object linking and embedding (OLE) structure of a Word file with an embedded text file using eDoc. As you can see, not only can you see the contents of the file, but also the path information about the file that was embedded. You can also reveal this information using Strings or by viewing the data in a hex editor.

Figure 7-6. In eDoc, viewing the contents of a Word document that has a text file embedded

Instead of a Word document, what happens if you use another type of container, such as a ZIP file? Figure 7-7 shows the file opened in the hex editor WinHex. Notice that you can see the contents of the text file, too.

Figure 7-7. Viewing the contents of a ZIP file that has the text file included

Even though your application might use different structures to store data, once the format is understood, an attacker might be able to extract the information. Encryption could be used to help protect the file, but weak encryption or obfuscation attempts are guaranteed to be broken eventually by an attacker.

As mentioned in Chapter 4, the HTTP Referer header is automatically sent from a Web browser when it fetches a resource from the Internet. The Referer indicates the URL of the Web page from where the request was made. For example, if a visitor to the Web page http://www.alpineskihouse.com/page.html clicks a link to http://www.contoso.com, the Referer would be http://www.alpineskihouse.com/page.html.

Developers of Web applications should be aware that sensitive information can be part of the URL. For instance, imagine a Web-based e-mail client. If the client displays HTML e-mails, it might be possible for attackers to display an image from their server in a message. What if the URL looks like https://mail.contoso.com/inbox/bryan? When fetching the image, the attacker’s server could log the request, including the Referer. Then, not only does the attacker know that the e-mail message was read, the attacker gains the link of the Web-based e-mail server, including the recipient’s user name.

Web beacons, or “web bugs,” are a way for an application to “call home” without the user’s knowledge. Web beacons are usually transparent image files with a dimension of 1 by 1 pixels that can be embedded into a Web page, document, or other file; when the page or file is accessed, the application automatically links to the Web to download the image. For example, most e-mail clients have a read receipt feature that enables the recipient of an e-mail message to notify the sender when the message is received. Most mail clients give the message recipient options on how to handle the read receipt, such as to send the receipt or not.

However, there are other ways without the client’s permission that a malicious user can obtain information on whether the recipient received or viewed the message. For example, in the Web-based e-mail client example, suppose the client automatically displays images in e-mail messages. A malicious user could insert a link to an invisible image located on the attacker’s server in the e-mail message. When the unsuspecting user views the message, the Web-based e-mail client fetches the image from the malicious user’s server. The attacker can then check the server logs to know whether the recipient has read the message yet, bypassing the read receipt feature. If you run a network monitor such as Ethereal or Web Proxy Editor, you can detect whether an application calls home using a Web beacon.