Google offers $200,000 for Android-busting exploit

Google has just announced a big-money bug-chasing competition for Android – and this one is a contest with an interesting twist.

Simply put, you do this:

1. Choose one of Google’s official “over the air” Android 7 firmware releases for the Nexus 5X and 6P phones.
2. Figure out a remotely exploitable sequence of bugs by which you can steal files from another app.
3. Prove your exploit to Google within a one-hour “hacking window”.
4. Pocket $200,000.

Once the main prize has gone, there’s another $100,000 for second place, and $50,000 to be split amongst other winners.

Stage (3) is the exciting part, and you really do need a remote exploit that relies on minimal action from the user.

When you’re ready to do battle, Google will fire up one 5X and one 6P phone on the T-mobile network in the US, and give you an email address and a phone number for each.

The only user interaction you’re allowed is to send an email or an SMS to each device; Google will read the emails or view the text messages, and that’s that.

You can put “click here for free stuff” links in your email, or ask the users to “try this fantastic app” in your SMS, but that’s not going to win you any money.

Nothing will be clicked or downloaded; no one will helpfully follow your “advice” to change critical system settings; and any dialogs or login windows that pop up will simply be ignored.

In other words, the sort of social engineering that works in the real world isn’t allowed here.

You will need a purely technical zero-day attack of the sort that well-heeled crooks, industrial spies and state-sponsored actors would love to find, where there are no obvious giveaways by which a well-informed user could avoid getting infected.

In fact, the rules explicitly say:

Entries that take an excessive amount of time to run, substantially interfere with use of the device, give clear indications of attack or are otherwise impractical may not be accepted, at our discretion.

What’s new?

At this point, you’re probably thinking, “How does this differ from competitions like Pwn2Own and Pwnium? Where’s the interesting twist?”

The problem with Pwn2Own-type competitions, which attract the world’s top bug-hunters because of the serious prize money on offer, is that they follow an all-or-nothing disclosure process.

These days, reliable and working remote code exploits just aren’t as easy as they used to be in the Windows XP era, where a single vulnerability in one app was often enough to let you take over a computer completely.

Thanks to defence in depth, using a combination of preventative techniques such as Data Execution Prevention (DEP), Address Space Layout Randomisation (ASLR) and sandboxing, most modern attacks actually require a series of vulnerabilities.

These security holes need to be exploited in turn to get past each protective layer and to emerge into a position of programmatic power on the device.

DEP means that when you send data to an app, such as an email client or an SMS messenger utility, the operating system treats it strictly as data. If you try to trick the app into running your data as if it were a program, you won’t get anywhere, because the operating system won’t let data be used as code.
ASLR means that handy operating system components, such as code to make network connections or launch new programs, are loaded into memory at unpredictable locations, so you can’t guess where they will be. This makes them much harder to abuse.
Sandboxes strip away the privilege of an app so that even if it misbehaves or crashes, it can’t accidentally (or deliberately!) access data or system resources belonging other apps.

As well-known hacker George Hotz famously quipped when he successfully exploited Adobe Reader XI at the 2013 Pwn2Own competition:

The first thing I did was break into the sandbox, the next thing I did was break out.

In other words, to win the big bucks in a Pwn2Own-style event, you may need to find and perfect several individually-important exploits along the way, which might take months, and then keep them all to yourself until the day of the competition.

Once you’ve won the prize, you disclose them responsibly to the relevant software vendor so they can be fixed, hopefully before any crooks figure them out.

But if you don’t win the prize, perhaps because your very last exploit in the chain fails, or if you end up pulling out of the competition because you can’t get the full attack to work reliably, you might decide to hang on to your intermediate bugs.

If the eventual winner found a different way in, your security holes might still be available for the next big-money contest, thus giving you a handy head start next time.

Google has decided on a different, less secretive, approach.

As soon as you find a bug that gets you one step closer to the prize, you have to disclose it responsibly to Google.

However, once you’ve claimed that bug, no one else can use it in their competition entry, so you retain the competitive advantage of finding it first, which is a strong incentive to disclose early, disclose often.

And Google can fix the bugs for everyone else along the way, instead of having to wait for you to do a grand reveal at the end when you claim the prize.

What to do?

Interested?

Get hacking, in the positive, not the pejorative, sense of the word.