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
Oldest First  |  Newest First  |  Threaded View
<<   <   Page 2 / 2
dak3
50%
50%
dak3,
User Rank: Moderator
9/4/2014 | 5:12:16 PM
Re: Spot on!
Well, a backup solution (which is what this is) wouldn't be very good if it sync'd to all your deletions. But I'll agree there should be a way to edit, or remove, files from the backup...
GonzSTL
50%
50%
GonzSTL,
User Rank: Ninja
9/4/2014 | 5:36:34 PM
Re: What should Apple do?
Simple. Bite the bullet and admit that there was no lockout feature, but they have remedied that oversight. Then, state that they are undergoing a thorough internal security assessment and independent audit of the iCloud service, to make sure that all configurations follow best practices (oh, how I hate that term). A sincere mea culpa will show that they have adult pants on and are willing to admit when they are wrong, and the assessment and audit will show that they are serious about security. That sure beats being outed by external sources and not even acknowledging it.
theb0x
50%
50%
theb0x,
User Rank: Ninja
9/4/2014 | 9:25:16 PM
Re: Spot on!
Synced deletions or not you as client have no control of the replication of your files in a farm of data centers. They can claim your files are destroyed all they want but have no way of ever proving it to you.
dak3
50%
50%
dak3,
User Rank: Moderator
9/4/2014 | 11:15:31 PM
Re: Spot on!
If you can prove that they don't remove them when you request, there's a big pay day ahead...
<<   <   Page 2 / 2
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
US Sets $5 Million Bounty For Russian Hacker Behind Zeus Banking Thefts
Jai Vijayan, Contributing Writer,  12/5/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
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-19719
PUBLISHED: 2019-12-11
Tableau Server 10.3 through 2019.4 on Windows and Linux allows XSS via the embeddedAuthRedirect page.
CVE-2019-19720
PUBLISHED: 2019-12-11
Yabasic 2.86.1 has a heap-based buffer overflow in the yylex() function in flex.c via a crafted BASIC source file.
CVE-2019-19707
PUBLISHED: 2019-12-11
On Moxa EDS-G508E, EDS-G512E, and EDS-G516E devices (with firmware through 6.0), denial of service can occur via PROFINET DCE-RPC endpoint discovery packets.
CVE-2019-19708
PUBLISHED: 2019-12-11
The VisualEditor extension through 1.34 for MediaWiki allows XSS via pasted content containing an element with a data-ve-clipboard-key attribute.
CVE-2019-19709
PUBLISHED: 2019-12-11
MediaWiki through 1.33.1 allows attackers to bypass the Title_blacklist protection mechanism by starting with an arbitrary title, establishing a non-resolvable redirect for the associated page, and using redirect=1 in the action API when editing that page.