At ProgrammableWeb's API conference next week in London (Sept 24-26), my keynote session will identify patterns in some of the recent cybersecurity transgressions, what could have been done to stop them, and why Internet security is currently a trainwreck.
It Will Fappen To You. It's Only a Matter of Time.
It was apparently a wake-up call for the general public when, in what is now being called the "Fappening," headlines revealed that hackers were able to publish nude photos belonging to celebrities like Jennifer Lawrence that were thought to be both private and secure in Apple's iCloud. Though Lawrence very bravely acknowledged that the photos were indeed of her and not Photoshopped fabrications, make no mistake about it; for her and the other impacted celebrities, it was the ultimate digital violation of their privacy.
For Apple, which was on the verge of announcing Apple Pay -- a means by which iPhone 6 users would be able to make NFC-based contactless payments at supporting merchants -- the timing could not have been worse. When it comes to handling personal payments, nothing matters more than trust. Just ask Home Depot and Goodwill; two big national brands suffering an erosion of trust after hackers gained access to the credit card data of hundreds of thousands of their customers.
Likewise, thanks to the revelation that the so-called hackers gained unauthorized access to celebrity iCloud accounts, Apple's trust took a hit. But, in the scheme of things for Apple, it's really more like a flesh wound. Compared to other vendors of personal technology, Apple has enjoyed a relatively stellar track record when it comes to security. Meanwhile, fearful that it could happen to them, iCloud users everywhere scrambled to change their passwords, remove any sensitive content from their iCloud accounts, and reconfigure their iOS devices so as not to automatically upload newly taken photographs and video to Apple's iCloud.
But for many of us who are closer to the nuances of Internet and digital security, this was not a wake up call. This was just another successful hack in a long line of transgressions that collectively point to (1) the lengths to which hackers with nefarious intent will go to achieve their objectives, (2) the fundamental problems with the way the Internet is secured, and (3) how APIs are increasing the Internet's vulnerable surface area and what API providers must do about it. After all, while Apple will very likley regain the trust of most of its customers, a transgression of this nature could mean death for a smaller brand. The stakes are not to be underestimated.
While Apple has, in its press release regarding the incident, admitted that celebrity iCloud accounts were victimized by a targeted attack, it has also said that the attack was not a result of a breach in the security of its systems and infrastructure. While the meaning of "breach" is like "beauty" (it's in the eyes of the beholder), Apple, for its part, has not disclosed the exact details of the transgression (transparency is still a major problem in our industry) and so much of what is public at this point still falls into the journalistic bucket of speculation. Nevertheless, if true, the currently prevailing non-Apple account of the celebrity iCloud incident offers some very visceral clues as to the lengths that hackers will go to achieve their objectives.
Not So Fast Sonny!
Allegedly, at the heart of the incident was a missing safeguard (called a rate limiter) that would have prevented the hackers from employing a "brute force attack" whereby an infinite number of passwords are tried for a given iCloud account until one finally works. By now, most Internet users have bumped into a rate limiter. After several incorrect user ID and password attempts, a Web site starts to treat you with suspicion. Some sites like Google's Gmail will start by using technologies like captcha to prove that you're human and that you're not a computer that's automating repeated attempts in rapid succession. Other sites will disable your account for some period of time like 10 minutes or an hour after which you can come back for another limited round of attempts. Still, other sites, particularly financial institutions, will lock the account until a human makes personal contact with a customer service representative.
In Apple's case, part of the issue has to do with how users typically only have one user ID (an "Apple ID") and password -- called a single sign-on (SSO) --- for accessing the entire constellation of Apple's online services. From iTunes to iCloud, the keys to the kingdom involve one set of credentials. As far as we know, wherever these credentials can be supplied, Apple had Rate Limiting in place. Well, all except for at least one (allegedly); where the credentials must be supplied in order to interface with the API for Apple's Find My iPhone service. Going back to Apple's press release and depending on your interpretation of the word "breach," exploiting such a vulnerability may not technically constitute a breach. If, for example, the lack of rate limiting through the Find My iPhone API was a deliberate choice by Apple's engineers, then the hackers simply took advantage of Apple's design decision.
With no rate limiting on that one entry point into the kingdom, the hackers only needed to create a bit of software with no other purpose than to try a nearly infinite number of Apple ID/password possibilities through that entry point. Not only did they create that software. They called it iBrute and made the source code for it public on the site Github.com so that other hackers could try it out or even worse, improve it. With no safeguard in place, it was only a matter of time before several keys to the kingdom -- each for a different Apple account (one of which was Jennifer Lawrence's) -- would be discovered.
Once hackers discover a vulnerability like this one, it's a race against the clock. Sooner or later, if a company like Apple has its security act together, it will discover such vulnerabilities on its own and close them off. So, with the clock ticking, what's a hacker to do? What else but try the most commonly used passwords? For this, the hackers allegedly turned to what's commonly referred to as the RockYou database. It's a publicly available database containing the passwords for over 14 million user accounts of the RockYou social gaming service that were revealed when that service was hacked back in 2009.
If there was ever a time to say "we're only human," this is it. One of the not so dirty little secrets of digital security is how "Password" and "123456" are the two most common passwords. In fact, there's even a list of the top 25 passwords. But with a list of the passwords to over 14 million accounts (a very projectable sample of humans), coming up with a relatively accurate list of the top 500 or 1000 passwords that people use isn't too difficult either. The hackers apparently did this too. By now, if you've read this far, you're asking "What about the celebrities' email addresses (which is what Apple uses for Apple IDs)? How were they discovered?" My answer, even if for only a moment in time, this information is relatively discoverable, especially for celebrities.
There's no telling how long the hackers used iBrute to dig for the passwords for targeted Apple IDs. But once they had them, it would have been a mountain of work to login to the celebrities' iCloud accounts and pour through all of their photos looking for anything sensitive. With the clock still ticking, they would need something that off-loaded the photos to local storage before any of those IDs and passwords changed. For that, the hackers allegedly turned to the same software that law enforcement agencies use to download photos in bulk; a product called Elcomsoft Phone Password Breaker (EPPB) that Wired referred to as the Police Tool That Pervs Use to Steal Nude Pics From Apple’s iCloud. According to Wired, "EPPB lets anyone impersonate a victim’s iPhone and download its full backup rather than the more limited data accessible on iCloud.com." Once the hackers had all of the images on their own hard drives, there was nothing standing between them and a very embarrassing event for both the celebrities and Apple.
Again, it's important to note that Apple has not confirmed the majority of these details nor has it disclosed a technical account of the matter that refutes them. Since the attack, Apple has apparently applied rate limiting to the Find My iPhone API entry point. In an article published on Sept 1, 2014, TheNextWeb.com reported how various developers, using their own Apple accounts, confirmed iBrute's ability to exercise a brute force attack through the Find My iPhone API. According to the report, Apple introduced rate limiting at 3:20am PT that day, effectively neutralizing iBrute's method of attack. In an interview with the Wall Street Journal, the company's CEO Tim Cook suggested that "celebrities' iCloud accounts were compromised when hackers correctly answered security questions to obtain their passwords, or when they were victimized by a phishing scam to obtain user IDs and passwords." The WSJ article went on to say that "Apple will broaden its use of an enhanced security system known as two-factor Authentication" and also said that Cook claimed that "none of the Apple IDs and passwords leaked from the company's servers."
In its press release, Apple implored users to activate an optional version of the two-factor authentication that it offers to account holders. More specifically, the release said "To protect against this type of attack, we advise all users to always use a strong password and enable two-step verification." As explained in this how to, Apple's, two-step verification (a consumer friendly name for "two factor authentication" or "2FA") prevents everyone but the person in possession of a pre-specified trusted device (the so-called second factor; a phone, an iPad, etc.) from logging into a 2FA-secured account.
But Apple's 2FA advice is problematic for two reasons. First, since API-based interactions are automated interactions that often involve two machines talking to one another, API-based authentications are rarely secured with a second factor. If any forward-looking good comes of the so-called Fappening, perhaps it will be a conversation among API economy stakeholders as to how exactly and when to secure API-based interactions with two-factor authentications.
Second, as noted in an article published by TechCrunch about the Fappening (see Apple’s Two Factor Authentication Doesn’t Protect iCloud Backups Or Photo Streams), several security researchers have long noted how Apple's 2FA scheme doesn't cover all entry points into the Apple kingdom.
In May 2013, Ars Technica published an article (see iCloud users take note: Apple two-step protection won’t protect your data) referring to research done by the developers of EPPB that said "In its current implementation, Apple’s two-factor authentication does not prevent anyone from restoring an iOS backup onto a new (not trusted) device...In addition, and this is much more of an issue, Apple’s implementation does not apply to iCloud backups, allowing anyone and everyone knowing the user’s Apple ID and password to download and access information stored in the iCloud. This is easy to verify; simply log in to your iCloud account, and you’ll have full information to everything stored there without being requested any additional logon information."
Circling back to Apple CEO Cook's references to phishing attacks, the company has yet to offer evidence that such attacks took place in advance of the Fappening nor has evidence of such an attack gone viral on any of the social networks (which most likely would have happened). Phishing is a technique whereby hackers with nefarious intent use email to lure unsuspecting users to enter their user IDs and passwords into Web pages that look official, but that are actually impostors. These emails are a form of social engineering that often preys on current events. After news of the celebrity photos struck fear into millions of Apple's customers, it didn't take long for phishers to strike. The email pictured below, received by my wife on Sept 2, 2014, states that "your Apple/iCloud Account has been momentarily restricted until you can validate your Apple and iCloud information." However, when I moused-over the links in the email and inspected the sender's address, my browser revealed that they pointed to a domain other than Apple's; a domain where my wife's Apple credentials would most certainly have ended up in the wrong hands, had she entered them.
Regardless of how forthcoming Apple has really been about the nature of the attack or how the attacks were actually perpetrated, they reveal several important, and naked truths about Internet security.
Internet Security Naked Truth #1: Hackers Will Stop At Nothing
First and foremost (and perhaps the one truth that could provoke a new attitude across all stakeholders), as evidenced by
- The discovery of Apple's rate limiting oversight
- The publication of iBrute onto Github (which took advantage of that oversight)
- The existence and suggested usage of the RockYou database
- The discussion of EPPB as tool for batch processing of iCloud content
- The subsequent phishing attempts that preyed on post-Fappening fear,
Hackers looking to do harm are a collaborative bunch that are quite tenacious, extremely sophisticated, and will stop at pretty much nothing to achieve their ends. Several attacks in recent history, including those on Pinterest and Buffer (ProgrammableWeb investigated both since APIs were involved) continue to prove that hackers are willing to coordinate the simultaneous pursuit of numerous vulnerabilities much the same way multiple regions of a jigsaw puzzle are assembled before they're connected into a final masterpiece.
In other words, never ever underestimate the lengths to which hackers will go.
Internet Security Naked Truth #2: User IDs and Passwords Have Jumped The Shark
While the attacks are often sophisticated in their totality, the majority of them involve the discovery of user IDs and passwords, the latter of which most Internet users have forever proven incapable of securely setting and protecting, but with good reason.
This isn't just about the nearly idiotic reliance on commonly used passwords like "Password" and "123456." There was a time where pretty much everything we logged into -- our personal computers, our networks, our mainframes, our PDAs, etc. -- were local to us and all of our applications (for which passwords were not required), could be found on those devices. But with everyone's increasing reliance on the Internet for everything from compute power to storage to content to banking to shopping to dating to software and so on, there also came the nearly unmanageable problem of dealing with a separate set of credentials for every Internet-bound service.
As a result, not only are people using weak passwords as evidenced by Splash Data's aforementioned 25 worst passwords, they're using the same password across multiple services -- otherwise known as "the shared password problem" -- because we as humans can't contemplate having a different user ID and password for every service. When shared passwords are in play, once a hacker gets a hold of a user's password -- be it through brute force attacks, phishing, or some other means --- it can often be like getting the master key to every service the user uses.
Last year for example (and again, speaking to the degree of hacker sophistication that exists), Buffer.com's private Code Repository on Github was successfully penetrated when hackers uncovered the password that one of Buffer's developers was using on an unrelated service. Once hackers had access to Buffer's code repository, they were able to inspect the Source Code for other secrets that led to an even bigger attack (on tens of thousands of Buffer's users).
Making it even easier for the hackers is the trend whereby many services are eliminating user-settable IDs and instead relying on a user's email address as their login ID. The idea of having different user IDs and passwords for every service we rely on is bad enough. But, as more services rely on a user's email address as their login ID as well --- email addresses that in many cases are easy to discover or guess --- the less the hackers have to figure out and the closer they are to the crown jewels (across multiple services).
Then, there are certain credential related issues that are completely out of users' control altogether. While it would be nice to assume that all Internet-based services conform to the same set of best practices when it comes to securing users' credentials, things could not be farther from the truth. For example, using their online chat mechanism, I recently contacted the technical support department for a domain management company. As frightening as it sounds, after they asked for my user ID, they also asked me for my password so that they could authenticate that I was the account holder. It's bad enough that I was asked to furnish my password over an unsecured chat to a person that I didn't know. But then I discovered that she wasn't even entering the password into her system. She was simply conducting a visual match with the password for my account, which was already visible to her on her computer.
For anyone but me to be able to view my password is a flagrant violation of generally accepted security practices. It's also evidence that most users have no idea who they're dealing with or what security practices are in place when establishing a business relationship with a new service that requires user IDs and passwords.
Apple, for its part, employs an unusual password recovery scheme that, depending on who you talk to, could stand for improvement. For example, if a user of iTunes forgets their password, there is no password recovery process. Instead, the user is challenged with three personal questions (one of which is the user's birthdate) before they are prompted to reset the password through their Web browser. Speaking to the variability in best practices, other services allow users to reset their passwords through their Web browsers as well, sometimes after being challenged with personal questions, but only after the service sends a secret and unique password reset link to the email address of record for the user's account. Presumably, only the user has access to the email account and can click the link. Apple doesn't do this.
Needless to say, for a great many reasons, the Internet's continued reliance on user IDs and passwords as a means for protecting everything online has officially jumped the shark and it's time for the entire Internet to shift to a new paradigm altogether. For example, services like Github allow users to login with their Google credentials (and Google credentials can further be secured with two factor authentication). But, one problem with many services that support the usage of third party authentication like Google's is that users can't easily switch from their existing user ID/password scheme to the third party scheme (effectively eliminating the user ID/password route to logging on).
Internet Security Naked Truth #3: APIs Are Like Candy To Hackers
While APIs drive amazing innovation and can turn an online service into a Platform that is more easily integrated with other platforms or mashed into applications, they also make a significant contribution to the volatility of Internet security.
One of the chief selling propositions of an API is how they offer developers a programmable interface that can scale to meet the needs of their application (or whatever else might be consuming the API). But much the same way a perfectly legitimate application can rely on APIs to scale its tasks, so too can an illegitimate application with iBrute being a ready-made example. Rate limiting aside, if a human used a Web form to try the 500 most common passwords for a given Apple ID, it would take an eternity. But when a machine running iBrute does it through an API (like the Find My iPhone API), it would probably take a couple of minutes at most.
Similarly, the attacks in the last year against Buffer and Pinterest involved a degree of scale that was enabled by APIs.
Of course, as programmable interfaces go, APIs do not shoulder all of the blame. To scale their attacks where no programmable interface already exists, hackers will often just create one using a technique called ScrAPI (pronounced "scrape p. i."). This is where a developer writes code that scrapes a Web page's functionality into an API that can be called by another application (legitimate or illegitimate). However, wrapping a login page with such an API for nefarious purposes will often trigger a rate limiter since it's standard operating procedure to apply rate limiting to login pages designed for human usage.
To the extent that an API was involved, the iBrute/Find My iPhone case also raises a colossal challenge for APIs and anybody responsible for them. Rate limiting may very well be a common part of the security pattern -- one that has evolved over two decades of the Web's existence -- that site operators must apply to interfaces (e.g.: Web forms) designed for human consumption. But APIs -- designed for a machine to work with -- are an entirely different ball game requiring new patterns and best practices that are yet to evolve.
For example, if rate limiting were part of the security pattern for APIs and Apple's penetration tests (pen tests) included a test designed to stress rate limits when API calls are being made (and Apple's development practices involved ongoing pen testing of all its APIs for that pattern), Apple might have discovered the lack of rate limiting on the Find My iPhone API before the hackers did.
For those who think API security is all about securing API calls with OAuth (yet another thorny issue due to the multiple implementations currently in play) think again. The naked truth when it comes to securing APIs as a potentially hackable entry point for discovering sensitive information is that there are many layers to the API security onion, most of which have a long way to go before they are fully evolved. It would behoove vendors in the API design and management markets to better-serve their customers with products that address the various layers of that onion with solutions that can apply and enforce security patterns known to protect API endpoints and their adjacencies.
Internet Security Naked Truth #4: Two Factor Authentication Should No Longer Be Optional For Any Service
It's true that two-factor authentication will stop many hackers dead in their tracks. Once Buffer changed its standard operating procedure so as to require its developers to authenticate on Github with a second factor, the hackers responsible for the original attack appealed to the Twitter-verse for a workaround but didn't get any answers.
But most Internet services have a huge problem when it comes to 2FA; Americans. For some reason, other parts of the world --- particularly Europe -- are better sensitized to the various security threats presented by Internet technology and are willing to put up with certain inconveniences to better guarantee privacy and asset security. But not in the US where citizens are loathe to trade convenience for security.
For example, I have friends in Europe for whom 2FA is required for all online banking. I know of no one in the US (and know of no US-based bank) that offers 2FA as a means for securing all banking that doesn't physically take place in a Branch office. Bank of America's Safe Pass program, for example, offers 2FA for certain types of transactions, but not all. American banks know that if they require 2FA across the board, they will likely lose customers to a bank that doesn't. It's a culture of convenience.
Even for those of us Americans who are willing to put up with the inconveniences of 2FA, there still remains some relatively geeky friction to adoption. For example, Google offers its users the option of protecting their accounts with 2FA (like Apple, Google also gave 2FA the cosumer-friendlier name "two-step verification"). However, if you're thinking of opting-in to Google's two-step verification service, be sure to check out the fine print. For example, you better know the recovery procedure if you lose the trusted device to which you've told Google to send its 2FA codes (hint: you need to print out a set of 10 one-time codes that you keep with you everywhere you go).
It sounds as though it's an intractable problem, but it's really not. Inconvenient? Yes. Intractable? No. Worth whatever it takes? Yes.
Now is the time for the biggest Internet players to get together and agree to bite the bullet and sacrifice the convenience of its customers for security. Likewise, it's time for enterprises to bite the bullet as well, requiring all users to authenticate against corporate networks with a second factor. Corporate networks with entry points that are protected by nothing but a user ID and password represent one of the biggest vulnerabilities to the Internet's commerce infrastructure.
Internet Security Naked Truth #5: Solve the Spam Problem and You'll Solve The Phishing Problem
More than a decade ago, when working as a journalist for ZDNet.com, I attempted to round up all the Internet email stakeholders to solve the spam problem once and for all. I referred to the effort as JamSpam. I founded JamSpam on the premise that the spam problem could be solved if only everyone would agree to some new Internet email standards and practices. The effort provoked a lot of conversation and even some collaboration between various email vendors. But here we are in 2014 and the while some progress has been made, the various email players still haven't gotten together to commit to shared technology advancements that would kill virtually all spam.
For example, judging by the content of my own inbox and spam folder, not everything that automatically ends up in my spam folder is spam (known as a false positive) and some emails that should have been tagged as spam are still finding their way into my inbox. More work has to be done. Another issue has to do with the plethora of email clients that end-users use as front ends to their email systems. Despite discussing the problem over ten years ago at JamSpam, there is still no standard method for all email clients to tell all email servers that a certain message is spam.
The problems and costs associated with spam have been well documented over the years. But in the context of the naked truth about Internet security, the phishing problem is for the most part subjugated to the spam problem. Most phishing attempts involve impostor emails that pretend to come from a specific sender when in reality, they didn't. It's the same pattern for most spam which is why universally dealing with the spam problem will go a long way towards dealing with the phishing problem, which in turn, will go a long way towards protecting Internet users from being socially engineered into divulging their user IDs and passwords to a hacker.
It is time for all those involved in the Internet's email ecosystem to act.
I could easily list another five naked truths about Internet security; truths that all point to the need for massive and holistically considered reform. For example, the risks associated with unsecured source code repositories and the secrets they often contain in clear text; secrets that can give hackers the keys to some lucrative kingdoms. Or, the impact that social media has on the adoption of various cloud-based services with virtually no scrutiny having been applied to their digital security practices (it's 10pm. Do you know what that service you just signed-up for REALLY did with the user ID and password you gave it?). What about the widespread lack of transparency and disclosure when a breach happens? Though many organizations would never give it a second thought, a recent GigaOm report by analyst Kord Davis explores transparency as a form of sustainable competitive advantage.
Arguably, the sky is falling. Whether you agree or not, the very least you can do is keep in mind former National Cybersecurity Center directory president Rod Beckstrom's three rules of cybersecurity:
- Anything attached to a network can be hacked
- Everything is being attached to networks
- Everything is vulnerable
The call for holistically considered reform of digital security practices is neither new or unique. That said, the Fappening has officially drawn attention to the API's starring role in the Internet's security, or lack thereof. Given how APIs are central to the theme of ProgrammableWeb, I have picked API security as the theme of my keynote at APIcon UK in London. In my keynote, I will review the anatomies of various attacks and what could have, should have, or can be done to prevent such attacks from happening. Hopefully, for those of you who attend, you will come away with a much better understanding of the lengths to which hackers with nefarious intent will go to achieve their means, and a shared view that the sky is falling, that reform is needed, and how that reform starts with us.
If you have not already registered to attend APIcon UK in London, there is still time. Just visit the event's web site at http://www.apiconuk.com.
Hope to see you there.