New Version of Tool for Busting-Open Apple's KeyChain Serves as a Security Reminder

Yesterday, via email, I received a news alert with the subject line "Elcomsoft Phone Breaker 7.0 Extracts iCloud Keychain." You can read the press relase to get an idea of what showed up in my inbox.

Elcomsoft's Phone Breaker, for those of you who don't remember or know the details, was one of the tools that hackers claimed to have used in an alleged API-related attack dating back to Sept 2014 that became known as "The Fappening." I say "alleged" because Apple never acknowledged that the hackers had successfully penetrated the API for its Find My iPhone service even though the gory details of how it was done were pretty widely publicized by the cybercriminals themselves.

In a nutshell, the hackers allegedly discovered that the Find My iPhone API was not rate limited. An example of a rate limit is a security measure that limits the number of failed logins that a device can make over a given period of time before the targeted account and/or the device (based on IP address) is locked out from any further login attempts. Most of us have bumped into Rate Limiting when we've forgotten our online banking password. In some cases, there's a "cool down" period which means you have to wait some pre-determined period of time (like 15 minutes) before you can try again. In other cases, you have to call the service provider's hotline to unfreeze the account. 

With no rate limits on the Find My iPhone API, a script that the cybercriminals wrote to test thousands of permutations of IDs and passwords at lightning speed went unchallenged. Eventually, the iCloud accounts of several celebrities were compromised and, using Elcomsoft's Phone Breaker (a software that anyone can purchase), the bad guys were able to extract  and circulate (on the dark Web) compromising photos that the celebrities thought to be both private and protected. Apple attributed the incident to a phishing attack but the same white hat hackers who originally confirmed that the API had no rate limits on it then later confirmed that rate limits were imposed within hours of the news getting out. 

So, why bring this up again, now? 

Whereas Phone Breaker was previously able to extract data (like embarrassing photos of celebrities) being saved to Apple's cloud, now, it can extract and unpack what's known as the iCloud Keychain. In a post to Elcomsoft's blog entitled Acquiring Apple's iCloud Keychain, Oleg Ofonin wrote:

iCloud Keychain is Apple’s best protected vault. Since iCloud Keychain keeps the user’s most sensitive information, it’s protected in every way possible. By breaking in to the user’s iCloud Keychain, an intruder could immediately take control over the user’s online and social network accounts, profiles and identities, access their chats and conversations, and even obtain copies of personal identity numbers and credit card data. All that information is securely safeguarded.

But is it really? (securely safeguarded?)

According to another post entitled How to Extract iCloud Keychain with Elcomsoft Phone Breaker, Olga Koksharova wrote:

Starting with version 7.0, Elcomsoft Phone Breaker has the ability to access, decrypt and display passwords stored in the user’s iCloud Keychain. The requirements and steps differ across Apple accounts, and depend on factors such as whether or not the user has Two-Factor Authentication, and if not, whether or not the user configured an iCloud Security Code. Let’s review the steps one needs to take in order to successfully acquire iCloud Keychain.

So, basically, if one can acquire the iCloud keychain, they can also discover any secrets it contains. However, on first blush, that seems like a big "if." For example, if rate limits are imposed on APIs and users elect to further secure their accounts with two-factor authentication (this is where a service provider uses SMS to text you a one-time secret code that must be furnished to complete a login), the security appears to be rather fool-proof. Right? Not only would it cause failure to script that cycles through all sorts of ID and password permutations, the bad guys would have to be in possession of the user's phone to obtain the secret code. Or would they?

As it turns out. Maybe not. A few days ago, the New York Times reported that identity thieves are having success at hijacking cellphone accounts. According to the story, "In a growing number of online attacks, hackers have been calling up Verizon, T-Mobile U.S., Sprint and AT&T and asking them to transfer control of a victim’s phone number to a device under the control of the hackers." As shocking as it sounds (you will ask yourself "How can this be possible?"), the story goes on to describe how hackers have somehow been very persuasive with the personnel that man the support lines at the various carriers. 

The story goes on to say "Once they get control of the phone number, they can reset the passwords on every account that uses the phone number as a security backup — as services like Google, Twitter and Facebook suggest." In other words, once the hackers hijack the phone number, they're also able to intercept any two-factor authentication workflows that work over SMS. For now, the cybercriminals appear to be targeting people that maintain cryprocurrency balances (millions of dollars have been irrecoverably lost). But, if the story is true, then the take away is that SMS is technically vulnerable as a channel for two-factor authentication and for now, there's not much we can do about it. It's up to the various mobile carriers to figure out how to procedurally eliminate any chance of their support personnel falling prey to such social engineering. 

The ability of hackers to hypnotize unsuspecting support personnel into performing an unauthorized phone number transfer demonstrates the tenacity with which cybercriminals approach their objectives. To further emphasize the degree to which they view Apple iCloud user accounts as juicy targets, Apple users have also recently reported an iMessage Phishing Scam. According to the MacObserver's Andrew Orr, "As shown in the image, a contact called 'iMessage' sends people an SMS message that says: 'Your iPhoneID is due to expire today. Tap <link> to update and prevent loss of services and apps.' .....There is no such thing as an ‘iPhoneID’ of course, but some Apple customers may not know that."

As you can see, the image is pretty convincing and, unfortunately, there are many unsuspecting users who will fall prey to a phishing attack of this nature. Much the same way Keychain data can be exfiltrated if hackers gain account access through the previously mentioned means, the same can be done if hackers are able to login to an account after obtaining the account credentials by way of a phishing attack. To help users, Apple has published a support note that helps its customers to know what to be on the lookout for.

It's a literal jungle out there. There are predators, they are after you, and they will take advantage of any vulnerability that they can find which is why at the very least, news of this upgrade to Phone Breaker should serve as as a reminder to both end users and API providers of the following things you should minimally do to improve your chances of surviving:

  • For API providers, rate limiting is not to be overlooked as a security measure when protecting your APIs from intruders. Without rate limits, there's not much to keep cybercriminals from hacking away at your API until they acheive success. API development across an organization should take place according to certain standards and repetitive patterns. For example, set standard policies that not only require rate limiting for all APIs, but that include a prescription for exactly how to implement it; one that's specific about the organization's tolerances for multiple failed attempts. Should you allow three? Five? Is there a cool-down period or is a phone call required?
  • For API providers, if a typical deployment involves an end-user application that's accessing your APIs, offer two-factor authentication (2FA) as an option for authenticating the authentication. As discussed earlier, it's not foolproof. But, in addition to significantly raising the barrier to an attack that affects a massive number of users, it makes it nearly impossible for hackers to scale their attacks. For extra measure, no matter what user ID and password is entered, respond with something like "We've texted you a secret code. Enter it here" in your User Interface. This way, hackers will never know if they actually found a legimate account. 
  • For API providers, the days of user IDs and passwords (sometimes referred to as "Basic Authentication") are in fact waning. Most users use the same ID and password from one service to the next which is very problematic. Shift your authentication methodology to one that's token based like an OAuth workflow as soon as possible.
  • For end users, if your service provider -- ANY service provider -- offers 2FA as an option, don't waste time taking advantage of it. Again, as pointed out earlier, it's not flawless. But it amounts to a fair amount of friction in the face of a hack and, while cybercriminals are tenacious a find ways around some friction, it might slow them down enough that they move-on to another target. 
  • For end users, consider moving to a Google Voice-based phone number. Google Voice numbers cannot be "moved" by weak-minded support people that work for the various carriers. One advantage of a Google Voice number is that it's like a number for life. No matter how many times you switch phones or carriers, you can always map your GV number to your new phone or new carrier. There are other advantages that I won't cover here. But I've had my GV number for a very long time. Your phone will still respond to inbound calls and texts to its native number. But the less you give that number out, the less activity you'll see coming through that number. One caveat; there are a handful of services that cannot SMS text to a GV number. In those cases, you may have to give them your phone's native number. But even if that's as many as 50% of the services you're using, you'll still be a bit more secure with half of the services that you work with.
  • For end users, be extremely vigilant when receiving emails, SMS text messages, or other notifications. Unless you are sure about the source of the message or the authenticity of the link it wants you to click, don't bother clicking any links or tapping any buttons. This is especially true if the message makes it sound as though it's urgent. If you're not sure, then contact the service provider and ask. 

This isn't meant to be an be-all end-all to-do list to tighten up personal and API security. But it covers some of the main bases that are often overlooked; bases that can make all the difference between get hacked, or not. 

Be sure to read the next Security article: Google Introduces Beta Version of App Engine Firewall