Examples of Malicious Response Bugs

Malicious server bugs reported to the public are usually around scenarios in which the target can connect to an arbitrary server. This doesn t mean, however, there are fewer bugs in the other scenarios (MITM attacks, DNS control or poisoning , and socket hijacking). It s just that they are harder to exploit, often relying on other attacks ”for example, performing an MITM attack might require control of the DNS, and frequently they aren t publicly disclosed. The following two subsections show an example of a client that is allowed to connect to an arbitrary server and an example of a client that connects to a hard-coded server.

Example: Telnet Client Environment Variable Disclosure

RFC 1572 ( http://www.ietf.org/rfc/rfc1572.txt ) describes the telnet environment option, called NEW-ENVIRON, with which a machine can retrieve or set environment options. These variables can either be well known or user variable names. The user variable names option allows querying or setting arbitrary variables. Do you see a problem with this? Ga «l Delalleau saw an opportunity. He discovered that a malicious telnet server could query telnet clients for arbitrary environment variables. He could use this feature to gain information not usually available to him about victims that connected to his server using a vulnerable telnet client.

Not many people consciously connect to telnet servers they don t trust. So, how could an attacker force a target to connect to the malicious telnet server? It turns out a protocol handler is associated with the telnet protocol ( telnet:// ). An attacker can use the protocol handler as a URL to point to a malicious server (example: telnet://example.com ) and embed the malicious URL in a Web page that the target might visit. For example, the attacker could embed <IFRAME SRC="telnet://example.com"> to force telnet to connect to example.com. This bug affected many vendors , including Microsoft, Sun, and Red Hat. For more information about this bug, see http://www.securityfocus.com/archive/1/402230/30/0 .

To discover this bug, you need to understand how the telnet protocol works. For example, we sniffed the traffic of a telnet session and did not see the NEW-ENVIRON option used.

Important

By understanding the specification, you can invoke functionality that exists in the client but that the server has not requested .

For this specific bug, send data formatted as shown in Figure 5-2 to request the USERDOMAIN environment variable. This variable is commonly used to store the Microsoft Windows domain the user is logged on to. Pieces of information like this are useful when you are attacking a machine. On some machines we investigated, passwords were being stored in the environment variables! (Information disclosure issues are discussed in more detail in Chapter 7, Information Disclosure. ) Security updates have been issued for this specific problem in telnet.

Figure 5-2: Binary data sent to the telnet client using NEW-ENVIRON asking the client to send theuser variable named USERDOMAIN

Tip

Netcat can be used to listen on a port. To repro the telnet bug quickly, you can create a binary file using the contents shown in Figure 5-2. The command nc -l -p 23 -v < telnetFile.hex will send the contents of the file named telnetFile.hex to a client upon connection. Unlike many tools, Netcat correctly reads and sends null or other unprintable characters , making it valuable for this type of testing.

Example: File Caching Allows Arbitrary Code Execution

A friend was recently fixing a bug in someone else s code and asked for advice on how to fix it. The application he worked on requested an Extensible Markup Language (XML) file from a hard-coded server over HTTP. The XML response contained filenames that the client should download and store locally. The XML response was similar to what is shown in Figure 5-3.

Figure 5-3: XML response from the server that contains files that should be cached by the client

The functionality was intended to be used for caching images in a local directory specified by the program. For example, C:\Cached Images\. However, no precautions were taken to ensure only images were downloaded. At first glance, the bug was that if an attacker could send a malicious response, any file (image or otherwise ) could be downloaded to the C:\Cached Images\ directory. However, something worse was possible. Not only could the attacker force any file to be written to disk, but could write the file to any place specified. Forexample, if the filename ..\Documents and Settings\ username \Start Menu\Programs\ Startup\trojan.exe is sent in the XML response, trojan.exe would be written to the target s startup group and executed the next time the target logs on.

Luckily this issue was identified and fixed along with several others before the product was shipped to customers. You can find bugs like this by running an HTTP proxy whenever you test a client application that requests data over HTTP.