Understanding the AT&T security breach: Parameter tampering basics
The recent AT&T security breach that disclosed 114,000 Apple iPad e-mail addresses is lingering on the Web like a bad smell in an enclosed car. Some details on how it was done are provided on gawker.com under the “Breach Details: Who did it, and how” section. This post will explain the user-agent header and HTTP request elements, and provide an example of parameter tampering that makes a breach like AT&T’s possible.
DISCLAIMER: What I present below has nothing to do with the AT&T site itself.
User-Agent Header – How to fool a Web server into thinking it’s being accessed by an iPad
The user-agent header is used by the HTTP protocol to let a Web server know what type of browser and system is being used to access the Web server. All browsers do this. When someone writes a program or script to emulate a browser, all he has to do is fill in the user-agent header information with whatever he wants. I’ve personally done this many times to write Web spiders, download managers and email harvesters. On the Web server side, user-agent header information is used to format Web pages and enable certain capabilities based on the browser type.
HTTP Requests are also part of the HTTP protocol and contains the methods used by the browser and server to exchange commands, information and files with each other. As with the user-agent header, a programmer can emulate HTTP requests just like a browser.
Let me start off by saying that parameter tampering is a well-known issue. My first exposure to parameter tampering was back in 1997 (yes, 13 years ago), when I started writing Web applications. It’s such a basic attack, it’s ridiculous. Here’s how it works:
Anytime someone uses a Web application, the browser and server use variables to pass specific information to and from each other. When someone fills out a user registration form, for example, a Web application will use variables with names like “UserName”, “Password”, “EmailAddress”, etc. When a user clicks the “Submit” button, the variable names and their corresponding values are sent to the server for processing.
Let’s say a customer logs into a Web application to look up a sales invoice, number 12345. After the person logs in, the server displays a list of invoices for that customer in the browser. To view a specific invoice, the customer clicks on the link for that invoice, which contains a variable “InvoiceNumber” followed by the value 12345:
The browser sends the URL to the Web server and the Web server returns the sales invoice information. In a insecure Web application, a customer will be able to modify the URL, replace the invoice number with ANY value, press enter, and be able to view the invoice if the invoice number exists in the database, even if the invoice belongs to another customer. A secure Web application will check to make sure the customer ID on the invoice matches the customer’s log in credentials and prevent the customer from viewing another customer’s invoices — or only retrieve invoices from the database that match the customer ID associated with the customer’s log in credentials.
This is just one example of parameter tampering. It may be possible to tamper with other parameters or a URL based on the Web application, to include cookies, form variable names, folder paths and Web page names. Once someone figures out that parameter tampering is possible, it’s just a matter of writing the code to access, add, modify or delete information.