Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
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 More

Apple: Developer Site Targeted In Security Attack, Still Down

Comments Filter:

  • Interesting timing... (Score:5, Interesting)

    by dottrap ( 1897528 ) on Sunday July 21, 2013 @06:36PM (#44345987)

    Interesting timing. Wonder if it was related/coordinated to the Ubuntu forums attacks.
    http://it.slashdot.org/story/13/07/21/0318243/ubuntuforumsorg-hacked [slashdot.org]

  • Purpose of the attack (Score:3, Interesting)

    by michelcultivo ( 524114 ) on Sunday July 21, 2013 @06:44PM (#44346029) Journal

    I'm thinking of the purpose of this attack:
    * Software stealing
    * Account hijacking: use the certificate to publish fake apps and get money
    * New software: tomorrow maybe the day that Apple will release iOS 7 Beta 4 and OS X Mavericks

  • Ohne Steve geht alles schief! (Score:5, Funny)

    by Anonymous Coward on Sunday July 21, 2013 @06:47PM (#44346051)

    This wouldn't have happened if Steve was still alive

  • Great info for future spear phishing (or just phishing)

    - People must look before you click (hover over link, make sure it gels with URL)
    - Never use the same password on sites, especially if the site has info you consider sensitive (and make it a good password)

    • Can you hover on an iPhone? I notice most Android email clients allow you to long-press a url to see the target, but it's not as fluid as it is using a mouse with hover.

      • Can you hover on an iPhone? I notice most Android email clients allow you to long-press a url to see the target, but it's not as fluid as it is using a mouse with hover.

        iOS is the same, long-press to trigger a menu that also reveals the actual URL. I do it all the time, usually right before I delete some spam.

        • Can you hover on an iPhone? I notice most Android email clients allow you to long-press a url to see the target, but it's not as fluid as it is using a mouse with hover.

          iOS is the same, long-press to trigger a menu that also reveals the actual URL. I do it all the time, usually right before I delete some spam.

          On iOS that functionality seems to be part of the OS rather than built into specific apps - at least it's worked in every app I've tried it in.

          • Yeah, it seems to work that way in most applications. Opera has their own weird selection/copying mechanism, so pressing and holding doesn't reveal the URL. Very odd.

            • Opera has done away with their own rendering engine, so there's no reason for Opera to even exist any more unless you happen to like their wacky interface diddling.

              • Opera is faster because of the compression they do via their servers. Also, it's less likely to crash in low memory situations, and less reloading when moving between tabs. I use it mainly when going on a wiki expedition.

  • Which one? (Score:2, Interesting)

    by Anonymous Coward

    Spirit of transparency or because there is an entire site down without any other reason?

    • Re: (Score:1)

      by Anonymous Coward

      As an iOS developer, having sites not work or not updated when they're supposed to be is SNAFU.

  • The only source of information about this is what Apple says when you try to go to the iOS or Mac developer centre, which was correctly quoted by the article. Note that there is no mention that any intruder did actually get any access to anything, as the summary suggests. It says that someone _tried_ to access developers' information, that all this information is encrypted, but they can't rule out someone's information was accessed. Quite a difference.

    • Re:The summary is wrong again... (Score:5, Informative)

      by Maestro485 ( 1166937 ) on Sunday July 21, 2013 @08:32PM (#44346525)

      Actually the source of information was an email that Apple sent out earlier today regarding the situation. I have an iOS developer license so I got the email.

      Here's a pastebin dump: http://pastebin.com/4dCWge1s [pastebin.com]

      • Actually the source of information was an email that Apple sent out earlier today regarding the situation. I have an iOS developer license so I got the email.

        Both the text on the website and the contents of the email are identical, so the only information available is the identical text from the website or from developer emails. And that text was quite precisely and clearly worded: It said "we cannot rule out that some developer data was accessed". That's like me finding that the gate to my garden has been smashed in; at that point I cannot rule out that someone entered my house. If I find no evidence then I still cannot rule out that someone very clever entered

    • By "encrypted" they almost certainly mean, "credit card data is encrypted with a key that may or may not have been compromised as well" and "passwords were hashed". Password hashing doesn't achieve very much these days unless your password is unusually strong.

  • CNet reading comprehension (Score:5, Informative)

    by gnasher719 ( 869701 ) on Sunday July 21, 2013 @07:23PM (#44346217)
    Either these guys at CNet can't read, or they make it up as they go. CNet writes in its article "Apple says its developer site was targeted in an attack, and that any information that was taken was encrypted. ".

    No, that's not what Apple says. Apple didn't say any data was taken, encrypted or not. Apple said the data that was targetted (not the same as "taken") was "securely encrypted".

    • Cnet is actually correct. Any data taken was encrypted.

      In this case, you have to assume that data was taken. No "If ands or Buts about it". Data was taken. They just don't know what data.

      • 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

        • My developer info as an iOS developer includes my Apple ID and my password. The same ID and password for my iTunes account which is connected to my credit card. If my name and email was compromised, I'm not terribly worried. If my password was compromised, then my credit card was compromised, and that's a problem. --JSt

          • My developer info as an iOS developer includes my Apple ID and my password.

            Mine too.

            But that was not the system accessed, authentication is handled by a different system.

            Luckily Apple seems to compartmentalize some important systems, and that is one of them...

    • ibrahim Balic [techcrunch.com] is apparently responsible for the breach (by his own admission).

      • ibrahim Balic is apparently responsible for the breach (by his own admission).

        What a stupid cunt. He probably thinks it's Ok because he only took information from some developers (that's what he's claiming). Consider this: If you stole information about Google's or Facebook's Apple developer account from Apple's website, what are the chances that these companies sue your ass off?

      • Re: (Score:2)

        by Njovich ( 553857 )

        Wow, he might want to recheck the law if he thinks he is not breaking any laws. If Apple wants to play things hard, that's some serious jailtime he is looking at.

  • Data was encrypted? What a joke. This is web site, it has to have unencrypted data in memory to server any purpose. If Apple can access the data, so did the intruder.

    • Re: (Score:1)

      by Anonymous Coward

      No it doesn't. But thanks for playing.
      You can use SWIFFT, VSH or for being more casual : SHA-2.

      Hope you don't work in IT.

      • Re:Data was encrypted (Score:4, Insightful)

        by cbiltcliffe ( 186293 ) on Sunday July 21, 2013 @08: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.

        • Re: (Score:3)

          by bondsbw ( 888959 )

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

          But the OP said that encrypted data is a joke. This is a flat lie. We are talking about millions of encrypted or hashed passwords in a database, versus just a few that are plaintext in memory at any point in time.

          And depending on implementation, there are strategies for keeping the password in memory for absolutely as small of a time as possible, even to the point that only a byte or even fewer bits of the password are ever in memory at any given time.

          If you don't understand this... well, I'll quote someo

          • there are strategies for keeping the password in memory for absolutely as small of a time as possible, even to the point that only a byte or even fewer bits of the password are ever in memory at any given time.

            How do those strategies work when you're receiving the whole password at one time in a network packet?

            • Re: (Score:2)

              by bondsbw ( 888959 )

              The password is transmitted encrypted, and stays that way until you apply the decryption algorithm. The encrypted password is decrypted in a for loop, byte by byte, using the same memory address (so that the previous byte is overwritten each iteration).

              Now for this to work properly in theory, your comparison or hashing function must also be callable on a per-byte basis. This is usually not the case (and may open another can of worms if you tried), so in practice at some point, the point in which your hash

              • Re: (Score:2)

                by bondsbw ( 888959 )

                Oh, and another strategy is to have a separate server (or servers) dedicated to running the algorithm from password decryption through hash comparison. This server would never be supplied with the user ID, just the encrypted password and the stored hash. If either server had a rootkit (but not both), neither would have enough information to associate the user ID with the plaintext password.

                The problem here is that the rootkit could be sophisticated enough to rewrite the output, always returning "true" whe

                • Re: (Score:2)

                  by DarkOx ( 621550 )

                  Its not really that hard.

                  Store two salts for the client. The salt for the server side hash and a salt to be used by the client.

                  Server -> Client :$Logon page
                  Client -> Server :$username
                  Server -> Client :$client_salt
                  Client collects password from the use and hashes the password with $client_salt
                  Client -> Server: $hashed_password
                  Server hashes the $hashed_password with the server side salt and compares with its stored hash

                  Obviously this does nothing protect client from the credential being picked off

        • Re:Data was encrypted (Score:4, Insightful)

          by maccodemonkey ( 1438585 ) on Sunday July 21, 2013 @11:21PM (#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.

        • Re: (Score:1)

          by Anonymous Coward

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

          The password sent from the browser doesn't have to be in plaintext. It can be:

          1/ Sent via SSL [wikipedia.org]
              AND
          2/ Hashed before it's even sent via SSL [slashdot.org]

    • Data was encrypted? What a joke. This is web site, it has to have unencrypted data in memory to server any purpose.

      All the website has in memory when I visit is my name - not my email, or my physical address which are the two other items possibly accessed in this attack.

      There's no reason why it would have anything other than my name for any page besides my account information, which I pretty much never access. Even on a page that indicates I'm paying with an existing credit card only has a few digits of th

      • You know it it works: the web site has a connexion to the database where it can extract anything. If you manage to onject SQL statement, you own all the database. Indeed the database could have your specific data encrypted with your password as the key to decipher it. Or even better the database could do fine grained access control based on your credentials, but I never saw that done at big scale.

        • If you manage to onject SQL statement, you own all the database.

          You can get as far as that page allows for the credentials you are using... and only smaller systems have direct links from pages to a database, usually they are going through a back-end layer of some kind with no direct DB access.

          But in the end it proves my point, that none of that is in memory. You are going to the database one way or another to get whatever you can.

  • Why take the site down? (Score:3, Interesting)

    by Anonymous Coward on Sunday July 21, 2013 @09:20PM (#44346745)

    If the attacker didn't successfully get in why is Apple completely revamping the site? When I ran a small website it got attacked everyday, I can't even imagine how many people try to get into Apple's systems. So what's so different about this one? Something doesn't add up.

    • If the attacker didn't successfully get in why is Apple completely revamping the site? When I ran a small website it got attacked everyday, I can't even imagine how many people try to get into Apple's systems. So what's so different about this one? Something doesn't add up.

      You don't just "get in successfully". A good website has multiple protections, and Apple's developer website should be the most protected website ever. So someone got past one protection level. Most likely no success at all, but it means the defence is now weaker than before. Result: A complete revamp that closes the way to get past _one_ protection.

    • If the attacker didn't successfully get in why is Apple completely revamping the site?

      Because they had planned a revamp for the near future anyway? Isn't that how most revamps "happen"? Because something else goes wrong and the people in charge decide that going to the new system now not only fixes the problem but takes away the hassle of two downtimes?

  • The data was taken and was partially unencrypted (Score:5, Interesting)

    by Anonymous Coward on Sunday July 21, 2013 @09:50PM (#44346883)

    I have my own domain name, and suffice it to say it is unique. It is 8 characters and unless the attackers brute-forced my name and the domain name, data was definitely taken unencrypted. I have not published anything to the app store yet; my website doesn't talk about any apps. As far as anyone who develops for iPhones knows, my personal development account doesn't exist.

    Throughout the day Thursday I had 4 password reset attempts on this Apple ID. I immediately changed my password the legit way to something much stronger than I had it, but that's beside the point - there's really only two vectors for someone to have gotten my developer account info: through the Apple breach, through email harvesters, or through past business contacts (I have developed for other people, but not published under myself)

    Considering the timing, I think we can assume it was obtained through the Apple breach. I consider the data compromised. I'm going to go so far as re-generate ALL of my provisioning, etc. certificates and I advise anyone else to do so when the site comes back up.

  • Was just my email exposed to some more spam? Not so bad.
    Was my password exposed? That would suck as I hate remembering new ones but I use a different one for every site.
    The worst from a password exposure would be if they then log in and developer reject all my apps.
    Was my credit card exposed along with bits like the code on the back? That would suck but again I use a crap card for online stuff.
    Were my private app keys exposed which then probably opens my app to piracy? That would suck too.
    Was my ban

    • Was just my email exposed to some more spam? Not so bad.

      That was one of the items possibly leaked.

      Was my password exposed? That would suck as I hate remembering new ones but I use a different one for every site.

      That was not one of the items leaked, at least Apple claims not.

      Was my credit card exposed along with bits like the code on the back? That would suck but again I use a crap card for online stuff.

      That was definitely not one of the items leaked as any developer purchases go through the App Store fram

  • Shouldn't more sites go offline when hacked? (Score:4, Insightful)

    by SuperKendall ( 25149 ) on Sunday July 21, 2013 @11:49PM (#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.

    • For a site as complex as Apple's developer site, especially when they're hosting both ios6 *and* the new ios 7 (which includes both published, and unpublished versions - I'm pretty sure beta 4 was sitting there to be released) as well as all the PKI/cert stuff - yeah, it can be horribly complex. Probably no one on the security team and the dev/web team had any sleep over the past few days.

    • Re: (Score:1)

      by Anonymous Coward

      An interesting thing is that iTunes Connect -- which handles things like app submission and the various financial aspects (including contracts) -- uses the same name/password as the developer site, and hasn't been down at all. I've been using it regularly for the past week without a problem.

      • Re: (Score:1)

        by MassacrE ( 763 )

        The developer site doesn't authenticate the user; they redirect to another site for that.

  • Video about the download (Score:3, Interesting)

    by Anonymous Coward on Monday July 22, 2013 @12:26AM (#44347535)

    I've got to dash to work, but here goes the link to the video where he shows what he did.

    http://www.youtube.com/watch?v=q000_EOWy80

    ac

  • Weasle words (Score:4, Insightful)

    by L4t3r4lu5 ( 1216702 ) on Monday July 22, 2013 @02: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."

    • " 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."

      Even better: We're replacing our antiquated hardware, making software updates we've been putting off for months, and upgrading our RDBMS.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        " 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."

        Even better: We're replacing our antiquated hardware, making software updates we've been putting off for months, and upgrading our RDBMS.

        Or, as what

      • Re: (Score:2)

        by rossz ( 67331 )

        Even better: We're replacing our antiquated hardware, making software updates we've been putting off for months, and upgrading our RDBMS.

        Updating software on a bunch of servers is a pain in the ass, even with something like puppet. Dealing with the fallout of a breach because you didn't update your software in a timely manner is an even bigger pain in the ass and has the potential side effect of unemployment.

    • " 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."

      Our old system was using Java - well known to be full of holes. Of course we were preparing to replace the whole mess for quite some time now.

  • “Researcher” posts video of Apple intrusion, with user data in the video [2:50]: http://youtube.com/watch?v=q000_EOWy80 [youtube.com]

  • There is a TechCrunch article on the breach, and someone by the name of Ibrahim Balic is taking credit for the breach.
    What he wrote is below, and the link provided goes directly to the comment.

    Hi there,

    My name is ibrahim Balic, I am a security researcher. You can also search my name from Facebook's Whitehat List. I do private consulting for particular firms. Recently I have started doing research on Apple inc.

    In total I have found 13 bugs and have reported through http://bugreport.apple.com./ [bugreport.apple.com] The bugs are a

  • we're completely overhauling our developer systems, updating our server software, and rebuilding our entire database.

    how a security breach where no sensitive data was compromised requires a total database rebuild?
    how do you "completely overhaul" a developer system just hours after being compromised?
    how long do you plan to work "around the clock" on that? half a year? because that's about the minimum such a system update would require, wild guess.

    and how do you want to keep customer confidence with such blatant and unnecessary lies?
    duh, apple ...

  • I noticed the article is dated sunday.. well I only just now got notified on Monday evening.. it says "in the spirit of transparency, we're notifying you".. LONG after it's been all over the web, here, and other tech publications. A little late, maybe?

Slashdot Top Deals

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Close