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.

Comments
Celeb Hack: Is Apple Telling All It Knows?
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


COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8937
PUBLISHED: 2020-06-01
Lexiglot through 2014-11-20 allows denial of service because api/update.php launches svn update operations that use a great deal of resources.
CVE-2014-8938
PUBLISHED: 2020-06-01
Lexiglot through 2014-11-20 allows local users to obtain sensitive information by listing a process because the username and password are on the command line.
CVE-2014-8939
PUBLISHED: 2020-06-01
Lexiglot through 2014-11-20 allows remote attackers to obtain sensitive information (full path) via an include/smarty/plugins/modifier.date_format.php request if PHP has a non-recommended configuration that produces warning messages.
CVE-2014-8940
PUBLISHED: 2020-06-01
Lexiglot through 2014-11-20 allows remote attackers to obtain sensitive information (names and details of projects) by visiting the /update.log URI.
CVE-2014-8941
PUBLISHED: 2020-06-01
Lexiglot through 2014-11-20 allows SQL injection via an admin.php?page=users&amp;from_id= or admin.php?page=history&amp;limit= URI.