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
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-3154
PUBLISHED: 2020-01-27
CRLF injection vulnerability in Zend\Mail (Zend_Mail) in Zend Framework before 1.12.12, 2.x before 2.3.8, and 2.4.x before 2.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in the header of an email.
CVE-2019-17190
PUBLISHED: 2020-01-27
A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the...
CVE-2014-8161
PUBLISHED: 2020-01-27
PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.
CVE-2014-9481
PUBLISHED: 2020-01-27
The Scribunto extension for MediaWiki allows remote attackers to obtain the rollback token and possibly other sensitive information via a crafted module, related to unstripping special page HTML.
CVE-2015-0241
PUBLISHED: 2020-01-27
The to_char function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric ...