Forgot your password?
typodupeerror
Security Apple

Apple: Developer Site Targeted In Security Attack, Still Down 112

Posted by samzenpus
from the protect-ya-neck dept.
An anonymous reader writes "Apple has informed developers that an intruder gained access to its developer site database. Quoted email from Apple: '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. 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. In order to prevent a security threat like this from happening again, we're completely overhauling our developer systems, updating our server software, and rebuilding our entire database. We apologize for the significant inconvenience that our downtime has caused you and we expect to have the developer website up again soon.'"
This discussion has been archived. No new comments can be posted.

Apple: Developer Site Targeted In Security Attack, Still Down

Comments Filter:
  • by cbiltcliffe (186293) on Sunday July 21, 2013 @09:54PM (#44346593) Homepage Journal

    You don't deserve to work in IT, either.

    Any hash, whether it be SWIFFT, VSH, SHA1, SHA256, the piece of crap called MD5, or whatever, is useless by itself. It has to be compared to either another hash, or some...get this...unencrypted data that is then fed through the hashing algorithm.
    Sure, passwords are hashed. But you don't send a hashed password from your browser. You send the regular password, which is then hashed by the server, and the resulting hash is compared to the stored hash on the server. If they match, you're let in.
    That means that the unencrypted password is in memory on the server, just as the GP stated.

    Now, this may be completely moot, if the hack was simply an SQL injection, or the like, which only allows access to data in a database, but at this point we, and probably even Apple, has no way to guarantee that this is the only method that was used to break into the server(s). Most security vulnerabilities, on the other hand, can be used to obtain access to disk data, and also to potentially install malware, or access memory data. We don't have enough information from Apple to know that this was one of the very few classes of hacks like SQL injection that definitely cannot install malware. I suspect Apple doesn't know, either.

  • by maccodemonkey (1438585) on Monday July 22, 2013 @12:21AM (#44347313)

    That means that the unencrypted password is in memory on the server, just as the GP stated.

    But relating that back to a user id is another can of worms. And that's assuming that the hacker even had access to memory, or the passwords are even still in RAM. A server isn't going to want to keep that in memory for performance reasons alone.

    We might be making judgements on IT skills in this thread, but the amount of CS skills are lacking.

  • by SuperKendall (25149) on Monday July 22, 2013 @12:32AM (#44347353)

    In this case, you have to assume that data was taken. No "If ands or Buts about it". Data was taken.

    I'd agree you have to assume that...

    They just don't know what data.

    A small point of phrasing, they do seem to know "what" was potentially taken at a meta level - names, addresses (physical and email), phone numbers. They just don't know what subset of user data (if any) was taken.

    So each Apple developer has to assume that someone may have that data now... but as a developer I'm not really that concerned. It's pretty much data someone could have found via other means who looked at applications I am selling. Most developer accounts belong to companies that would have public email/physical addresses anyway.

  • by SuperKendall (25149) on Monday July 22, 2013 @12:49AM (#44347415)

    Although the outage has been inconvenient, the upside of this is that the users of the system can be pretty sure Apple figured out the extent of possible damage, and also we can be pretty sure nothing else was hacked into in the meantime.

    The timeframe seems pretty long but to me it seems like any site that has been hacked should, as a rule, probably go down until the site developers can be sure nothing else will be taken and holes are closed. Yet very few other sites do this, I'm sure to avoid irking customers...

    Perhaps it's only really possible for a site like the Apple Developer website where the users can understand the technical reasons for closing a site until it is safe, but it seems like it's a better approach when possible.

    It does make you wonder though just what they are fixing that takes this many days to get back on track.

  • Weasle words (Score:4, Insightful)

    by L4t3r4lu5 (1216702) on Monday July 22, 2013 @03:46AM (#44348079)
    " In order to prevent a security threat like this from happening again, we're completely overhauling our developer systems, updating our server software, and rebuilding our entire database."

    "We knew about the vulnerability, and didn't do anything about it for months. Hopefully looking like we're doing all this to protect you means you won't sue us and find out."

"The only way for a reporter to look at a politician is down." -- H.L. Mencken

Working...