Attacks/Breaches
7/22/2013
10:26 AM
Connect Directly
RSS
E-Mail
50%
50%

Apple Developer Forum Hack Explained

Turkish security researcher said his bug report wasn't malicious, disputes Apple's claim that attack compromised information on iOS and Mac OS X developers.

Apple said Sunday that its developer portal was hacked Thursday, putting the personal details of 275,000 third-party developers at risk. Some portal members have already reported seeing unauthorized password-reset requests for their Apple IDs.

Apple said the developer portal will remain offline, pending security improvements. As of Sunday, the members' area of the Apple developer portal had been replaced with this message: "Last Thursday, an intruder attempted to secure personal information of our registered developers from our developer website. Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers' names, mailing addresses and/or email addresses may have been accessed," it said.

"In the spirit of transparency, we want to inform you of the issue. We took the site down immediately on Thursday and have been working around the clock since then," said Apple.

[ So much for the myth that Apple has Fort Knox-level security. See Hangover Won't End: More Mac Malware Found. ]

But a London-based Turkish information security researcher who's claimed credit for disclosing the developer portal flaws to Apple said his effort wasn't meant to be malicious. "Apple!! This is definitely not an [sic] hack attack !!! I am not an hacker, I do security research" tweeted the London-based security researcher Ibrahim Balic, who runs a digital marketing agency.

"My intention was not attacking. In total I found 13 bugs and reported [them] directly one by one to Apple straight away," Balic told the Guardian. "Just after my reporting [the] dev center got closed. I have not heard anything from them, and they announced that they got attacked. My aim was to report bugs and collect the datas [sic] for the purpose of seeing how deep I can go with it." According to The Hacker News, Badic demonstrated the exploit against 73 of his own employees' Apple IDs. But he said the bugs would have given him access to information on at least 100,000 Apple developers.

Seeking to address the apparent hacking accusation, Balic on Sunday posted a YouTube video showing a "data leaks user information" bug report to Apple, dated early Friday morning, London time. The video also appeared to show him being able to access other portal members' Apple IDs and email addresses.

Balic's YouTube post alone drew angry comments from other developers. "Ibrahim next [time] you do this obscure the personal information of the users accounts. Saying you will delete ... data is great except for anyone being able to do a screen grab on the accounts you did display," read one comment. Another added: "This guy should be sued for displaying personal data."

The timing of Balic's bug report lines up with Apple taking the developer forum offline Thursday. But it's not clear if Balic's bug report was posted to a forum accessible by anyone who was a registered Apple developer. If so, other developers could have capitalized on the bugs he discovered.

As of Monday, Apple's developer forum, where software development kits and beta versions of iOS 7 and Mac OS X Mavericks could be downloaded, remained unavailable. "We're completely overhauling our developer systems, updating our server software and rebuilding our entire database," said Apple's outage notice, which was emailed to developers Sunday. Apple also said that it would extend the membership period for any developer whose membership was set to expire while the portal was offline, and promised that their iOS and Mac apps would remain available for sale.

One risk from Apple's developer forums being compromised is that members might be subjected to phishing attacks. If successful, those developers' accounts could be compromised by attackers, who might create malicious versions of the apps and submit them to Apple's App Store.

Despite Apple promising transparency over the temporary portal shutdown, prior to Sunday its developer forum had displayed a message saying only that the outage was due to "maintenance taking longer than expected," which drew criticism from third-party developers. Instapaper creator Marco Arment, for example, said presciently on his blog Sunday that Apple had most likely either experienced a data loss or "a security breach, followed by cleanup and increased defenses." He added: "The longer it goes, especially with no statements to the contrary, the more this becomes the most likely explanation."

Apple's third-party developers aren't the only people to have had their personal details exposed in recent days. Software development firm Canonical, which supports the free, open source Debian GNU/Linux distribution Ubuntu, said Saturday that it had taken the Ubuntu forums offline the same day, after they were replaced by an image of an assault-weapon-wielding Tux, the Linux mascot, and "@Sputn1k_" label, which was a name-drop from the hacker responsible.

"Unfortunately the attackers have gotten every user's local username, password and email address from the Ubuntu Forums database," read a security warning posted on the forums' site. Thankfully, "the passwords are not stored in plain text, they are stored as salted hashes," it said. Even so, the company recommended that anyone who had reused the password on another site change it there immediately.

A Twitter account in the name of @Sputn1k_ had been suspended Monday. But a Sunday tweet to the account read: "You can stop worrying about your passwords. Yes, they were encrypted." Meanwhile, a longer post from "Sput," made via TwitLonger, noted that the passwords had been encrypted using vBulletin's default hashing algorithm of MD5 plus salt. "Whilst it may not be the strongest, when you're dealing with 1.8m users it would take a very long time to get anywhere with the hashes," said Sput.

"You don't have to worry about a DB leak. That isn't how I like to do things," he promised.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-1544
Published: 2014-07-23
Use-after-free vulnerability in the CERT_DestroyCertificate function in libnss3.so in Mozilla Network Security Services (NSS) 3.x, as used in Firefox before 31.0, Firefox ESR 24.x before 24.7, and Thunderbird before 24.7, allows remote attackers to execute arbitrary code via vectors that trigger cer...

CVE-2014-1547
Published: 2014-07-23
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 31.0, Firefox ESR 24.x before 24.7, and Thunderbird before 24.7 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors.

CVE-2014-1548
Published: 2014-07-23
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 31.0 and Thunderbird before 31.0 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors.

CVE-2014-1549
Published: 2014-07-23
The mozilla::dom::AudioBufferSourceNodeEngine::CopyFromInputBuffer function in Mozilla Firefox before 31.0 and Thunderbird before 31.0 does not properly allocate Web Audio buffer memory, which allows remote attackers to execute arbitrary code or cause a denial of service (buffer overflow and applica...

CVE-2014-1550
Published: 2014-07-23
Use-after-free vulnerability in the MediaInputPort class in Mozilla Firefox before 31.0 and Thunderbird before 31.0 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) by leveraging incorrect Web Audio control-message ordering.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Where do information security startups come from? More important, how can I tell a good one from a flash in the pan? Learn how to separate ITSec wheat from chaff in this episode.