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 1 / 2   >   >>
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...
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.
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.
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...
theb0x
50%
50%
theb0x,
User Rank: Ninja
9/4/2014 | 4:34:48 PM
Apples 2 Factor Authentication still a FAIL
I just wanted to point out the Apple 2 Factor Authentication does NOT protect iCloud Backups and can be installed with only an Apple ID and password. Access to iPhone backups can easily be obtained using malware or a phishing attack to steal the authentication token created by iTunes. This method does NOT require a password.


A verification code is not required to restore a iCloud backup to a new device. This is a major flaw that needs to be addressed by Apple and has been well known for over a year.

Even if all these Celebs had 2 factor authentication enabled, their iCloud backups and Photo Streams would still have been compromised.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
9/4/2014 | 4:17:44 PM
What should Apple do?
So Apple has clearly not impressed the Dark Reading community with its transparency over the celeb nude photo  hack. So what would it take for them to win you over?
Some Guy
50%
50%
Some Guy,
User Rank: Strategist
9/4/2014 | 4:05:38 PM
Re: Spot on!
Sure it is. Apple just needs to make their iCloud users aware that there are two copies of every picture you stream and you have to delete both -- that's where the "deleted" pictures came from in this attack.
theb0x
50%
50%
theb0x,
User Rank: Ninja
9/4/2014 | 4:02:22 PM
Re: Spot on!
That is not something Apple can fix or any other cloud service. It is impossible to confirm that when a file is 'deleted' from the cloud that it is actually destroyed. This is one of the major drawbacks to any cloud service.
Some Guy
50%
50%
Some Guy,
User Rank: Strategist
9/4/2014 | 1:57:46 PM
Spot on!
I think you nailed them right between the eyes on this one. The other thing to mention is that some of the celebs talk about how they are seeing photos that they DELETED, and deleted a long time ago. Apple needs to fix that, too (even if it's just better user training on how photo streaming really works).

As for Apple's posturing on this, it's all PR. And PR, as we all know, is for when the truth just won't do.
GonzSTL
50%
50%
GonzSTL,
User Rank: Ninja
9/4/2014 | 11:44:56 AM
Re: Great Article!
This whole situation is almost comical. First of all, I fail to understand why a lockout feature was not in place to mitigate a brute force attack on user credentials. That violates one of the oldest security practices established decades ago! This should have been handled at the configuration, testing, and audit phases of the rollout. Heads should roll on that one, I think. Next is the whole practice of storing that kind of personal information in the cloud without some form of strong authentication. What were they thinking? Then there's Apple's media release exculpating themselves. Really? No brute force protection - really? I realize that no organization is invulnerable, but certainly this event has tarnished Apple's brand, and their response did not help. Apple, step up to the plate and come up with something more than what you released to the media. At least admit that you did not have what should have been the minimum required protection for user credentials, instead of having it revealed by outsiders who did their own testing and proved that you did not have it in place at the time of the breach. To be clear, I am not here to bash Apple; I love and use their mobile devices, and will continue to do so. I just want a little transparency, especially in light of this event.
Page 1 / 2   >   >>
Ransomware Grabs Headlines but BEC May Be a Bigger Threat
Marc Wilczek, Digital Strategist & CIO Advisor,  10/12/2017
20 Questions to Ask Yourself before Giving a Security Conference Talk
Joshua Goldfarb, Co-founder & Chief Product Officer, IDDRA,  10/16/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Be a unicorn, not a donkey...
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.