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

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
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-20001
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
CVE-2020-36317
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
CVE-2020-36318
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
CVE-2021-28875
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
CVE-2021-28876
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...