Spoofing is the act of making something appear as something else to the target application or end user. Users and applications decide what action to take based on information presented to them. If the information presented can fool users or applications, they might take action in a way they might not normally act. This is particularly interesting when it comes to security decisions. In this chapter, you’ll learn how to find issues that fool programs into trusting incorrect information and how attackers can present information to a user through a program’s user interface (UI) in a deceptive and misleading way (known as UI spoofing).
A common mistake that jeopardizes security is to trust something—a piece of data, an address, a dialog box—that can be controlled by an attacker. Spoofing bugs take advantage of opportunities when a program or an end user can be fooled into making a decision beneficial to the attacker based on information that has been tampered with or supplied by the attacker. In some situations, spoofing bugs can be used to bypass security mechanisms and compromise an application. Caller ID is a good example of a serious spoofing problem.
Caller ID is a feature available on phone lines in many countries that displays the phone number of the originating call. Average users of this feature believe the number displayed by Caller ID is accurate, and call recipients often base their decision of whether to answer the call on this information—for example, accepting calls from recognized phone numbers and declining to answer calls from unknown numbers.
However, Caller ID information can be spoofed. The capability of spoofing Caller ID information previously was limited to the people who controlled a public branch exchange (PBX), a method of access that wasn’t available to most people. Today, there are easier ways to spoof Caller ID information by using Voice over IP. (Services have been set up to allow users to make calls for only a few cents a minute using spoofed Caller ID information.) Although this issue seems somewhat harmless at first, there are many malicious abuses, such as using it as a social engineering aide and for voice mail compromise.
Social engineering is the ability to obtain private information by fooling the target (a person) into believing that the attacker can be trusted with that information. For example, suppose you find a new software vulnerability and contact the software vendor with the details so that it can fix the issue. You decide not to disclose the issue to anyone else until it is fixed. In this scenario, you wouldn’t give information about the vulnerability to someone who calls you on the phone and asks for details. However, what would you do if someone calls and claims to work for the vendor? If the caller works for the vendor, you should be able to trust the person with the vulnerability information. What if your Caller ID shows the call originates from the vendor? If you aren’t aware of Caller ID spoofing, you might disclose the details of the vulnerability to an attacker, who has spoofed the call and practiced social engineering on you to obtain the private information.
Important
Kevin Mitnick, one of the most famous social engineers, once was interested in how Motorola cell phones worked so that he could identify vulnerabilities. He was able to use his social engineering skills to call Motorola and convince the persons he spoke with that he was a Motorola research and development employee. As such, he was given the firmware source code. For more information about this, see http://www.pcworld.com/news/article/0,aid,121922,00.asp.
Most cellular phone service plans include voice mail. Users have voice mail passwords that are used to protect their mailbox from unauthorized people listening to their messages and changing their voice mail options. Some cellular phone providers offer a feature that enables users to access their mailbox without entering a password if users call from their cellular phone. The voice mail system must determine from where the call originates to allow the password to be bypassed. Sometimes Caller ID is used for this purpose. If a caller spoofs the Caller ID information, he or she can log on to the voice mail system as someone else without using a password. Because the voice mail system trusts the Caller ID information, there is a security vulnerability.
We were surprised this type of spoofing was so easy to accomplish. We tried it against several voice mailboxes (with owners’ permission). We attempted to call the victim’s cell phone number and spoofed that the call was originated by the same number. The victim’s cell phone doesn’t even ring. We were immediately connected to the voice mail system and logged in without a password! This attack doesn’t work against all voice mail boxes. Some providers don’t use Caller ID information and some users have configured their mailboxes to require the password for access regardless of from where the call originates.
Although the application you are testing might not use Caller ID, many of the spoofing issues are similar. To find spoofing issues that affect the product’s security, you can apply the following approach:
Identify places where the application uses data to make decisions or presents the user with data so the user can make a decision that affects security. In the Caller ID example, the call recipient used the phone number displayed by the Caller ID feature to make decisions that affected security. Threat models and data flow diagrams prove useful in this step.
Determine whether the data used to make the decision or displayed to the user can be controlled by the attacker. The information in Chapter 3, is useful in this step. The phone number in the Caller ID example was controllable by the attacker.
Become the attacker. Think maliciously about how data supplied by the attacker can be used to cause spoofing issues. Modify (spoof) the attacker-controllable data in an attempt to change the outcome of the security decision.
This approach can help you find general spoofing issues as well as a special class of spoofing bugs known as user interface spoofing (discussed later in this chapter).
Spoofing occurs when an attacker is able to forge information used by the target program, as the Caller ID example demonstrates. Following are good examples of items that are commonly spoofed:
Internet Protocol (IP) addresses
Media Access Control (MAC) addresses
Protocols
Reverse Domain Name Service (DNS) lookups
Simple Mail Transfer Protocol (SMTP) e-mail messages
Hypertext Transfer Protocol (HTTP) Referer header
HTTP User-Agent header
For many people, when spoofing is mentioned the first thing that comes to mind is IP address spoofing. The idea of IP address spoofing is commonly known, but less widely understood. A network packet is composed of two main parts: the header and the body. The header contains the source and destination IP addresses, the source and destination port numbers, and a few additional flags. The body contains the data. The difference between Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) packets greatly affects the ease with which the IP address in the packet can be forged.
TCP provides a reliable means of communicating over a network. Reliability is partly ensured by assigning sequence numbers to data packets so that both the client and server know which numbered packet in the sequence should arrive next. A TCP connection involves a three-way handshake to indicate that communication between sender and receiver can take place.
Although it is possible to spoof TCP packets, it usually isn’t simple, and it enables sending data only to one side of the connection (and not receiving the response). Application security models should not rely solely on the source IP address for decisions that affect security. For example, some systems give the user administrative privileges on the Web server if the connection comes from a certain IP address. If the target is important enough, an attacker will attempt to spoof the IP address to perform privileged operations on the server that only a trusted IP address is allowed.
Important
It is the responsibility of the operating system to mitigate TCP spoofing. Applications must be careful about features that trust data based on its source IP address. A common defense-in-depth measure is to allow incoming connections only from specified IP addresses. An example is the UNIX TCP Wrapper functionality that limits connections to certain services based on IP address. It is useful to check the source IP address as a defense-in-depth measure, but do not base a program’s security on it.
Important
To identify authenticated users Web applications often use a numeric or alphanumeric value stored in a cookie, URL parameter, or hidden form field. Similar to spoofing TCP packets by determining the sequence number, if an attacker can determine the value used by the Web application for a logged-in user, the attacker can send the value and spoof being the logged-on user to gain access to the Web application.
Unlike TCP, UDP connections do not involve a handshake and packets are not acknowledged by the recipient. Although this makes UDP an unreliable protocol, it makes it a much faster way to transmit data. It also means that the source IP address in the UDP packet can be trivially spoofed. If a program accepts UDP packets, there isn’t much preventing an attacker from sending spoofed packets to the program.
Network equipment is assigned a unique MAC address by its manufacturer. On an Ethernet network, the MAC address is used to uniquely identify hosts. To take advantage of this unique assignment, some networks allow only legitimate hosts with known MAC addresses onto the network and reject all others. This is known as MAC filtering and is common on many wireless access points.
MAC filtering doesn’t keep determined unwanted people off the network though. If an attacker controls a network device, the attacker can spoof the device’s MAC address and substitute an address that is allowed on the network. For instance, an easy way to modify a MAC address in the Microsoft Windows operating system is to use Mac MakeUp (http://www.gorlani.com/publicprj/MacMakeUp/macmakeup.asp).
Verify that applications don’t contain features that base security solely on the MAC address. Applications that use this type of security model are usually easy to find because they ask the user to enter trusted MAC addresses.
Important
Spoofing a MAC address can enable an attacker to steal someone else’s IP address on the local area network (LAN). Connections between computers on the LAN are made based on the MAC address. If an attacker knocks the victim’s computer off the network through a denial of service attack, the attacker can assume the victim’s IP by spoofing the victim’s MAC address.
Many network protocols allow an attacker to spoof information within the body of the packet. The following are some types of data commonly spoofed within the body of a packet:
Reverse DNS lookups
SMTP e-mail messages
HTTP Referer header
HTTP User-Agent header
Numeric IP addresses can be converted to human-readable domain name addresses by performing a reverse DNS lookup. For example, 192.0.34.166 could be converted to www.example.com. When the reverse lookup is requested, the DNS server responsible for the IP address is queried for the domain name address. The address returned can be any domain name specified by the DNS server. It is possible for the forward lookup (conversion of a domain name to an IP address) and the reverse lookup information not to match. For example, performing a forward lookup on www.example.com returns 192.0.34.166, but when a reverse lookup is performed on 192.0.34.166, the DNS server hosting records for 192.0.34.* could return the domain name address www.blueyonderairlines.com.
Reverse lookup information is used to make security decisions. Sometimes applications allow connections only from certain domain names (determined by the reverse DNS information). Other applications use reverse DNS lookups for logging information. When incorrect reverse lookup information is provided, problems can arise.
For example, to make log files more easily readable some programs log the information returned through a reverse lookup instead of the source IP address of the client that connects. This information appears as friendly domain names in the log file; for example, www.microsoft.com instead of 207.46.18.30 would be listed in the log file. This feature means that the connections made are not being logged properly. If you are testing a program that does this, report the bug! It is important to log the numeric IP addresses. If you find the reverse lookup information useful, log that, too.
No application should rely on reverse DNS information to be correct because attackers often can control the reverse lookup information for their domain name. The following graphic helps illustrate how an attacker could pull off a reverse DNS lookup spoofing attack:
The most common way to send e-mail is by using SMTP, which doesn’t require the sender to authenticate. Because authentication is not required, anyone can send a message to any address and claim that it was sent from any address the sender specifies. For this reason, users and programs should not trust that an e-mail truly comes from the address listed in the From field.
Tip
Digital signatures can be used to verify the sender of an e-mail message is who the message claims it is.
SMTP requires that the sender specify the recipient’s address using the RCPT TO command; the sender’s address is specified using the MAIL FROM command. An attacker can specify any address using the MAIL FROM command, allowing the attacker’s mail to appear to come from that e-mail address.
A mail message can be spoofed by connecting to an SMTP server on port 25 and issuing the following commands. To connect to port 25 on the SMTP server, type telnet <yourservername> 25 at the command prompt. Once connected, type the following commands:
Server: 220 server ESMTP Client: HELO example.com Server: 250 pleased to meet you Client: MAIL FROM: <[email protected]> Server: 250 2.1.5 <[email protected]>... Sender ok Client: RCPT TO: <[email protected]> Server: 250 2.1.5 <[email protected]>... Recipient ok Client: DATA Server: 354 Enter mail, end with "." on a line by itself. Client: This is a spoofed e-mail! Client:. Server: 250 2.0.0 jAQ6rr0i794836 Message accepted for delivery
Important
Because SMTP messages are not authenticated, there is widespread abuse of the system with spoofing. Many spammers employ spoofing techniques when they send bulk e-mail messages. To help mitigate this problem, most SMTP servers stamp the IP address of the machine originating the e-mail in the e-mail headers.
As mentioned in Chapter 4, any data included as part of an HTTP request can be forged. An optional part of the request is the Referer header. (Recall that Referer is misspelled in this text to match the misspelling in the HTTP specification.) This header’s value contains the URL of the page that requested the URL.
Important
Spoofing data contained within an HTTP request can be accomplished by using the techniques discussed in Chapter 4.
Sometimes developers rely on the Referer’s value as a way to prevent other Web sites from linking to images on their site or to keep third-party servers from hosting HTML forms that submit to scripts on their servers. If the Referer’s value isn’t a URL for the current Web site, the request originated from another site and the Web request is rejected. One popular script that used this logic was Matt Wright’s FormMail script (http://www.scriptarchive.com/readme/formmail.html).
FormMail is a freely available Perl script that is used to add e-mail Web form functionality to a Web site. When the Web form is filled out and submitted, its contents are sent to the e-mail address contained in a hidden form field. To prevent other sites from hosting forms that submit to it, the Referer header is verified against a list of allowed referrers.
Spammers figured this out and exploited the vulnerability by sending custom form submissions with a spoofed HTTP Referer, a spam message as the contents of the form, and the target of the spam as the hidden field e-mail address. This attack was possible because all three fields were part of the packet’s body and under full control of the attacker.
Another part of the HTTP request that can be spoofed is the User-Agent header. This header is used to tell the Web site which browser is requesting the page. An attacker can modify the User-Agent header sent by the client to cause the server to consider the attacker’s browser to be something other than it is. Why is this important? Sometimes Web sites respond differently depending on what type of user agent makes a request. For example, some Web sites require visitors to be members to view the full contents of the site. However, these Web sites still want search engines to index the site content without having a member account. To allow this, these Web sites have a back door of sorts. If a search engine is indexing the site, the Web site allows membership checks to be bypassed. Because search engines have a custom user agent string, sometimes the determination of whether to bypass the membership check is based on the User-Agent header value. If this is the case, attackers can gain access to the site without a membership if they spoof the User-Agent header and provide a string used by a popular search engine.
The issues discussed in this chapter to this point are those in which an attacker causes problems to a program’s logic. UI spoofing, on the other hand, is a special class of spoofing that enables an attacker to present information in the legitimate program’s UI in a way that the information would not normally be presented so as to mislead the user. Although attackers prefer attacks that avoid user (victim) interaction, this is not always possible. Sometimes an attack requires the victim to perform certain actions. It can seem very difficult to coerce a victim into performing these actions. UI spoofing provides a great method for manipulating users into performing actions necessary for an attack to be successful. Following are some common ways to perform UI spoofing:
Reformatting or rewording dialog boxes
Modifying the Z-order
Providing misleading URLs and filenames
Commonly, security dialog boxes ask the user whether or not an action should be taken. Sometimes the dialog box includes information that is controlled by an attacker. For example, you might receive a document or e-mail message (potentially from an untrusted source) that contains links. When you click links that could be specified by the attacker, many programs will display a dialog box asking you to verify whether you want to visit the link. Often the link URL is included in the dialog box. In scenarios like this, it is sometimes possibly for the attacker to reword or reformat the dialog box.
The dialog box in Figure 6-1 asks whether the link http://www.microsoft.com/ should be opened. This figure was generated by a sample program named LinkDialogSpoof.exe that is included on this book’s companion Web site. You can use this program to practice UI spoofing as demonstrated in this chapter.
Locate the sample program LinkDialogSpoof.exe on the companion Web site. Make sure that the supporting file named LinkDialogSpoof.txt is in the same directory as LinkDialogSpoof .exe. Open LinkDialogSpoof.txt in a text editor such as Notepad. You should see the following text contained in the file:
Link=http://www.microsoft.com/
For this example, assume that the attacker controls the contents of LinkDialogSpoof.txt and the dialog box is presented to confirm that links aren’t opened without the user’s explicit consent. A user should choose to open only links that look safe.
Suppose an attacker wants to trick the victim into loading http://www.example.com. How can an attacker trick the user using the data displayed in this dialog box? Notice the URL is enclosed in single quotation marks. What if an attacker includes a single quotation mark as part of the URL? The dialog box would start getting a little confusing as shown in Figure 6-2.
The attacker can close off the URL and add a sentence to reassure the user it is a good idea to open the link. For example, the attacker can supply http://www.example.com/’ This link has been verified and is safe and digitally signed by ‘Microsoft as the input. The result would be a somewhat convincing dialog box, as shown in Figure 6-3.
Important
When examining security dialog boxes, verify the default selection is the most secure choice. Users often assume the default is secure and accept the default choice without much thought. The example dialog box in Figure 6-1 has an insecure default.
This could work, but the URL http://www.example.com is on the same line as the added text. Also, the attacker’s data (the link) is indented in the dialog box, which separates the program’s text and the attacker’s data. This might not convince as many people as the attacker would like because it looks somewhat suspicious. An attacker can work around this problem by actually reformatting the dialog box.
Most dialog boxes in the Windows operating system allow programmers to format the text that is displayed. In Figure 6-1, the dialog box contains three separate lines of text and the second line is indented. An attacker can take advantage of this by including formatting characters to change the layout of the dialog box. For example, if the attacker includes a carriage return/line feed (CR/LF) in data, the input could be http://www.example.com/‘<CR/LF> This link has been verified and is safe and digitally signed by ‘Microsoft’. The resulting dialog box is shown in Figure 6-4. This is much more convincing.
Tip
When entering control characters such as CR/LFs, nulls, and tabs, it is helpful to use a binary editor instead of a text editor. This preserves any binary characters in the remainder of the input while allowing easy insertion of the control characters you want to test.
The attacker can format the URL so that it is virtually invisible. For example, if the attacker uses this data:
http://www.microsoft.com’<CR/LF><CR/LF>Press Enter to open this link. <50 or more CR/LFs>@example.com
The text now contains more lines than can fit on the screen. The last several lines aren’t visible, including the line that contains the server name. The dialog box for this input is shown in Figure 6-5.
This type of input takes advantage of the username@ syntax, which is discussed in the section titled “Username@URL Syntax Attacks” later in this chapter, and wildcard DNS.
Figure 6-5. Adding so many CR/LFs that some of the text and Yes/No buttons scroll off the bottom of the screen and aren’t viewable. This link actually loads http://www.example.com not http://www.microsoft.com.
Entries in log files can sometimes be spoofed by using the same techniques used to reformat dialog boxes. Suppose a Web server log file has the file format shown in Figure 6-6.
To attempt to spoof a log entry you might try inserting a CR/LF so that the log entry wraps to the next line. For example, the HTTP request http://server//addUser?ID= 100%09192.0.2.144%0D%0A2006-02-17%0902:10:36%09GET%09/smiley.jpg might result in the log file entries shown in Figure 6-7. Note that %0D%0A is a CR/LF character and %09 is a tab character. The highlighted text shows the attacker-supplied data (from the URL).
Wildcard DNS allows mapping all possible host names for a domain to an IP address without explicitly specifying each host name on the DNS server. For example, www.alpineskihouse.com and something.alpineskihouse.com would map to the same IP address if wildcard DNS is set up for alpineskihouse.com. The wildcard host names can contain null characters and other control characters that are not usually allowed in host names. An attacker can take advantage of this capability to use control characters in a host name. Table 6-1 lists control characters that can be used in UI spoofing.
Table 6-1. Useful Characters for UI Spoofing
Character | Hexadecimal representation | Description |
|---|---|---|
Carriage return/line feed (CR/LF) | 0D0A | Used to force text onto the next line. The line following the CR/LF can surreptitiously contain attacker-supplied data. The user viewing the dialog box might not realize that the text on the line after the CR/LF is part of the attacker’s input. |
Carriage return | 0D | If the application filters out carriage return/line feed characters, sometimes a carriage return character can be used alone to achieve the same result. |
Line feed | 0A | If the application filters out carriage return/line feed characters, sometimes a line feed character can be used alone to achieve the same result. |
Tab | 09 | Can be used to force text to the next line. The tab character is useful if CR/LF, CR, and LF are blocked. |
Space | 20 | Accepted almost everywhere. Many spaces together can be used to wrap text to the next line. |
Backspace | 08 | Sometimes can be used to erase characters in the UI or in files to help hide or change information. Particularly useful when the data is sent to a console window. |
NULL | 00 | Often used to truncate strings. This character can be used to hide the remainder of a string. |
Tip
Rewording and reformatting spoofing attacks can be mitigated significantly if the UI makes a clear distinction between the program’s text and text provided by a potential attacker. Common ways to achieve this include using a different color or font for attacker data and ensuring attacker data cannot wrap to another line, truncate important parts, or scroll off the side of the screen.
Sometimes it is not possible to reformat a dialog box. However, sometimes attackers can control windows that might cover parts of a dialog box and in that way trick a user into making a bad decision that jeopardizes security. For example, in HTML, it is possible to create pop-up windows. Also, Microsoft Internet Explorer has a pop-up object that gives the caller great control, including specifying the order of layers of windows on the screen (known as the Z-order).
In 2001, Georgi Guninski found that it was possible to use pop-up windows programmatically to appear on top of the browser’s normal UI, including any security dialog boxes that are displayed. The original advisory is available on his Web site at http://www.guninski.com/popspoof.html. Andrew Clover created a very convincing demo of this problem, which is available at http://www.doxdesk.com/personal/posts/bugtraq/20030713-ie/activex.html.
For example, the dialog box shown in Figure 6-8 is displayed. The pop-up text makes the user believe there is only the option to click Yes. In reality, clicking Yes is a bad security decision. Figure 6-9 shows the pop-up separated from the original dialog box to reveal that the legitimate dialog box is actually warning the user that untrusted code might be run.
If your application allows untrusted users to display pop-up windows programmatically, verify that the windows cannot be placed on top of areas outside of your application, dialog boxes inside your application, and areas in which user data isn’t normally displayed. Also, test to see whether the window contains a hard-coded border that identifies the window as coming from a certain source (application, URL, etc.). Such identifying information can help a victim realize that the pop-up is not part of the legitimate program and might be controlled by an untrusted party. A big part of the problem with the Internet Explorer example (Figure 6-8) is that there is no border around the pop-up window, which makes it difficult for the victim to realize a pop-up window is present.
Important
Phishing is a type of attack in which an attacker contacts a victim, pretends to be a trustworthy entity, such as a representative from the victim’s bank, and asks the victim to disclose private information (user names and passwords, credit card information, etc.). Spoofing bugs like the ones discussed in this chapter are often used to make a phishing attack more convincing. If an application contains a spoofing bug, an attacker can exploit it to increase the chance of success in a phishing expedition.
Another form of UI spoofing is when attackers modify data so that it appears as something other than it actually is, and then present this to users. Modified URLs and filenames are especially useful for causing confusion. Some ways to spoof URLs and filenames include homograph attacks, URL redirection, and username@URL syntax attacks.
Which Web site would you expect to see if you clicked the link http://www.microsoft.com? You would probably expect to see the official Microsoft Web site, but you wouldn’t. Evgeniy Gabrilovich and Alex Gontmakher registered the domain mi?ros?ft.com using Russian Cyrillic characters for the c and o. Although the characters look similar to the Latin c and o, they aren’t the same, and the URL that uses the Cyrillic characters takes you to a completely different place than you would expect.
More Info
For more information about homograph attacks, see Gabrilovich and Gontmakher’s paper titled “The Homograph Attack” at http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf.
It is very difficult to distinguish a legitimate site’s URL from a homographed look-alike. Some programs, such as FireFox, display the Punycode equivalent of URLs that include Unicode characters like Russian Cyrillic characters. The Punycode version of the microsoft.com look-alike site is http://www.xn--mirsft-yqfbx.com.
Tip
Punycode is defined in RFC 3492 as “a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens).”
When testing, it is useful to see how the target application behaves when homographed URLs are used. Often, it is helpful for applications to draw attention to URLs that potentially might be homographed for users by displaying them in Punycode.
Tip
Sometimes programmers call the SHGetFileInfo function (part of shell32.dll) to determine how a filename should be displayed to the user. If the SHGFI_DISPLAYNAME flag is used and the Hide Extensions For Known File Types folder option is enabled, the application programming interface (API) recommends files such as test.txt.bat should be displayed simply as test.txt. The Hide Extensions For Known File Types folder option is enabled by default. As a result, programmers might believe the full filename will be returned if they have changed this setting on their machine. To find issues like this, you can look at the source code for references to SHGetFileInfo, or you can test with the Hide Extensions For Known File Types option enabled and use filenames such as test.txt.bat to see whether just test.txt is displayed.
Which Web page would you expect to see when you type http://www.fourthcoffee.com into your browser? You probably expect to see a coffee-related Web site. However, you notice that http://www.microsoft.com is now displayed in the browser address bar. How did that happen? This is called URL redirection. When you request the first URL, the server responds with HTTP response code 302, which tells the browser to load a different URL, http://www.microsoft.com in this case.
A user might not want to allow a URL to be loaded from a certain domain, but might unknowingly load the URL if HTTP redirection is performed. A victim is more likely to trust a recognizable or well-known URL. Often pages on reputable Web sites accept a URL through the query string and redirect to it. For example, http://www.msn.com/redir.asp?URL=http://www.example.com.
Important
Pages on reputable sites that allow arbitrary redirection are often used in phishing attacks. If the Web application you are testing allows an attacker to specify an arbitrary URL value and force HTTP redirection on that value, talk with the programmer about removing or limiting this functionality. To help mitigate this issue Web programmers can limit the URLs that are allowed for HTTP redirection.
If the user reads the beginning of that long URL, he or she might expect to be delivered to the MSN site, but instead the user’s browser is redirected to the example.com site. An attacker can cause even more confusion by obfuscating the redirection URL by using other tricks discussed in this chapter and in Chapter 12.
Important
HTTP redirection is also important in testing for cross-domain and zone issues, discussed in Chapter 10. Many APIs that retrieve URLs silently follow redirects without alerting the caller. For this reason, a program might believe it is receiving data from one domain when actually it receives it from another.
Many programs ask the user whether the user wants to load a Web page from a certain URL. Often, the program will prompt the user only for the original URL and will not prompt if a redirect is performed.
To create a test Active Server Pages (ASP) page that performs an HTTP redirection, use the following code:
<% Server.Redirect "http://www.example.com" %>
Important
HTTP redirection is different from HTML meta tag refresh and HTML script redirection (using client-side script to change the browser’s URL). HTTP redirection is done at the protocol level and is supported by system APIs. For this reason, applications often get HTTP redirection behavior without including additional code (and sometimes without knowing it). HTML meta tag refresh and HTML script redirection are contained in the contents of the HTML, not at the protocol level. These types of redirection are performed after the contents of the HTML are parsed by the application, and they require the application to support refresh and script redirection.
Important
Similar to trusted Web sites allowing redirection to arbitrary URLs through attacker-supplied data, some Web sites accept attacker-supplied data and use it as the source URL of an HTML frame. When this occurs, it is hard for the user (victim) to realize that an attacker controls one of the frames.
RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt) specifies that URLs can include a user name using the following syntax:
<userinfo>@<host>:<port>
This syntax enables an attacker to insert arbitrary text before the server name (host) in the URL. For example: http://[email protected] would connect to www.example.com and uses www.microsoft.com as the user name. However, because www.example.com doesn’t require a password, the user name part of this URL won’t be used. Further obfuscation can be applied to the real server name to cause even more confusion. For example, if the IP address of example.com is used, the URL could look like http://www.microsoft.com @192.0.34.166 or http://www.microsoft.com@3221234342 (which uses a dotless IP address as discussed in Chapter 12). Both of these URLs look as if they would load the Microsoft Web site, but instead they load example.com.
Many attackers use this syntax to confuse their victims. For this reason, in security update MS04-04 Internet Explorer turned off this syntax by default for http and https. If you are testing an application that supports URLs, consider disabling support of this syntax to prevent the associated attacks.
Determine all of the places in which attacker-controlled data is presented to the user or can be used to make a decision that affects security, such as in parts of the user interface or in log files.
Use the techniques discussed in Chapter 4 and Chapter 5, to send spoofed data over the network.
Understand the protocols used in your application. Many protocols contain contents that are trivial to spoof (for example, SMTP e-mail sender, HTTP Referer header, HTTP User-Agent header). These attacks are not limited to text-based protocols; they are also present in binary protocols.
Use a binary editor to modify files that could be controlled by attackers. For example, if you wanted to modify a Microsoft Office Word document, you can make the modifications in a binary editor to preserve the existing binary characters in the file and add control characters if necessary.
Try all ASCII characters (hex 0x00 through 0xFF) in attacker-controlled input. Applications might filter some characters or behave strangely when certain characters are used. Strange behavior includes not printing characters or printing incorrect characters. The total number of ASCII characters is only 256, so testing each character is realistic. The full ASCII table is available on http://www.asciitable.com.
Use Unicode characters in applications that support Unicode (for example, homograph attacks).
Test to see whether an attacker could potentially reword or reformat the user interface by including CR/LFs, nulls, tabs, and other control characters.
Try to mislead the user with your test input in places an attacker can control the input. Misleading input is the kind that by providing misleading statements or misleading URLs or filenames instructs the user to somehow compromise security.
Verify that the default selection in security dialog boxes is the most secure option.
Verify that the text in dialog boxes clearly explains the impact or danger of the user making an insecure choice.
Spoofing issues can occur in places where a program makes a decision based on attacker-controlled data or when attacker-controlled data is presented to the user, as in user interface spoofing. General spoofing enables an attacker to gain more access than would normally be granted. User interface spoofing enables an attacker to trick a victim into performing an insecure action or helps an attacker hide an attack.