Chapter 4: Becoming a Malicious Client

This chapter discusses how developers can sometimes mistakenly trust data received from a client in sever-side code and how an attacker can take advantage of these mistakes. Here, we discuss the general approach for sending malformed data using arbitrary protocols and the tools that can assist in sending malicious data. Because HTTP is so widely used, the second half of the chapter details malicious client attacks over this protocol. This chapter also discusses several bugs specific to sending malformed requests; however, you should consider the sending of these requests as an entry point to server applications. You can apply the techniques used to send these requests when searching for other bug types. For example, malicious requests often result in information disclosure (see Chapter 7, Information Disclosure ), buffer overflows (see Chapter 8, Buffer Overflows and Stack and Heap Manipulation ), script injection (see Chapter 10, HTML Scripting Attacks ), SQL injection (see Chapter 16, SQL Injection ), and many other types of bugs. Chapters discussing these bugs build on the information presented in this chapter.

Client/Server Interaction

Today many applications use the network for some or all of their functionality. These applications can act as clients that connect to servers, which can provide additional functionality. Some examples of these clients include the following:

  • Web browsers     Connect to Web servers to display Web content

  • E-mail clients     Connect to mail servers to send and receive e-mail

  • Media players     Connect to video and audio streaming servers

  • Word processors     Connect to Web and file servers to retrieve and store documents

In these examples, server-side code processes requests from the client. For example, the mail server contains code to process sending and retrieving e-mail messages. Often, well-defined specifications describe how clients should form requests and how servers should respond to these requests. Well-written server code assumes any data can be sent to the server. However, some server developers mistakenly think that only legitimate requests, requests that conform to specifications, will be sent to the server. Other developers acknowledge the possibility that a malicious client will send malformed requests, but they believe that the difficulty of forming such requests ” especially if public documentation on how to make requests to the server does not exist ”will deter making such requests.

It is the security tester s job to violate these assumptions and find these sets of security vulnerabilities before attackers do. First, it is necessary for the security tester to know what kinds of requests the server accepts before attempting to send malicious requests to the server.

Finding Requests the Server Normally Accepts

Following are three ways you can discover the format of legitimate server requests:

  • Read the documentation.     Usually, well-established open protocols are documented in Requests for Comments (RFCs). RFCs are available from the Internet Engineering Task Force (IETF) at http://www.ietf.org . However, documentation isn t always available, and when it is, you cannot assume that the code you are testing is written to specification and that no additional requests are supported.

  • Read the source code.     If you have access to the source code for a client that connects to the server, you can see exactly how requests are normally made to the server. However, if the source code is not available, you can still see how the process works by reverse engineering either the client or server code. Reverse engineering a server binary is very time-consuming but can provide a definitive list of the types of requests the server accepts. For more information about reverse engineering, see Chapter 17, Observation and Reverse Engineering.

    Tip  

    If you can, it is often helpful to talk to the server designers and programmers. They can answer questions on how the data is formatted and accepted and can point out specific parts of the code that are of interest.

  • Watch network traffic.     Another way to discover the format of normal requests is to use the client against a server and monitor the network traffic. Many client applications make network requests without the end user s knowledge: sometimes programs phone home to their creator to check for updates, report to the vendor how the program is used by the user , and for other reasons. It is important for security testers to know how to use a network monitor (also called a sniffer ) to identify which applications make network requests and how these requests are formed .

Tip  

Sometimes it might not be obvious to the end user that an application is connecting to the network. This chapter explains how security testers must violate the server s trust of the client by making malicious unexpected requests, but sometimes the content of the network traffic is a security problem in itself. For example, if passwords are sent across the network in plain text, people who monitor, or sniff , can easily obtain the passwords. Disclosing information on the network like this is discussed in more depth in Chapter 7.

Sniffing Network Traffic

Many tools can be used to sniff network traffic. One of the most common free sniffers is Ethereal ( http://www.ethereal.com ). By using a sniffer, you can easily determine whether specific actions in the application send network requests.

For example, to see whether Microsoft Windows Media Player (WMP) version 10 makes any network requests when the application is loaded, you could set up a sniffer, load the application, and then examine the data the sniffer captures. In this example, many network requests are made when the WMP application loads. Some of these network requests are shown in Figure 4-1. By sniffing the application s network traffic, you can see how WMP communicates with the server over HTTP and which specific requests are made. The WMP privacy policy notes that this application makes network requests such as this, but many other applications make network requests without the user s knowledge or permission.

image from book
Figure 4-1: Ethereal showing the list of packets captured (top pane), decoded details of the selected packet (middle pane), and raw packet data (bottom pane)

Here are a few handy tips to consider when using a sniffer:

  1. Disable extra network cards.     If you have multiple network cards connected to the network you are monitoring (for example, a wireless and a wired card), disable network cards that aren t being sniffed at the operating system level. This guarantees that traffic will go through the interface you are monitoring.

  2. Disable promiscuous mode.     Promiscuous mode allows the network sniffer to capture all traffic the network card can see. This traffic includes network requests between computers other than the one on which the sniffer is running. By disabling promiscuous mode, you will capture only traffic sent to or received from the machine running the sniffer.

Sniffer best practices  
Important  

Because promiscuous mode allows computers other than those sending or receiving a specific network request to see the network traffic, attackers can use it to spy on others traffic. Knowing this enables you to be aware of exactly what an attacker is able to see in network traffic.

  • Enable network name resolution.     Network name resolution converts the numeric IP addresses for the traffic capture into human-readable names (if available), making it easier for you to understand which machines are involved.

  • Use decoders to your advantage.     Most sniffers include decoders for many network protocols. These decoders parse each part of the packet into a more understandable and human-readable format. Ethereal currently includes more than 700 decoders for various protocols, including FTP, HTTP, Microsoft Exchange Messaging Application Programming Interface (MAPI), BitTorrent, and America Online s instant messaging protocol.

  • Manipulating Network Requests

    Once you have determined that a program makes a network request to the server you are testing, you need a way to manipulate the requests. Manipulated requests can contain information not normally sent by legitimate clients. Some common ways to manipulate network requests include the following:

    • Use a program that contains a user interface to construct single network requests.     For less complex network requests, you might be able to construct single requests by hand in a program that allows you to enter exactly what you want to send over the network and to specify where to send it. Hooking and proxying (discussed later) require triggering the functionality in the client application so that the data can be modified and sent, which can become time-consuming. To test formatting data quickly in many different ways, a program that allows custom packet construction often is efficient. A tool that enables you to construct hand-crafted Web traffic is the Microsoft WFetch tool ( http://download.microsoft.com/download/iis50/Utility/5.0/W9XNT4/EN-US/wfetch.exe ). One drawback of this approach is that sometimes the network request being tested requires the server to be in a certain state. To put the server in the correct state, several specific network requests first need to be made. Depending on how complex these requests are, it might be easier for you to write a custom client.

    • Write a client to send custom requests.     One way to send malformed requests is to write your own client, which isn t limited to sending legitimately formed data the way the normal client is. Often, writing a client is a time-consuming effort and requires a good understanding of the details of the protocol used. However, writing the entire client from scratch often isn t necessary because you might have access to the source code of a legitimate client (including open source clients) that could be modified to send malformed requests. Because the goal is to test the server, not write a custom client, alternative approaches should be considered first.

      Tip  

      To write a custom client to send a few requests, you can use sniffers in conjunction with a scripting language such as Perl, Tcl, or Python to quickly create a fake network client using just a few lines of code. If scripting languages don t suit you, both ava and the Microsoft .NET Framework family of languages also offer rich standard libraries to make network programming simpler. The sniffer can be used to determine what the request normally looks like, and your code can be used to create permutations of that request.

    • Hook the legitimate client s network requests.     Hooking a program is when some part of the normal program s runtime is caught (or hooked), allowing for modification of the flow of execution or of the program s data. For example, hooking the WSASend function included in the Winsock code library (used to send data over the network) would enable you to call custom code of your choice instead of the normal Winsock code. If you hooked Winsock, you would have access to the data that the legitimate client application is attempting to send. You could then modify that data as desired before sending it over the network. Several libraries are available to assist you in hooking system library calls. A popular one is the Microsoft Detours package ( http://research.microsoft.com/sn/detours/ ). Hooking certainly can save a lot of time compared to writing a malicious client from scratch; however, it is sometimes a bit of work to do right.

    • Use proxy requests.     Similar to hooking, you can use a network proxy to force existing clients into creating malformed requests. Security-testing proxies receive network traffic normally sent between a client application and server and allow the traffic to be modified before forwarding it to its original destination. This approach can save a tremendous amount of time compared to the two preceding approaches. Tools in this category include Imperva Inc. s Interactive TCP Relay (ITR) ( http://www.imperva.com/application_defense_center/tools.asp ) and Jiri Richter s Man in the Middle tool (included on this book s companion Web site) for generic TCP proxying. For Web-specific traffic, Paros ( http://www.parosproxy.org ) and Web Proxy Editor (also included on the companion Web site) are useful tools.

    Using a Proxy to Modify TCP Traffic

    As discussed, one of the fastest ways to begin altering network traffic is to proxy requests. Generic TCP proxies need to obtain the following configuration information:

    • Remote server     The server IP address or name to which requests are normally sent

    • Remote port     The port on which the remote server expects to receive requests

    • Local port     The port on which the proxy tool should listen for requests

    Jiri Richter has written a generic TCP proxy named MITM (available on this book s Web site) that can be used to modify arbitrary TCP traffic. In addition to allowing modification of existing traffic, this tool allows you to inject additional hand-crafted packets sent to either the server or the client.

    If you want to test a telnet server using the proxy approach, set the test server as the remote server and set 23 as the remote port. If you don t already know the port, you can determine it by using a sniffer when the client is directly connected to the server. Figure 4-2 shows MITM configured to proxy telnet traffic. Once configured, use a telnet client, such as telnet.exe included in the Windows operating system, and connect to the proxy server instead of connecting directly to the test server. When the client is connected to the proxy server, it is possible to view and modify the data normally sent to the server.

    image from book
    Figure 4-2: MITM configured to allow modification of telnet client requests

    For example, when you proxy traffic between telnet.exe and a test FreeBSD server, the client sends the terminal emulation that it would like the server to use, as shown in Figure 4-3. telnet.exe can be configured to send ansi , vt100 , vt52 , or vtnt as the terminal emulation. Using the proxy, the terminal emulation value in the network request can easily be modified to anything, including values that telnet.exe would never send.

    image from book
    Figure 4-3: Changing the terminal emulation specified in the network request from ansi to anything in MITM

    What if developers write code under the assumption that the part of the client request that specifies the terminal emulation will contain only a value that telnet.exe sends? They will be surprised when attackers modify the value to specify something else. Although it sounds like a silly mistake, it is actually a somewhat common assumption. For example, Microsoft FrontPage Server Extensions (FPSE) contained a bug similar to this that eEye Digital Security ( http://www.eeye.com ) found. FPSE normally can perform a number of operations that the FrontPage client requests. eEye testers made a request similar to a normal FrontPage client request, except they changed the operation to a bogus value. The server did not handle this well: it crashed the entire Web server process. This flaw allowed an attacker to make an anonymous Web request and take down the entire Web site! Microsoft patched this issue in Microsoft Security Bulletin MS00-100 ( http://www.microsoft.com/technet/security/bulletin/MS00-100.mspx ).

    Important  

    Programmers need to write code that properly handles bogus data sent to it. Part of a security tester s job is to send malicious data and test how the code handles that data.

    After the network data is intercepted by the proxy, modifications can be made to it blindly, butit would be better to decide intelligently which modifications to make. Many times traffic contains unfamiliar hexadecimal data. You can use the techniques described in the section titled Finding Requests the Server Normally Accepts earlier in this chapter to better understand the data. Figure 4-4 shows the decoded telnet traffic in the Ethereal network sniffer. The offset 0x39 is the value 00 50 and is used to specify that the window width should be set to 80 (00 50 is hexadecimal for decimal 80). Suboptions begin with FF FA and end with FF F0, as shown in the figure.

    image from book
    Figure 4-4: The Ethereal decoder, which shows the hex data 00 50 in the request is the client requesting a width of 80
    Important  

    Even if the client validates input, the server needs to revalidate that data. Because sending requests outside of the normal client is possible, the server should not assume that the client has previously validated the data.

    Tip  

    Even if the client making the requests doesn t allow the server to be specified (the server is hard-coded), client requests can still be proxied . By editing the file WINDIR system32 drivers etc hosts , you can define the IP address that will be used for a server s name. The IP address can point to the security proxy (likely on the local machine, so 127.0.0.1 would be the IP address). In the security proxy, the IP address of the remote destination server would be specified.



    Hunting Security Bugs
    Hunting Security Bugs
    ISBN: 073562187X
    EAN: 2147483647
    Year: 2004
    Pages: 156

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net