In the ActiveX example in Chapter 18, an attacker calls into the ActiveX control by coercing the target to load an HTML document that contains data specified by the attacker. The attacker uses the Active X control for a purpose other than the control’s developer intended. This same concept applies to other technologies. The repurposing attacks apply to many technologies some are discussed in this chapter. In this chapter, we discuss how document formats and Web applications can be repurposed to perform malicious actions. You’ll also learn the basic concept behind a related issue with the Microsoft Windows messaging system.
A useful feature in some document formats is the ability to request data from another source. You might recall that document formats accessing external data must be protected against Web beacons, as discussed in Chapter 7, but sometimes more dangerous bugs threaten when accessing external data.
Sometimes a data request can allow an elevation of privilege. Suppose an SQL statement, which an attacker might not have access to make, is the request for external data. If an attacker can find a document format that supports making SQL requests and can coerce a target (who has access to make SQL requests) to open the document, the attacker’s SQL statement will be successfully executed by the target, and the attacker’s privileges would be elevated. The fact that any SQL query is run when the document is opened means an attacker can make any modifications to the database that the target can make.
Spreadsheets are a common example of a document format that often supports requesting external data. Spreadsheets are used to query the external data and create reports on that data. Not all spreadsheets request external data, however, and it is difficult to know when one is requesting such data. A user usually must open the spreadsheet to determine whether the spreadsheet requests external data, and sometimes even then it is difficult to tell. In some instances, simply requesting external data is dangerous. In addition to SQL statements, some other examples of dangerous external data requests include Lightweight Directory Access Protocol (LDAP), Simple Object Access Protocol (SOAP) requests (discussed later in this chapter), and Dynamic Data Exchange (DDE).
Sometimes file formats that request external data store this data at a location specified in the file. This enables additional attacks. Some external data requests might not seem harmful—for example, a request to retrieve a URL or file. However, if the attacker has the ability to specify a location to store the response, danger is almost certainly ahead. For example, Microsoft Office Word and Excel contain features that allow users to insert the contents of one document into another file. This functionality can be specified by the document creator. The file containing the contents of the other file is updated with current contents of the containing file when the user opens the file. If an attacker is able to insert data into the file in this example, the data is stored in the original document and then must be sent back to the attacker. In other scenarios, an attacker might store the data in a location on the Internet from which it is easier to retrieve the data without coercing a victim into manually sending the document to the attacker. The problem in Word and Excel was mitigated in October 2002 when Microsoft released update MS02-059 (http://www.microsoft.com/technet/security/bulletin/MS02-059.mspx).
Important
The repurposing attacks discussed in this chapter for document formats and Web pages that request external data leverage the target person as a human proxy who is unaware that the attacker’s requests are being made under the target’s account.
The ability to request external data is often very useful. Removing this functionality could hinder productivity, so this isn’t always the best solution for customers. Many programs, such as the Office applications, mitigate the danger of requesting external data by requiring user interaction before making the request (no automatic external requests are allowed) and notifying the user before a request is made. For example, Excel displays the dialog box shown in Figure 19-1 when a refresh of the data requires requesting external data.
The ability to request and/or store external data in ways that can be abused as described is usually documented as a feature. Remember that there are two issues when requesting external data—requests that are harmful by themselves and the ability to store responses. As a tester, you need to look for bugs in both areas.
The ability to request external data is often a feature. Having knowledge of the security concerns along with a good understanding of the product’s features can help you find these bugs. If possible, talk with a developer to gain a better understanding of the product and to determine whether a feature that requests external data exists. If the product has already been written and documentation is available, try looking for clues such as the use of external data, data links, SOAP, SQL, and LDAP. Verify that the user requesting the external data (the user opening the document) is aware of any potentially harmful external data requests and storage of the responses.
Tip
Features that allow data to bind to a control or field in a document often allow accessing of external data. Be on the lookout for features like this so that you can verify whether they can be repurposed to request and/or store external data.
Another effective way to find features that request external data is to exercise the application’s functionality while using monitoring tools like FileMon (for local files) and Ethereal (for network traffic). More information about these tools is available in Chapter 3 and Chapter 4. The downside to this approach is that these tools will only help you determine if the application you are testing made an external request for the exact scenario you tested in the application. If the application was used differently to include additional features or if it used the previously tested functionality in a different manner, external requests might be made. For this reason, it is often useful to gather information about the product’s functionality in combination with exercising its functionality while using monitoring tools like FileMon and Ethereal.
Important
We talked with one product team about the threat of harmful requests for external data. They wanted to support automatic data updates through SQL statements and thought that they would examine the SQL statement to verify that it didn’t modify data. If the statement only requested data, they thought, this would be a harmless action because their application would not allow the results of the request to be stored. After meeting with the SQL team, it became obvious that determining whether a SQL statement would modify data is not an easy task. Enter a bug if your application is attempting to filter the contents of requests that are known to be harmful. The approach to filter bad content as opposed to allowing only good content will almost always miss cases and result in security bugs.
Web pages are designed to access external data. Most Web pages on the Internet request external data. For example, pages that contain graphics make external data requests to display them. The security model of Web browsers should not allow a Web page on one domain to read content on another domain (this is discussed in Chapter 10). However, the browser’s security model does not prevent it from making requests to other domains for most types of data. (The Web browser security model allows one domain to force the browser request data from another domain but does not allow different domains to read the response of such requests.)
As discussed in the previous document format example, if an attacker can coerce a target into making certain requests, the requests themselves can be harmful. Unlike document formats discussed earlier in which the application mitigates the risk by not allowing harmful requests, in the Web page case the server receiving the request must protect against the repurposing attack. An attack that allows an adversary to get a victim to perform specific actions against a Web application by forcing the victim’s machine to make Web requests specified by the attacker is known as a cross-site request forgery (CSRF) attack. This type of attack is commonly referred to by Microsoft as a one-click attack, with a variation called a zero-click attack. Microsoft used these terms internally before the term CSRF was used externally. For this reason, you might see these terms used instead of CSRF in some documentation produced by Microsoft. Because CSRF better describes the attack, we use this term in this text.
Important
Many Web applications are vulnerable to CSRF attacks. This type of vulnerability is often mistakenly overlooked when doing security testing, making this a fruitful area to test.
In Chapter 4, you learned how some Web applications take input through the query string (a GET request). Imagine a Web mail application that has a button to delete the current e-mail message. When the button is clicked, the browser is redirected to http://server/delete.cgi?msgId=1. When this URL is requested, the Web application verifies the request comes from an authorized user and, if successful, deletes the first message from the user’s inbox (signified by the msgId parameter). If an attacker coerces a victim to load this URL, the first message from the victim’s inbox will be deleted. Although an attacker could create a Web page or send an e-mail message that contains a link and hope the victim clicks it, the attacker could also use the following HTML normally used to display an image instead:
<IMG SRC="http://server/delete.cgi?msgId=1">
Without the use of script, this HTML will automatically load the SRC URL to retrieve a picture. Because delete.cgi doesn’t return a picture, one will not be displayed, but the first e-mail message on the server will be deleted unknowingly by the target.
Important
The same techniques used to coerce a target into sending an attacker’s data in cross-site scripting attacks are used for CSRF attacks.
Whereas query string data is commonly used to modify settings and data, the HTTP specification states that only data retrieval should be done with GET requests. The first step in circumventing this problem is to prevent the server from accepting GET requests but instead allow it to accept only POST requests for anything except data retrieval. However, this alone does not solve the problem.
Note
How does an attacker get a victim to authenticate against the vulnerable Web site? In a CSRF attack, the attacker wants the Web application to perceive the forged request as coming from the victim. The victim must be logged on to the Web application for this to occur. Some Web applications use cookies or Windows Integrated authentication to log on users automatically. Automatic logon makes CSRF attacks easier. If automatic logon isn’t possible, attackers might be able to attack targets after the targets have already logged on, or attackers might even use social engineering techniques to trick the target into logging on.
The same general problem that allows CSRF attacks to occur with query string data exists with POST data. The only difference is that the data cannot be contained only in the URL. Chapter 10 discusses a way an attacker could exploit cross-site scripting (XSS) flaws in applications that accept POST data that involves an attacker creating a form prepopulated with the data the attacker wants the target to POST and where the attacker wants it POSTed. This same technique applies to CSRF attacks in which the Web application accepts POST data.
For example, the following HTML is used to create a new user account on a Web site and contains three input fields: user name for the new account, password, and confirmation of the new password.
<form name="createForm" id="myForm" method=POST action="http://server/createUser.cgi">
<table border="0" width="39%">
<tr>
<td width="123">Username:</td>
<td><input type="text" name="username"></td>
</tr>
<tr>
<td width="123">Password:</td>
<td><input type="password" name="passwd1"></td>
</tr>
<tr>
<td width="123">Confirm Password:</td>
<td><input type="password" name="passwd2"></td>
</tr>
<tr>
<td width="123"> </td>
<td><INPUT type="submit" value="Create Account"></td>
</tr>
</table>
</form>This HTML form submits to createUser.cgi, which processes the form and creates the new user account. An attacker could host a copy of this form prepopulated with a user name, password, and confirm password of the attacker’s choice. The attacker-hosted copy could also include JavaScript to automatically submit the form. If a user who has access to create accounts through createUser.cgi views the attacker’s copy of the form, the new account will be created.
A common way to prevent CSRF attacks is to add to each form a validation form field that contains data that should not be determinable by the attacker and that is unique for the user requesting the form. When the form is submitted, the validation form field is checked to be valid for the current user. If the validation field is correct for the user submitting the form, the request is accepted. Otherwise, the request is considered to be a CSRF attempt and is immediately rejected.
The following HTML is an example of a validation form field included as part of an HTML form with CSRF protection:
<input type="hidden" name="__REQUESTDIGEST" value="0x499F221FF714785447B7213E765D4914,12 Apr 2006 05:47:14 -0000" />
Important
One cross-site scripting or script injection bug anywhere on the Web site enables an attacker to bypass the CSRF prevention validation form field. This is because the attacker can use the XSS bug to automatically navigate the client browser through the series of steps necessary or can obtain the value of the validation field of the targeted user.
When brainstorming ways to prevent CSRF attacks, people often suggest keeping state on the server to verify the form was loaded immediately before the POST request is received. Another common suggestion is issuing a cookie when visiting the form and verifying the cookie before processing an HTTP POST. These do not prevent the problem! Can you think how an attacker might bypass these techniques without another bug in the site? With JavaScript, an attacker can get the victim’s browser to load any URL. An attacker can force the Web browser of the target to visit the HTML form and then load the attacker’s form, which does an HTTP POST to the vulnerable Web application. This defeats both the suggested server-maintained state and the cookie mitigations. This approach to defeating server maintained state and cookie mitigations does not foil the hidden form field mitigation previously described. For this reason, the hidden form field is the recommended mitigation.
Tip
ASP.NET 1.1 and later can manage the validation field for Web applications by using the Page.ViewStateUserKey property. This property stores the undeterminable user-unique validation data in the __VIEWSTATE form field. For more information, see http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemwebuipageclassviewstateuserkeytopic.asp.
As discussed in Chapter 11, SOAP allows a client to call into functions on the server. Similar to HTML forms that use POST, SOAP uses HTTP POST to send its XML requests to the server. Unlike typical HTML forms sending POST requests, a form isn’t displayed prior to making a SOAP request, so the validation form field mitigation wouldn’t work as easily in this situation. Instead of adding mitigation to the Web application, the mitigation is in the client making the SOAP request. This is similar to what happens in the document format case first discussed at the beginning of this chapter.
In Microsoft Internet Explorer, a Web page that attempts to make a SOAP request to a different server causes the XMLHTTP object to display a security dialog box that asks the user whether to allow the cross-domain SOAP request. This dialog box is shown in Figure 19-2.
Figure 19-2. A warning dialog box that appears when a page on one domain attempts to call a SOAP method in another domain
As long as every client blocks or warns in places where a target can be coerced to make a SOAP request to an arbitrary server, CSRF isn’t possible through SOAP, right? Maybe. It turns out that SOAP messages also can be sent using HTML forms using either GET or POST. SOAP through GET and POST isn’t always supported by the server. If these types of requests are supported and the SOAP method can do harmful actions or receive sensitive data, they are great targets for a CSRF attack.
The following URL uses GET to request a call to the SOAP method called bid with the id parameter set to 5089 and the amount parameter of 1000:
http://server/auction.asmx/bid?id=5089&amount=1000
Alternatively, if the server accepts SOAP requests through form POST requests, the following HTML form could call the bid SOAP method:
<FORM name="myForm" action="http://server/auction.asmx/bid" method="POST"> <INPUT type="hidden" name="id" value="5089"> <INPUT type="hidden" name="amount" value="1000"> <INPUT type="submit"> </FORM>
In ASP.NET, SOAP GET and POST requests can be configured on the server. To ensure HttpGet and HttpPost are not enabled check the machine.config and web.config files. For more information about this configuration, see http://msdn.microsoft.com/library/en-us/cpguide/html/cpconConfigurationOptionsForASPNETWebServices.asp.
The following tips can be used to help you find identify CSRF bugs:
Use the techniques discussed in Chapter 4 and Chapter 11 to identify GET, POST, and SOAP requests the server accepts.
Verify that no GET requests can modify settings and data.
Verify that all POST requests that can modify settings and data contain a validation field that cannot be determined by another user.
To verify that the validation form field used to prevent CSRF attacks cannot be used by a different user than the one who requested the form, try loading an HTML form as one user and submitting it as a different user. If the requested action succeeds, you’ve found a bug.
When testing SOAP Web services, ensure HTTP GET and POST are disabled for requests that could modify or retrieve settings and data.
When testing an application that allows an attacker to specify that the victim make a SOAP request, make sure the application doesn’t support or warns when SOAP requests are made to arbitrary domains.
Applications running on the Windows operating system use messages to control how the applications behave. Every time a user clicks a button, moves the mouse, presses a key on the keyboard, and so forth, a message is sent to the application. The application chooses which messages it listens to and handles only those specific events. These messages can be repurposed to cause a security problem in an method known as shatter attacks.
The problem with messages is that any application can send a message to another application, and the recipient application has no way of determining who sent the message. Nothing prevents a lower privileged application from sending a message to an application that is running with higher privileges. As a result, if a high privilege application accepts messages, it might allow a lower privileged account to perform unexpected actions in the high privilege security context, including running arbitrary code.
To send messages in the Windows operating system, an attacker needs to run code on the box. However, this code can run as a lower privileged account and attack an account with higher privileges. For example, an attacker might be able to escalate privileges from Guest to System (an account that allows accessing everything on the computer).
Although this problem has existed since the early days of the Windows APIs, Chris Paget realized the security implications and released a paper (http://security.tombom.co.uk/shatter.html) that explains in depth the background of the vulnerability and why it is a problem.
Winspector (http://www.windows-spy.com/) enables you to enumerate all processes, windows, and window messages on a machine at run time. It is a lot like Spy++, which is a tool available with Microsoft Visual C++, but has some extra features that will help identify which windows a process creates. By using Task Manager or Process Explorer to determine which user started a process and then Winspector to determine whether any windows were created by a high privileged user, you might be able to wreak some havoc, such as a shatter attack. The user account that creates specific windows is not always the same account that starts the process. Some applications use impersonation to create windows as an account with less or greater privileges as the account that started the process. The next step is to write code to send messages to the message pump running with higher privileges in an attempt to elevate privileges. Use PostThreadMessage, PostMessage, or SendMessage to construct the messages. Three particularly common ways to craft malicious messages are buffer and integer overruns, callback function pointers, and class or interface pointers passed in the parameters of the windows messages. Another generic way is to manipulate the UI, which governs settings.
If you have access to the source code of the target application or have permission to disassemble it, find where each custom message is handled, and assess how the parameters are used and what can happen if the attacker can specify arbitrary parameters. To attack/test the custom message handlers, you will need to call RegisterWindowMessage as well. In addition to targeted testing, fuzz testing might also be worthwhile.
In addition to ActiveX, many technologies are prone to repurposing attacks. Some requests for external data (such as SQL statements and SOAP requests) can be harmful if an attacker can coerce a victim into making requests the attacker specifies. In some cases, the request for external data isn’t harmful, but the ability to store that data through repurposing can allow an attacker access to privileged information. Because messages in the Windows operating system can be sent to any application, these messages can also be repurposed. Sometimes a repurposing attack is prevented or mitigated in the client; other times it is prevented on the server receiving the potentially repurposed data. Sometimes an attack isn’t prevented at all. Using the tips in this chapter, you can help identify these issues and ensure they are correctly fixed.