iPad hack vs. OWASP Top 10

Which of the "OWASP Top 10" was responsible for the iPad AT&T hack? The answer is: "none of them". It's an "information leakage" problem, something I would include in my top 10 list, but which is missing from OWASP's list.

OWASP is an organization that helps secure websites by teaching developers to avoid common web app vulnerabilities like "SQL injection" and "cross site scripting". They have a pretty good list of what they consider the "Top 10" vulnerabilities.

But the AT&T iPad registration vulnerability, "information leakage", isn't on their list. In my experience, it should be. In our pentests into websites, "information leakage" is one of the most common problem we find. In their book "The Web Application Hacker's Handbook", authors Stuttard and Pinto also include "information leakage" as one of their top 5 web application vulnerabilities.



There are also other important factors that, while not worthy of the top 10, are still interesting.

HOW THE HACK WORKED

The way the AT&T hack worked is by exploiting a feature in the registration process. AT&T uses your e-mail address as your account name. In order to logon, you must supply this, along with your password.

Like many websites (Twitter, Facebook, etc.), when you log in again, the server populates the form with your account name, so that you don't need to type it in again.

However, whereas other web applications pull your account name from a cookie saved in your browser, the AT&T application used the hardware identifier (ICC-ID) from the mobile phone SIM chip. Also, while the login page appears to be a native application, it is in fact pulled from the AT&T website. A picture of this is shown below:

AT&T assigns ICC-ID to customers sequentially. That means hackers can easily guess it. Hackers just pulled the numbers from their own iPads (as well as other sources from the Internet), incremented it, and used it to get the login page populated with somebody else's e-mail address. They wrote a simple program that would do this for them using the following URL:

https://dcp2.att.com/OEPClient/openPage?ICCID=77777777777&IMEI=0

By doing this a million times, they were able to grab 100,000 e-mail addresses.

AT&T fixed this simply by no longer populating the login page with the e-mail address. Owners of the iPad now have to type in both their e-mail address and their password in order to login.

ADDITIONAL VULNERABILITIES

Besides the "information leakage" problem, there were several other common flaws that led to this problem.

sequential identifiers

The reason you could guess a person's ICC-ID is the number is assigned sequentially. You take your own assigned number, increment it by 1, and get another valid number that identifies a different customer.

Hackers are trained to look for such things. Whenever they see a small number, they increment it to see what happens. This number is beyond the control of the web application designers, but they should have understood that this was a danger.

Let's use another example of this problem. Imagine you publish press releases on your website with a URL that looks like the following:

http://www.example.com/pr?articleID=4736

Each new PR posting is just a new article in the database, with a sequential "articleID".

The first thing a hacker tries is to grab the highest numbered article, and add one to it. They should get an error message saying no such article exists.

The hacker will then write a script that sends the new URL every 5 minutes to the website. What the hacker is hoping for is that your company puts a new announcement in the database hours before officially publishing it by linking to it from their homepage. By getting this article early, hackers can scoop other reporters or buy/sell stock before the stock price moves based on that information.

The same exists with the hidden "session IDs" that are part of cookies. If the session ID is too small, hackers can hijack somebody else's session ID by taking their current ID and making a small change to it. In other news, this appears to have happened with Apple's new iPhone 4: people pre-ordering it found they got somebody else's session accidentally. It appears the session ID was so small that it wrapped - causing multiple people being assigned the same session.

security through obscurity

This wasn't a webpage. It was an application that fetched information from a server via SSL encrypted web requests. There was no way that a hacker could ever see the URL that was being sent to the server, and no way the hacker could change it.

Or so it seems. There are many ways to discover the URL. Hackers can download the software update, extract the application files, and reverse engineer them (by using "strings") in order to find the URL. Or, they can setup an SSL man-in-the-middle proxy on their wifi, and defeat the encryption. Or, hackers could have used a dozen other techniques to find this URL.

The point is that such "implementation details" are never truly secret. Hackers can easily discover them.

This is the traditional "security through obscurity" argument. If you have a secret inside the application running on a user's device, you have to assume that the hacker can discover that secret.

We see this a lot in our pentests. For example, a lot of banks use ActiveX controls in Internet Explorer because, unlike JavaScript, hackers cannot see the source code. We love this, because we are really good at reverse engineering. We drop the ActiveX control into IDApro, and almost instantly find some secret that allows us to hack into the system. Sure, it looks too "obscure" to you, since you don't have years of experience with reverse engineering. The point is that we have, so such secrets are "obvious" to us.

internal vs. external

Hacking has a simple threat model: they can't change anything internal to the server, but they can manipulate the external data being sent to the server. If it's sent across a network, then by definition, it's external to the system.

Yet, developers have a hard time understanding this. They frequently assume that certain things can't be changed by hackers. In this case, it was the "User-Agent" string. This string is included in every web request, and identifies the browser and system sending the request, like "Firefox running on Windows 7". Since it's hard-coded into browsers, web application designers assume hackers cannot change it.

But of course they can. They can edit the code of their browsers. They can change it when the request goes through a proxy. When they write their own script to create web request, they can put anything in their User-Agent string that they want.

In this case, the server rejected web requests that didn't have 'iPad' in their User-Agent strings. The hackers script therefore lied, and put iPad in the string in order to get the server to accept their requests.

CONCLUSION

I created a list of bad decisions above: information leakage, trusting sequential numbers, relying upon the security of obscurity, and not respecting the boundary between internal and external data.

But nobody made these bad decision explicitly. They don't appear in the requirements or design specs. They aren't necessarily visible in the code.

Only now that a hacker has taken this to the logical extreme does the problem become apparent. This is probably the biggest lesson in cybersecurity: after the hack, it always appears that people must have been morons for making obvious mistakes. In truth, such problems are not as obvious when the application is being designed.

I, and others, put "information leakage" in our top 10 list. We've exploited this in virtually every web application pen test we've done. Maybe it doesn't appear on lists like the OWASP Top 10 because it's not clear you've made a mistake until after hackers have exploited it.


UPDATE: Why it's not "OWASP A4 - Insecure Direct Object Reference"


My first thought was "this is just #4 on the OWASP list: Direct Object Reference", because the exploit URL clearly matches the example URL for #4:

http://example.com/app/accountInfo?acct=notmyacc
https://dcp2.att.com/OEPClient/openPage?ICCID=notmyacc

But then I started thinking about the differences.

The biggest one is that #A4 applies to "output", but the AT&T page is "input". It produces a page with the tag:

<input id="email" name="email" type="email" placeholder="Required" value="ipad@robertgraham.com" autocapitalization="off" autocorrect="off">

In addition, #A4 applies to something you get AFTER you've logged in. The AT&T hack, however, occurred BEFORE login.

The hacker didn't "manipulate" data to get unauthenticated information. The next time he opened this application, he was presented with his own e-mail address without first logging in.

The most important item, though, is that this scenario matches neither the "Am I Vulnerable?" no "How Do I Prevent This?" discussions related to #A4.

Imagine you are the security auditor. You simply go down the list of all object references to see if they are secure. You wouldn't find this problem, because it's not an object reference in the traditional sense. Moreover, AT&T's solution to prevent this was completely unrelated to the remediation suggested by OWASP.

In short, this scenario matched none of the "object reference" issues I've had familiar with. On the other hand, it did match all the "information leakage" issues I've faced. It often occurs before the login process (as in this case), and fixing it usually involves simply removing the information being leaked (also as in this case).

OWASP doesn't define "information leakage", but the book I mention describes it in Chapter 14. They describe it mostly in the context of error messages, which is where I normally see it as well. While a login prompt isn't an error message, it's still a "system status message" saying you aren't logged in. Information leakage is the idea that developers think they are revealing harmless information, which the hacker than then turn around and make harmful.

I think there is a temptation to extend each of the Top 10 items to cover as much as possible, to twist every problem so that it somehow fits under an existing category. I think that is wrong. The Top 10 list should encompass every thing -- it should just be the Top 10 specific problems. I have a lot of experience with direct object references and with information leakage, even if there is some overlap, I see them as distinctly different problems, with different auditing strategies to find them, different ways to exploit them, and different ways to fix them. One might argue "information leakage" is only #11 on the list (and therefore not part of the Top 10), but I don't think you can argue that it's the same thing as "direct object reference".

UPDATE:

jeremiahg: RT and YES! @VerSprite: Info Leakage is not a vuln, but the effects of an exploited vuln. Many of the OWASP Top 10 may lead to info leakage

There's a difference in leakage before and after exploitation.

We coined a new term in a Blackhat presentation several years ago, "data seepage", to specifically differentiate from such "information leakage" you describe. We refer to "data seepage" as information that is knowingly provided publicly, without authentication or encryption -- for which you later regret.

A good example is the way that most wifi defice send out WiFi probes for each of the devices it knows about in it's connection list. Imagine you are sitting in the lobby of the PGP offices, and you suddenly see three different devices probing for "Symantec Internal". You might then discover that Symantec is trying to acquire PGP. Some devices, notable Apple's now, turn that off. Thus, while sitting in a Starbucks, you see lots of Blackberries "seeping" information about the companies these guys work for, while iPhones are mercifully quiet.

Rather than use my own term, I used the term "information leakage" in the context of the book I described above. They used it to refer to either information that helps you exploit the system (like path names), or useful data outright (like e-mail addresses). Maybe I should've used "seepage" instead.

By the way, I was talking to Dave Maynor, and he instinctively said "it's not on the OWASP Top 10" without thinking too hard about it. From his perspective, the top vulnerabilities are those that hackers can easily find and exploit with automated tools. This leakage/seepage issues is harder to exploit, and therefore, doesn't belong in the Top 10. I suppose that begs the question of "Top 10 most common" vs. "Top 10 most dangerous".