Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

9/3/2014
12:35 PM
Dave Kearns
Dave Kearns
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
100%
0%

Celeb Hack: Is Apple Telling All It Knows?

Did Apple have a system-wide data breach? No. Was it complicit through an appalling security lapse by not defending against brute force attacks? You're darn tootin'!

Recently the entire social network world, the general print media, entertainment news TV, and, really, almost every outlet that feels it is in the news business has been awash in articles about the leak of nude and compromising photographs of a large group of celebrities. Besides lots of conversation about the propriety of a) taking nude pictures and b) storing nude pictures in the cloud, there’s been a good deal of idle speculation as to how the pictures became available.

Was there one hacker? Multiple hackers? Was phishing involved? Did an entire website get hijacked?

Well, one thing we can rest assured of: It wasn’t Apple’s fault. And we know that because they told us so. According to the Apple statement, “None of the cases we have investigated has resulted from any breach in any of Apple’s systems including iCloud® or Find my iPhone. We are continuing to work with law enforcement to help identify the criminals involved.”

Well, that’s reassuring.

Wait, though: Weren’t the victims' accounts on Apple’s servers? So how did someone not authorized to use those accounts get access to them? Apple? Anything to add here? Apple? It gets really quiet at this point.

Many have suggested that phishing might have been involved. After all, many tech-savvy folk have fallen victim to this sort of attack; a good phishing attempt might get someone to reveal his or her password. Others suggest that -- since people do tend to reuse account names and passwords -- the authentication credentials could have been buried in the billions of accounts amassed by Russian hackers in last month’s big story. But the theory I find most believable is one put forward by a group of white-hat hackers on Github, called “iBrute.” What they discovered was that Apple’s “Find My iPhone” app had no protection against a brute force password attack.

In a brute force attack, hundreds and thousands of passwords are tried to gain access to an account until one succeeds. Protecting against this is simple: Just limit the number of incorrect attempts and lockout the account (either temporarily -- 30 minutes to a couple of hours -- or permanently until the person contacts the help desk). Apple chose not to limit incorrect attempts in any way. This behavior has since been corrected, but the damage had already been done.

To use this type of attack, the hacker would need to know the account name. In this case it would be an email address. So, you know a celebrity’s name, and if she has an iPhone she probably uses a me.com email address. You’ve got all the time in the world to launch a brute force attack against possible account names, a fairly easy proposition. Take Jennifer Lawrence, the celebrity most mentioned in the stories about the hack. Her address could be: [email protected], [email protected], [email protected], etc. A handful of addresses using a brute force attack and -- most likely -- you’re accessing the account in fewer than 24 hours.

Get into the account and, not only can you access the photo gallery, but you’ve got access to her address book -- the email account names of all of her celebrity buddies. Crack those accounts, and you’ve got access to even more through your brute force hack. One lone hacker, in less than a week, could have amassed all of the pictures that have been leaked.

Did Apple have a system-wide data breach? No, it didn’t, as it was so quick to point out. Was Apple complicit in the breach through an appalling lack in security by not instituting a defense against brute force attacks? You’re darn tootin’. And, while it's corrected that error in judgment, the horse is already out of the barn.

Portable electronic devices and the apps they contain can make our lives easier -- and more fun. But don’t overlook the security and privacy concerns that people have about them. You wouldn’t live in a house without locks on the doors, would you? Don’t use apps that are the electronic equivalent. And Apple? Step up, man up, and admit you might have had a part in the whole fiasco. It’s the right thing to do.

Dave Kearns is a senior analyst for Kuppinger-Cole, Europe's leading analyst company for identity-focused information security and networking. His columns and books have provided a thorough grounding in the basic philosophies of directory technology, networking, and identity ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
dak3
50%
50%
dak3,
User Rank: Moderator
9/3/2014 | 3:15:06 PM
Re: Great Article!
A MITM attack isn't something the user can defend against, easily, but can be detected by the host/server - so that's Apple's bad.

 

Even a phishing attack which acquires credentials can suffer detection based on IP address (although it could be spoofed), another factor which a good risk-based authentication system would have caught.

 

-dave
aws0513
100%
0%
aws0513,
User Rank: Ninja
9/3/2014 | 3:02:49 PM
Re: Great Article!
Yes...  Excellent article.

Apple did not satisfy me with their answer.

They responded with a statement that is, in its own way, a form of social engineering.

Those who are in the security industry would quickly smoke out the fact that Apple has not provided any evidence that they really were not at fault.  All I saw were statements of misdirection that many people would likely fall for.

Until Apple provides specific details on how the data was obtained, I will continue to hold them at fault.

IMHO, the only outs that Apple has at this point are
  • The victim(s) fell for some kind of MITM or phishing scheme.
  • The victim(s) shared their account credentials with other people in their entourage (a bad practice, but we know it happens).  Thus providing another vector for compromise of their account and data.
  • It is proven that the victim(s) released the data themselves as a form of self promotion.  Would not be the first case of such activity in Hollywood.
StuAllard
50%
50%
StuAllard,
User Rank: Apprentice
9/3/2014 | 3:00:36 PM
Re: Great Article!
The fact that Apple is vehemently denying something is not true, is often the best indication that in fact, the opposite is true. In this case, however you twist it, Apple was hacked in a massive way, and they did bot block the hack.  Their reputation is tarnished and is only getting blacker by the denials. 

Celebs should get some security awareness training as well, stop uploading highly private pictures to the cloud, and start using 2-factor authentication combined with strong passwords.

Stu Sjouwerman

CEO, KnowBe4

www.knowbe4.com
Robert McDougal
100%
0%
Robert McDougal,
User Rank: Ninja
9/3/2014 | 2:22:05 PM
Great Article!
I agree 100%.  I think that when all is said and done Apple will regret this statement.  

It appears to me they are attempting to define a breach as an event that involves attackers gaining access to company servers.  So, in this case, since the attackers only gained access to individual accounts there wasn't a breach.  

In my opinion, if the accounts were compromised by bruteforce then your systems were breached.  A matter of semantics I suppose.
<<   <   Page 2 / 2
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
6 Small-Business Password Managers
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/8/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18980
PUBLISHED: 2019-11-14
On Signify Philips Taolight Smart Wi-Fi Wiz Connected LED Bulb 9290022656 devices, an unprotected API lets remote users control the bulb's operation. Anyone can turn the bulb on or off, or change its color or brightness remotely. There is no authentication or encryption to use the control API. The o...
CVE-2019-17391
PUBLISHED: 2019-11-14
An issue was discovered in the Espressif ESP32 mask ROM code 2016-06-08 0 through 2. Lack of anti-glitch mitigations in the first stage bootloader of the ESP32 chip allows an attacker (with physical access to the device) to read the contents of read-protected eFuses, such as flash encryption and sec...
CVE-2019-18651
PUBLISHED: 2019-11-14
A cross-site request forgery (CSRF) vulnerability in 3xLogic Infinias Access Control through 6.6.9586.0 allows remote attackers to execute malicious and unauthorized actions (e.g., delete application users) by sending a crafted HTML document to a user that the website trusts. The user needs to have ...
CVE-2019-18978
PUBLISHED: 2019-11-14
An issue was discovered in the rack-cors (aka Rack CORS Middleware) gem before 1.0.4 for Ruby. It allows ../ directory traversal to access private resources because resource matching does not ensure that pathnames are in a canonical format.
CVE-2019-14678
PUBLISHED: 2019-11-14
SAS XML Mapper 9.45 has an XML External Entity (XXE) vulnerability that can be leveraged by malicious attackers in multiple ways. Examples are Local File Reading, Out Of Band File Exfiltration, Server Side Request Forgery, and/or Potential Denial of Service attacks. This vulnerability also affects t...