Locating Common Areas of Information Disclosure

By now, you should have a better understanding of what information disclosure is and the problems it can cause. The vast majority of information disclosure bugs can be found in the following areas:

• Data in files

• Data sent over a network

Disclosure in Files

All applications and services use files. This section discusses several different types of files that applications use that can disclose information. These include an application s binary files, data files, and source files. Although you must look for different bugs in each type of file, the steps used to find information disclosure bugs are the same as follows :

1. Find which files are being used.

2. Determine how the files are stored.

3. Inspect the contents of the files.

Finding Which Files Are Used

Chapter 3, Finding Entry Points, discusses how to find entry points into an application and which tools you could use to determine which files the application uses. A couple of great tools can help you identify which files your application uses:

• Process Explorer by Sysinternals shows the files in use by a particular application.

• File Monitor by Sysinternals shows all files the system tries to access.

Using these tools in conjunction with the application identifies any files that are used. Let s look at how you can use these tools to inspect which files are used.

Process Explorer     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.

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

Important  

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, Finding Weak Permissions. To help catch these issues, you can use File Monitor.

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.

How Files Are Stored

As mentioned, an application might use several files while running, especially for features thatcache or auto-save data. If these files contain useful information, an attacker might be able to take advantage of them. To help mitigate information disclosures in such files, check the following:

• Temporary files are written to a safe location.

• The permissions on the files are not weak.

• Filenames or paths are not easily predictable.

In addition to these checks, you might have to take extra measures to ensure the file does not disclose any information. For example, even if a file is deleted or a disk is formatted, anattacker with access to the disk might be able to recover deleted data. Also, if an attacker has access to pagefile.sys and hiberfil.sys, information stored in memory that is not deletedand written over might not be safe if it was paged to disk or the system was put in hibernation.

Ensure Data Is Written to a Safe Location     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.

Note  

Different operating systems might store a user s personal data in a specific directory and handle permissions differently from the Windows operating system.

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 Settings\Temp (for instance, this expands to C:\Documents and Settings\ username \Local Settings\Temp ). 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:\temp and c:\tmp. 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.

Ensure the Permissions Are Not Weak     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.

Important  

You should make sure that the file does not allow access to users who should not be able to access it. Chapter 13 discusses the principle of least privilege to help you determine who needs access.

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.

Check Predictability of a Filename or Path     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 .

Filename predictability  

Although this attack might seem far- fetched , it does occur. In one case, we tested an application that used a file to store the location of a file path that was uploaded using a particular Microsoft ActiveX control. Not only was this done without notifying the user, the file was written to a location that Everyone had access to. When we reported the bug, the developer stated that the filename was a globally unique identifier (GUID) and would be hard for an attacker to guess. This might be true if the filename was dynamically generated, but in this case it wasn t. Although the filename was indeed a GUID, the value was hard-coded in the application, so it was always the same GUID. As such, attackers could use a utility like Filemon to detect when the file was created, and then to determine the last location of a file that was uploaded using the control.

Inspecting the Contents of Files

When a file is created, it might contain data the user might not have expected to be included. You should inspect the contents of files that your application produces and also the application s program files. If the application is writing data to an unsafe location that uses weak permissions, that is a security bug, even if the practice doesn t seem to disclose information directly. Here are some examples of the kinds of data a file might disclose, depending on the file type:

• Application binary files

  • Internal machine names

  • Internal Web sites

  • Secrets used in encryption algorithms

  • Hard-coded user names and/or passwords

• Application data files

  • User s personal information

  • Application version

  • Deleted data

  • Machine name

• Application source files

  • Author information

  • Bug IDs

  • E-mail addresses

  • Internal machine names

  • Comments that indicate bugs ( // HACK , // TODO , // BUG , etc.)

Easter eggs  

Easter eggs are hidden features in an application that were added to provide some form of credit to the people who worked on the product. Whereas some people think Easter eggs are cool and creative, others find them a nuisance. After all, when you pay for an application, you probably expect to pay for the actual features you use, not those developers secretively add for personal recognition.

Although Easter eggs might not disclose sensitive information, they are often considered a waste of space and resources. Some companies such as Microsoft now have policies prohibiting shipping Easter eggs. Also, would you ship an untested feature? Unless a developer discloses the Easter eggs prior to shipping the application, they can be hard to find and test. Here are a few methods that will help:

• Run a tool called Strings.exe (discussed in the section titled Viewing the Data later in this chapter) on the binary.

• Search the source code for suspicious strings.

• Use WinHex to inspect memory when the application is running.

Embedded Metadata     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: PEG 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.

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

• Strings by Sysinternals is used to view the strings in a file.

• A hex editor, such as WinHex, enables you to view the binary contents of a file.

• eDoc by eTree is an editor you can use to view or edit document files, such as Word documents.

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.

Disclosures over a Network

When testing network applications for information disclosures, you should ask a few questions about your application:

• Are any requests and responses unexpected?

• Is more information sent than necessary?

• Are the error messages too revealing ?

• Is sensitive data protected?

Sometimes an attacker can alter the request and get the application to return additional data that it shouldn t. Refer to Chapter 4, Becoming a Malicious Client, to understand how to bypass client-side validation, which might help pass values that would normally be blocked. Although some of the data might be visible to the user, sometimes extra data is returned that is not displayed, so you need to use tools to examine it.

Determine What Data Goes over the Network

Chapter 3 discusses tools that could be used to determine which ports an application opens on a machine and how to monitor data going over the network. Several tools can be used to help monitor this data, such as Ethereal and Web Proxy Editor. You should also be aware that sensitive data could be sent in the padding of an IP packet. Some tools that operate at the TCP level ignore the padding, and the information goes undetected.

Important  

The quality of the tools you use to gather information can make a difference between finding or missing the bugs. You should also understand the functions and limitations of the tools.

A tool called Scapy, which runs on Linux, allows packet manipulation, including data contained in the padding. Refer to http://www.secdev.org/projects/scapy for more information.

Providing Too Much Information

Now that you know what data is being sent across the network, you can determine whether too much information is being revealed, especially to unprivileged users. If your application has features that attempt to protect a user s anonymity, you should think of other ways that a malicious user might be able to defeat those features. Following are two examples:

• HTTP Referer

• Web beacons

HTTP Referer     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     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 .

More info  

In addition to Web beacons, a Web site might use other mechanisms, such as cookies or the last-modified header, to track the browsing behavior of a user.

Fingerprinting  

Some applications make the name and version of the software being used obvious. An application might have a splash screen that reveals this information while it starts, or the software s name and version might appear in the title bar or be displayed in the About dialog box. Although you might think such information is useless and generally not important to an attacker, imagine if an attacker could easily determine which specific application and version a target is using. The attacker can then target attacks specific to the vulnerabilities of that piece of software. Just like fingerprints can identify individuals, application fingerprints can identify which version of software is running and which security vulnerabilities affect it. To an attacker, this information disclosure can be useful, especially if the application allows network connections.

A lot of applications, including both servers and clients, actually reveal fingerprints. If you notice that your application is allowing fingerprinting, you should determine why it needs to do this, think of how the revealed information could be abused, and decide whether the behavior could be changed to bolster security.

Error Messages

The preceding sidebar covers how applications sometimes reveal too much information that can assist a malicious user. Similarly, you might not think twice about error messages that an application displays. For instance, how many times have you browsed to a Web site, and then received an error as shown in Figure 7-8?

Figure 7-8: Web site displaying a database error

As a user, you might be frustrated because the site does not appear to be working properly; however, to a malicious user, this error message discloses a lot of interesting information:

• Uses Open Database Connectivity (ODBC) Access driver

• Runs the Apache Web service

• Runs PHP

• Shows the location (path disclosure) of the script on the server s file system

• Indicates a SQL SELECT statement is being constructed

• Server is not using an English language setting because the word program in Program Files is spelled as programme, as used in European languages

Obviously, the server is not handling error messages properly, which indicates there might be a weakness in the script ”which makes this a great target for an attacker.

Sometimes testers focus on only the valid input to make sure an application functions properly. But it is vital to force applications into error cases to see what happens and to view the error messages that are displayed and the information they can reveal. You will often find that the errors are not handled properly and are simply returned to the user.

Whereas the error message displayed in Figure 7-8 was caused by the application not handling an error from the system, applications can also return error messages that disclose too much information. For example, the following graphic shows an example of a real Web site and the information disclosed in its error messages. The figure shows a Web site s login form.

If the user types in an invalid user name, the following error message is displayed.

Can you see an information disclosure problem in the error message? It might not be very obvious at first, but the error indicates that specifically the user name is invalid. When the user types in or guesses the valid user name, the error message changes as indicated in the next graphic:

Now that the user name is known, half of the puzzle is solved . If the first error message displayed in the beginning simply indicated that the login information was invalid, it would be harder for a malicious user to narrow down whether the user name or password was the problem.

Use secure error messages  

Sometimes we have even seen error messages indicate which of the characters in a logon attempt are invalid and reveal the maximum number of allowed characters in a password. Although these error messages are intended to help a user log on correctly, they are inadvertently assisting malicious users, too. Remember, while error messages can reveal useful information, think how an attacker might be able to use that same information.