Uber under attack – how penetration testers turn bugs into breaches

Don’t-call-them-taxis firm Uber is used to being in the security news.

From stolen credentials showing up on the dark web, through the controversy of raiding a reporter’s trip history because she was late for a meeting, to a leaky “lost and found” database, the company has had its share of security downs.

But Uber has made an effort to up its security, too, famously hiring away then-Facebook CSO Joe Sullivan, taking on two loud-and-proud car hackers to work on driverless cars, and initiating an official bug bounty programme.

A trio of Portuguese bug hunters recently decided to see what they could do with Uber’s bug bounty programme, staying within the official guidelines, and the results make interesting reading.

They’ve told their own story in chronological order, and they’ve included the parts where they found website bugs that Uber already knew about, and thus weren’t eligible for a payout.

Those make the story doubly interesting, because they remind us all that there’s more to penetration testing than just finding a security hole and reporting it, and that old holes can still have new uses.

Putting together the snippets

Many attacks rely on snippets of data leaked at one point being fed back in at another, increasing the jackpot along the way, and producing a bigger payout at the end.

(By “bigger payout”, we mean in terms of how much personal information crooks can bleed from the system, rather than the size of a legitimately-earned bug bounty!)

If you’re a programmer, you’re probably familiar with the idea of “unit testing,” a part of software development that says there is no point in trying to piece together the individual parts of a system if any of them fail in isolation.

But unit tests are really no more than a starting-point for quality: a minimum standard that stops you trying to construct an entire edifice from individually defective parts.

You still need to take into account how all the parts interact – a much harder problem that typically expands geometrically, not linearly.

If you need to consider how 5 different components behave when each one can be in 6 different states, there are 6×6×6×6×6 combinations (65 = 7776), not just 6+6+6+6+6 (30).

How bug hunters think

Here’s one example of how bug bounty hunters think.

The researchers decided to wander around in various Uber apps, looking for web pages that they could use to interact with Uber’s servers, figuring that little-used forms might be less well tested for how they interact with the system as a whole:

Uber Riders mobile application [has] a Help section that allow users to send questions directly to support. Let’s be honest, many of us almost never use the Help or even know that it exists, but as pentesters we can’t say no to another form.

They saved the HTTP request that they observed being sent off to Uber, and studied it.

You can see a special header field called x-uber-token that you’d imagine to be a session cookie that’s unique to this user for this login session, plus an item called x-uber-uuid:

The reply included the logged-in user’s email address, a personal touch that doesn’t constitute a data breach, assuming that the user has logged in already.

Loosely speaking, x-uber-token acts as a password valid for this session only, while x-uber-uuid (UUID is short for Universally Unique Identifier, a randomly-chosen 128-bit string of binary data) essentially serves as a username.

The pentesters then wondered whether the x-uber-token really would serve as an authentication password, so they changed the x-uber-uuid value to a known-good UUID for a different user and tried again.

Ideally, you would expect the request to be discarded: the server ought to notice that the UUID and the token don’t match up.

But the testers received the same reply as before: the email address sent back belonged to the first UUID, even though that UUID was no longer anywhere in the request.

In other words, the server seemed to be ignoring the x-uber-uuid header altogether, because the reply was determined by the value of x-uber-token.

So, on a whim, they tried putting the second user’s UUID into the x-uber-token field, because…

…well, why not?

Lo and behold, the second user’s email address came back.

That’s a small result already, because you shouldn’t be able to figure out my email address just from my UUID without also knowing my password.

How to find my UUID?

But how to find my UUID if I don’t co-operate?

For that, they found a second data leakage bug by trying yet more forms, because…

…well, why not?

They tried out an Uber Rider feature that allows you to split the fare if you are sharing a ride with other people.

To do so, you simply put in their phone numbers, and Uber sends them a request, asking if they want to go halvies on the fare.

But that “split request,” which you can intercept, includes the UUIDs of the other users, whether they go on to accept the fare split or not.

That doesn’t sound like a serious flaw, except that it provides an unintended data leakage path: a reliable way to convert phone numbers into email addresses, using Uber’s database as the lookup service.

Your phone number gives me your UUID, and in an unrelated part of the system, your UUID gives me your email address.

That’s the sort of security bug that unit testing alone is unlikely to find.

There are more examples in the paper by the Portuguese researchers, which we recommend you take a look at because it’s disarmingly direct, and gives you a good feeling of how they progressed during their (legal!) probing of Uber.

The good news is that the problems they found were taken seriously by Uber, who have already paid out bug bounties, and have fixed, or are in the process of fixing, the holes:

From a pentester’s view, the [Uber] security team takes this program very seriously by trying to resolve all the issues as fast as they can.

What to do?

Just remember, if you want to get into penetration testing and bug bounty hunting:

  • Read the terms and conditions. Stick to both the spirit and the letter of any bug bounty programme.
  • Disclose responsibly. Publish your findings in the agreed way at the agreed time.
  • Don’t break the law to prove a point. And don’t expect any sympathy if you do.

Security research can be fun, but always keep it legal!