In September 2014, the internet went a bit crazier than it usually is for a while: A person that remains anonymous as of writing this released an avalanche of intimate photographs of various celebrities to the prying eyes of the public. It’s safe to say that this has been a huge invasion of privacy of the affected individuals. For obvious reasons, finding out how this happened is an essential part of potentially preventing further incidents, no matter what type of data may be affected.

While there is no conclusive answer to the question of How as of right now, the theory that Apple’s iCloud may have been involved in at least a few cases is one of the more solid ones, for one specific reason: Some prior evidence of a vulnerability that may or may not be involved in the process.

The Previous Vulnerability

Let’s go back in time for a bit: A security researcher discovers the lack of a lockout mechanism in a specific part of the FindMyiPhone API, leaving it open to brute force attacks. Usually, when authentication components are concerned, it is considered a requirement that some sort of mechanism prevents these attacks by locking the account temporarily, delaying subsequent authentication attempts from the same origin, showing a captcha or other more or less effective methods. But this API component did not have this, allowing an attacker to shuffle through an enormous amount of potential passwords until he found the right one.

Considering the fact that this is usually solved on application level and Apple’s servers deal with an enormous amount of traffic every second of every day, it’s unlikely that such an endeavour would show up in any monitoring they might use. And if it would, it probably wouldn’t get the necessary attention and considered yet another small-sized botnet DDoS attempt.

After this vulnerability was discovered, the researcher Alexey Troshichev posted Proof-of-Concept code to GitHub, illustrating the impact of the problem with a small utility he called iBrute.

It is not really relevant if this bug or the code published was involved in the leaking of this sensitive material that violated the privacy of various celebrities. The fact is: It could have. And Apple could have prevented it, if they had followed a trend that picked up massive steam lately: Bug Bounties.

Cash for Vulnerabilities

A bug bounty is a pretty simple concept: A company may invite people to report potential security problems and, if they prove to be actual vulnerabilities, pay the researcher a certain amount of money for bringing it to the vendor’s attention.

Apple is one of the few large tech companies that do not pay bug bounties. While they do invite researchers to share vulnerabilities with them, there is no program that will reward them to go through the trouble of actually doing so. For a very long time, Apple barely gave any credit to researchers identifying vulnerabilities, so it’s only natural that the willingness to share crucial information with the vendor is somewhat limited.

Facebook, on the other hand, has been running a bug bounty program for years now and their experiences are a completely different story. In January 2014, Facebook paid a researcher a whopping USD 33 500 for a critical vulnerability that would have allowed an attacker to read arbitrary files on the webserver. In 2013, Facebook paid more than 1.5 million US Dollars in total in bug bounties for a total of 14 763 submissions, 687 of which were eligible for a bounty.

Google, who is running a bug bounty program as well, paid out about 2 million US Dollars in the same time period. At this point in time, it is assumed that over 350 vendors offer bug bounty programs in every possible flavour. While Facebook has a minimum of USD 500 as a bounty sum, Twitter sticks with an iconic (but relatively unattractive) USD 140, matching the character limit on a tweet. Etsy, a well-known marketplace for crafted goods, offers a more symbolic reward in form of a public acknowledgement as well as a t-shirt.

The idea of bug bounties is far from new: When Netscape 2.0 was released in 1995, the developers offered mugs and polo shirts to people who would find a bug in the then-famous browser.

Apple is definitely one of the big players who can and should maintain a bug bounty program, this does not necessarily mean that everyone should. Katie Moussouris, who used to work for Microsoft and built their inhouse bounty program from scratch, talked about this at RSA 2013 in a flash talk, urging companies to make sure they are able to evaluate submissions and react to them properly before going public with a program.

And she is probably right: Only after everything a company can do by itself, with due diligence, to make sure that its infrastructure and products are secure, the full potential of a bug bounty program can be harnessed. Paying thousands of dollars for simple Cross-Site-Scripting vulnerabilities that even an inexperienced tester using an automated scanner can find is not the most sensible thing to do here.

But even if an organisation is not ready to make the jump: Understanding how the vulnerability market works in 2014 is crucial for many reasons. Bug bounty programs provide researchers with an easy way to deal with vulnerabilities without being criminalized or threatened. It’s not a rare experience for a researcher contacting a vendor offering to disclose a vulnerability, often without any monetary demands, to be instantly informed about potential legal consequences, sometimes in a very harsh tone. It’s also a valid alternative from trying to sell your findings through a vulnerability broker, which is definitely a way to make more money, but brings the moral problems of potentially selling these bugs to three letter agencies or syndicates heavily involved in cybercrime.

Seeing how frequently these programs are being utilized by researchers from all over the world, the assumption that Apple could have prevented a potential bruteforce attack on every registered iCloud account is probably valid – or at least a considerable question that Apple should face. If a bounty program was in place, iBrute may never have become a live bullet, but a mere couple of hundred dollars in Apple’s checking account.

About the Author

Stefan Friedli is a well-known face among the Infosec Community. As a speaker at international conferences, co-founder of the Penetration Testing Execution Standard (PTES) as well as a board member of the Swiss DEFCON groups chapters, he still contributes to push the community and the industry forward.

Links

• http://www.forbes.com/sites/kashmirhill/2014/01/15/so-you-found-an-obamacare-website-is-hackable-now-what/
• https://github.com/hackappcom/ibrute
• https://www.facebook.com/BugBounty/posts/778897822124446