Understanding Common Ways Clients Receive Malicious Server Responses |
Myth: It Is Difficult for an Attacker to Create a Malicious Server |
Chapter 4, discusses how unexpected malicious data can be sent from client applications to server applications and how server applications often erroneously trust such malicious data. This chapter builds on that concept and shows how the same problem can arise when client applications erroneously trust data sent from servers. This chapter discusses how attackers can send malicious responses to client applications and details easier ways testers can send malicious responses to client applications, the common types of malicious response bugs, and tips on testing clients against malicious responses.
Malicious response scenarios are real. Many involve factors outside of the client application’s control. When a factor outside the client’s control is compromised, it is important that the client application prevents additional compromise. A few ways a target’s client application can connect to a malicious server or receive malicious responses from a server include the following:
Client application knowingly connects to an arbitrary server.
Attacker performs a man-in-the-middle (MITM) attack.
Attacker controls or poisons the Domain Name System (DNS).
Server socket is hijacked.
The following section covers the details of these scenarios.
Client application knowingly connects to an arbitrary server. Most client applications are designed so that the client machine cannot be harmed when it connects to arbitrary servers. For example, a Web browser should not be harmed when it loads data from a server even if malicious data is encountered. However, this is not always the case. If a client issues requests to a malicious server, the server’s responses could be designed to exploit bugs in the client.
Often, the target’s client need not directly specify the malicious server to connect to. An attacker can use various methods to trick a victim’s client into connecting to arbitrary servers. For example, a protocol handler hyperlink such as ftp://ftp.example.com could be used to force an FTP client to connect to ftp.example.com when the hyperlink is clicked. JavaScript can also be used to automate activating a hyperlink so the victim doesn’t even need to click the link. Another example is when ActiveX controls are used to force a client to connect to a server of the attacker’s choice. For example, Adobe Acrobat, RealNetwork RealPlayer, and Microsoft Windows Media Player all allow callers of their controls to specify to which server the client should connect without user intervention. It isn’t hard to get a target to connect to a malicious server when functionality like this exists.
Attacker performs a man-in-the-middle. (MITM) attack. Some clients don’t allow the server to be specified. These applications typically connect only to a set of predefined trusted servers. Neither the user nor the attacker can specify the name of another server in this situation. However, an attacker might be able to intercept the network request to the server and respond with malicious data or intercept the response from the legitimate server and modify it. This is known as an MITM attack.
Important
When users connect to untrusted networks that connect unknown other users, such attacks as the MITM attack are easier to pull off. How secure is your computer when you connect to a hot spot at the local coffee shop? Do you know for sure whether you are connecting to the coffee shop’s network or to a rogue access point pretending to be the coffee shop’s network? Do you really trust the other users on that network?
Attacker controls or poisons the DNS. In situations in which a client connects to a server by name, a DNS server is used to look up the IP address of the server. If the DNS information is controlled by an attacker, the lookup procedure might return the IP address of the attacker’s server instead of the legitimate server’s IP address, resulting in the client being directed to the attacker’s machine. For more details, including several different attacks that allow DNS poisoning, see http://www.lurhq.com/dnscache.pdf.
Important
Similar to DNS cache poisoning, a Web proxy’s cache can be poisoned. The result is the attacker’s response is sent to the client instead of the legitimate server’s response. HTTP splitting is one way of poisoning a proxy’s cache. HTTP splitting is discussed in Chapter 10.
Server socket is hijacked. When a program binds (associates) a local address with a port, the default action is for the program to associate all local addresses with that port. Even machines with one network card typically have at least two IP addresses—an externally reachable address and the localhost address (127.0.0.1). It is possible for two programs to listen on the same port when different addresses are associated with that port. For example, one program could listen on port 80 for the external IP address while a separate program listens on the same port for the localhost address. Although a program might be listening on a port for all addresses, it is possible for another program to request the same port for a specific address. When a connection is made for the specific address, the program listening specifically for those requests will receive it. This is illustrated in Figure 5-1, which shows that the rogue program will receive all network requests with the destination IP address of 192.168.1.188 on port 8080 because the rogue program is more specific in what it is listening for than the legitimate program is.
Figure 5-1. A rogue program listening specifically for requests for IP address 192.168.1.188 on port 8080
Socket hijacking is a potential security problem in server software. If an attacker can gain user-level (nonadmin) access on the server, by listening on a specific address the attacker can attempt to receive requests normally received by a server process on the same machine. If a socket can be hijacked, the server program that opened the hijacked socket contains a bug that should be fixed.
Tip
Applications on UNIX-based operating systems are also potentially vulnerable to socket hijacking. Most UNIX systems require admin/root to open a socket port 1024 and below.
The Netcat tool (http://www.vulnwatch.org/netcat/) is useful in testing for socket hijacking vulnerabilities. Once the target server program is listening on a port, issue the following command line as a user:
nc -s <IPAddress> -p <PortNumber> -v -l
where IPAddress is the address on the server to hijack and PortNumber is the port to hijack. The account used to launch the Netcat command should be different from the one used by the server process. Once the Netcat command is issued, attempt to make a connection to the server. If Netcat receives the connection, the server application is vulnerable to socket hijacking.
Tip
In versions earlier than Microsoft Windows Server 2003, developers explicitly had to block socket hijacking by setting the SO_EXCLUSIVEADDRUSE flag. As a result, many server applications are vulnerable to this attack. For example, we recently tested several server applications and found most to be vulnerable.
In Windows Server 2003, Microsoft enhanced socket security so that by default sockets are not sharable. More information about this change and socket hijacking is available on Microsoft Developer Network (MSDN) at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_reuseaddr_and_so_exclusiveaddruse.asp.
Secure Sockets Layer (SSL) can mitigate some malicious response attacks. If the client uses SSL and checks that the server SSL certificate is valid—it is from a trusted certificate authority (CA), it has not expired, the name of the server to which the client has connected matches the name on the certificate, the certificate has not been revoked, and so forth—MITM attacks, DNS control and/or poisoning, and socket hijacking attacks won’t work. However, SSL doesn’t stop attacks in which the attacker coerces a target to connect to an arbitrary server (the first case described earlier). Even if SSL is used to connect, an attacker can legitimately obtain an SSL certificate for malicious use.
Important
The target client is in trouble if MITM attacks, DNS control/poisoning, or socket hijacking can occur. Client applications should be written carefully to ensure that the client doesn’t become compromised as a result of such attacks.
Also consider that a server that is normally trusted could be compromised. In this scenario, the attacker’s data could be sent from the server over SSL. It is important to consider how much a client should trust a server.
For example, to mitigate a server compromise, programs that automatically download and install updates often check the signature of the update. To make it more difficult for an attacker to tamper with updates the private key used to sign the updates should not reside on the server. Without a defense-in-depth measure like this, an attacker that compromises the update server would then be able to install and compromise any client that requests updates.
The same techniques that are used to send malicious requests to a server can also be used to send malicious responses to a client, except for only a few differences. Instead of creating a custom client, a custom server can be made. Instead of hooking requests to the server, hooking responses to the client can be performed. Programs such as Netcat can be used to listen on an arbitrary port to send custom responses. Proxying responses instead of requests is done in the same manner.
Just as sending unexpected malicious requests is an entry point for server applications, sending unexpected malicious responses provides a great opportunity for client attacks. Following are some of the common types of bugs found when sending malicious responses (the chapter in which more information can be found about these attacks is shown in parentheses):
Spoofing (Chapter 6)
Information disclosure (Chapter 7)
Buffer overflows (Chapter 8)
Format strings (Chapter 9)
Domain/zone elevation (Chapter 10)
Important
Malicious response is an area ripe for finding bugs. Many developers don’t anticipate this when they write client applications. For example, while we were writing the Web Proxy Editor that is included on this book’s companion Web site, we wanted to make sure the tool worked well for manipulating server responses. The goal was more to make sure Web Proxy Editor worked properly than it was to find vulnerabilities in the application we were using through the proxy. Yet, within 30 minutes, we were able to find a way to run arbitrary code on the client machine by sending a malicious response.
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.
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.) Security updates have been issued for this specific problem in telnet.
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.
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.
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. For example, if the filename ..Documents and SettingsusernameStart MenuProgramsStartup rojan.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.
When we started finding malicious response bugs using the proxying approach (using Web Proxy Editor), some developers started pushing back about the importance of these bugs. They didn’t think it was practical for an attacker to create a server that would send the malformed responses. In the malicious request scenario, attackers can make manual modifications when they want to attack the server. In the malicious response scenario, attackers need to get a target to connect to their server so that they can send the malicious responses. Because attackers don’t know when their victim will connect to the malicious server, automation is helpful. We wanted to show developers that it is extremely easy to create a server that would respond with the malicious data normally created in Web Proxy Editor manually. The solution was to use a small tool named EvilServer.
Once you find a bug manually using Web Proxy Editor, you can use the EvilServer tool (included on the companion Web site) to reproduce the bug. Web Proxy Editor logs all of the data sent through it, including modified data. EvilServer acts as a small Web server. If a client makes a request matching an entry in the Web Proxy Editor log, the corresponding response is sent back. This allows you to create in minutes a server for any malicious response you like without writing any code. Complex clients often make many requests for other server functionality before the response of interest is sent. By using Web Proxy Editor and EvilServer, you can record and replay any set of HTTP functionality to satisfy prerequisite requests and responses needed by the client.
A downgrade MITM attack allows an attacker to force the client and/or server to use a less secure protocol or set of functionality that is supported for legacy client/server compatibility. Sometimes clients support connecting to servers that contain different features or different versions of a feature. Clients and servers often negotiate which features and feature versions should be used. For example, many Secure Shell (SSH) clients support both versions 1 and 2 of the SSH protocol and several different encryption ciphers. (SSH is an encrypted network protocol for connecting to machines to provide command-line access.) Version 1 contains protocol flaws that can allow an attacker to see the normally encrypted data exchanged between the client and server. This flaw is described in detail at http://www1.corest.com/common/showdoc.php?idx=82&idxseccion=10. For this reason, most people use SSH version 2.
However, for backward-compatibility reasons, many servers and clients still support version 1. Using an MITM attack, an attacker can tell the server and client to use the vulnerable SSH version 1 protocol before encryption begins. To prevent this attack, most SSH clients and servers can be configured to use only version 2 of the protocol. An easy way to test that the client honors this restriction is to proxy the network traffic and tell the client to use an older version.
Several clients have issues around downgrade attacks. In July 2003, Marco Valleri and Alberto Ornaghi presented information on several protocols that have downgrade problems, including SSH, Internet Protocol Security (IPSec), and Point-to-Point Tunneling Protocol (PPTP). Their presentation can be found on the Black Hat Web site (http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-ornaghi-valleri.pdf).
Important
Some Web logon forms are displayed using HTTP and are submitted securely over Secure HTTP (HTTPS). This is dangerous! Similar to downgrade attacks, if attackers are able to hijack the HTTP response, they can specify the place to which the logon information will be submitted, such as to their server. To prevent this, it is recommended that the server use SSL to send forms requesting sensitive information and receive sensitive form data.
Following are several tips to help you test sending malicious server responses to a client application.
The same concepts that are important in making malicious client requests are important when sending malicious server responses. The same tools work in both scenarios, including Web Proxy Editor, Jiri Richter’s MITM tool, and Netcat.
Malicious responses are an entry point into the client. This entry point can allow for finding bugs in many categories. For example, buffer overruns, information disclosure, spoofing, and so forth. It is important to understand how the client interprets data it receives.
If you have access to the source code of the client, it is useful to set breakpoints on common functions used to retrieve data from the network. These include recv, WSARecv, WSARecvEx, and WSARecvFrom. This enables you to see exactly which data is received by the application and to follow its use through the code.
It is interesting to replace URLs sent by the server with URLs of other servers. Web browsers have a well-defined security model that does not allow them to access data from another domain. Sometimes because the legitimate server sends only relative URLs, the client won’t perform any validation and will blindly follow full URLs to other servers. This allows malicious responses to cause data from other servers to enter the client while the user and client code think only the server to which the client is directly connected is being used. This issue, known as domain/zone elevation, is discussed further in Chapter 10.
SSL provides no protection if the client can connect to arbitrary servers. Attackers can legitimately set up their own servers that use SSL.
If the client connects to only specific servers over SSL, test to ensure the client verifies the SSL certificate is from a trusted certificate authority, that it is not expired, that the server name matches the name on the certificate, that the certificate has not been revoked, and so forth.
Many system application programming interfaces (APIs) automatically perform certificate checks. However, parts of these checks can be disabled. It is easy to find bugs where the checks have been disabled through white box testing. Look for the following ways to disable certificate checks:
The SCHANNEL (Secur32.dll) ISC_REQ_MANUAL_CRED_VALIDATION flag can be passed to the InitializeSecurityContext function to bypass certificate validation that the system normally performs.
The WinInet (Wininet.dll) INTERNET_FLAG_IGNORE_CERT_CN_INVALID (which bypasses server name/certificate name match checks) and INTERNET_FLAG_IGNORE_CERT_DATE_INVALID (which bypasses date checks) could be used when calling HttpOpenRequest and InternetOpenUrl.
The WinHTTP (Winhttp.dll) WinHttpRequestOption enumeration type contains the WinHttpRequestOption_SslErrorIgnoreFlagsWinHttpRequestOption_SslErrorIgnoreFlagsSets, which can be configured to ignore various certificate problems. More information about this is available on MSDN (http://msdn.microsoft.com/library/en-us/winhttp/http/winhttprequestoption.asp).
Be mindful of the downgrade attack. If the client supports legacy versions of the server and there are security concerns around legacy support, it is helpful to have a client option to communicate only with specific versions of the server.
Even when other components are compromised, connecting clients should not be compromised. For example, if an attacker poisons the DNS and sends malicious responses from an imposter server, the client application shouldn’t allow the attacker to take over connecting clients.
Fuzz responses. Fuzzing server responses is often overlooked, but is a useful way to find malicious response bugs.
Clients can receive malicious responses from servers in many ways that are out of their control. Client programs should not blindly trust server responses and should not allow the client to be compromised as a result of malicious responses. The same approaches used to send malicious requests when testing can be used to send malicious responses. It is usually not difficult for an attacker to create a malicious server.