Slashdot Mirror


Apple: Developer Site Targeted In Security Attack, Still Down

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

112 comments

  1. contact information out in the open by Anonymous Coward · · Score: 0, Interesting

    So is sensitive information only your credit card data?

  2. Interesting timing... by dottrap · · Score: 5, Interesting

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

    1. Re:Interesting timing... by scdeimos · · Score: 4, Interesting

      I was thinking the same thing. Yesterday Ubuntu, today Apple, tomorrow Microsoft?

    2. Re:Interesting timing... by ClaraBow · · Score: 4, Funny

      The Windows team must be doing early research for Windows 10 ;-)

    3. Re:Interesting timing... by icebike · · Score: 1

      Microsoft. Snort. Done.

      More likely the NSA installing more spyware backdoors.

      --
      Sig Battery depleted. Reverting to safe mode.
    4. Re:Interesting timing... by gnasher719 · · Score: 0

      More likely the NSA installing more spyware backdoors.

      Bloody idiot.

    5. Re:Interesting timing... by Desler · · Score: 2

      Except the Apple breach was on Thursday.

    6. Re:Interesting timing... by SuperKendall · · Score: 1

      I'm not sure that means much though, especially since Apple locked down the site perhaps they decided to move on - or it might have been the plan to hack the sites in succession.

      I can't figure out a good motive for hacking both sites though, unless the aim was to deface each site somehow. But it seems like in each case the attackers were after developer info, but why? I can't see much use for it.

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
    7. Re:Interesting timing... by Anonymous Coward · · Score: 0

      I was thinking the same thing. Yesterday Ubuntu, today Apple, tomorrow Microsoft?

      The day anyone cared enough to hack Microsoft has long passed, and even Apple is a dead man walking.

      'The average price of a smartphone has plunged to $375 from $450 since the beginning of 2012, IDC estimates. That drop has already threatened revenue growth and profit margins at Apple Inc. (AAPL)... “The days of great growth in the high end of the market are gone,” said Michael Morgan, an analyst at ABI Research. “It’s the Chinese companies who know how to survive on tiny margins that are ready for the fight that’s about to ensue.”'

    8. Re:Interesting timing... by Desler · · Score: 1

      It means that there is no pattern of "Yesterday Ubuntu, today Apple".

  3. Purpose of the attack by michelcultivo · · Score: 3, Interesting

    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

    1. Re: Purpose of the attack by s3cr3to · · Score: 1

      Don't forget: Ubuntu phone too. OMG

    2. Re: Purpose of the attack by Anonymous Coward · · Score: 0

      Who said their signing infrastructure was compromised?

      Even if it was, we know they can or do enforce a CRL, and signing systems are most likely to leave an auditable trail.

  4. Ohne Steve geht alles schief! by Anonymous Coward · · Score: 5, Funny

    This wouldn't have happened if Steve was still alive

    1. Re:Ohne Steve geht alles schief! by Anonymous Coward · · Score: 0

      Failing that, they also DON'T (!!!!) have the "proudly done in a mac" badge, which everybody knows makes you immune to such things (and gives you a bunch of other +1's).

  5. Mining expedition... by justcauseisjustthat · · Score: 1

    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)

    1. Re:Mining expedition... by Nerdfest · · Score: 2

      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.

    2. Re:Mining expedition... by H0p313ss · · Score: 2

      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.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
    3. Re:Mining expedition... by 93+Escort+Wagon · · Score: 1

      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.

      --
      #DeleteChrome
    4. Re:Mining expedition... by MysteriousPreacher · · Score: 1

      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.

      --
      -- Using the preview button since 2005
    5. Re:Mining expedition... by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Mining expedition... by Anonymous Coward · · Score: 0

      I say you have two systems, one obvious, one hidden. Just as if you were still living at home. You didn't want mama too see your porn did you?

    7. Re:Mining expedition... by MysteriousPreacher · · Score: 1

      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.

      --
      -- Using the preview button since 2005
  6. Which one? by Anonymous Coward · · Score: 2, Interesting

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

    1. Re:Which one? by Anonymous Coward · · Score: 0

      They could have just said we are doing maint if they didn't want to be transparent

    2. Re:Which one? by Anonymous Coward · · Score: 1

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

    3. Re:Which one? by Anonymous Coward · · Score: 0

      In the spirit of transparency, Apple told all of its users it was handing data directly to the NSA through PRISM.

      NOT!!!!!

      Transparent my ass.

  7. Re:Happy Sunday from The Golden Girls! by thinkingrodent · · Score: 2, Funny

    One Million Dollars! *strokes fluffy cat*

  8. The summary is wrong again... by gnasher719 · · Score: 2, Informative

    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.

    1. Re:The summary is wrong again... by Anonymous Coward · · Score: 0

      That's called click bait.

      Making up sensational, but rubbish headlines to bash Apple is the new sport for media.
      It causes an enormous amount of additional hits = money.
      It's food for all the Apple haters waiting gleefully for the next occasion to mindlessly show their idiocy and being completely uninformed.
      (see the Debian idiot one post above)

      See also the electrocuting headlines. (despite that just stupid people bought $1 death trap chargers putting through input voltage on the output. In the wet)

    2. Re:The summary is wrong again... by Maestro485 · · Score: 4, Informative

      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

    3. Re:The summary is wrong again... by Anonymous Coward · · Score: 0

      This is why I don't RTFA.
      If an article is interesting, I just go to other news sites and see if I can find it.
      No need for links from here to there.

    4. Re: The summary is wrong again... by Anonymous Coward · · Score: 0

      that is the sort of understatement you issue to satisfy the disclosure obligation set by EU, your law team or other body, while checking the true scale of the 'problem'

    5. Re:The summary is wrong again... by Anonymous Coward · · Score: 0

      I have a Mac developer license and I did not get this email.

    6. Re:The summary is wrong again... by gmanterry · · Score: 2

      I have a Mac developer license and I did not get this email.

      This is the email I got from Apple:

      Apple Developer Website Update

      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.

      --
      Since when is "public safety" the root password to the Constitution?
    7. Re:The summary is wrong again... by Anonymous Coward · · Score: 0

      I have a Mac developer license and I did not get this email.

      Same here. I have a free developer membership, and I didn't get the email. Maybe only people with a paid membership were in the part of Apple's database that was broken into.

      Do you have a free or paid membership?

    8. Re:The summary is wrong again... by IamTheRealMike · · Score: 1

      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.

    9. Re:The summary is wrong again... by Anonymous Coward · · Score: 0, Informative

      Which rock are you living under? Your precious master Apple is not special. All headlines are chosen by editors to bait people into reading the article.

      Also, I'm curious as to how you managed to find time to post this comment. I heard apple zealots are performing some weird gay orgy and cock-in-anus dance to make the site come back up. What happened ? Out of lube?

    10. Re:The summary is wrong again... by gnasher719 · · Score: 2

      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 my house; I can only rule out at that point that nobody stupid broke in. The alternative wording "some developer data may have been accessed" indicates a much higher likelihood. For example, if my patio door was unlocked I wouldn't say "I cannot rule out that someone entered", I would say "someone may have entered my house".

    11. Re:The summary is wrong again... by Anonymous Coward · · Score: 0

      And in case anyone is unsure, let's be clear. These fake chargers are dangerous. I've opened a few out of curiosity and found shockingly unsafe design. The problem is that counterfeits can look pretty convincing, and consumers aren't wondering why the prices are so low when compared to first party and chargers produced by legit third parties.

      Worst I saw was a charger that was nothing more than a minimal board, big capacitor and wires nowhere near the thickness required for carrying mains voltage. And of course, no grounding or fuse.

      For any electrical goods, people need to know the source and stop buying this cheap and dangerous stuff.

    12. Re:The summary is wrong again... by ecotax · · Score: 1

      I received this email on both accounts (work and private) that I have access to, so I guess they did indeed send it to developers with a paid membership.
      At the time, I was wondering if I wasn't being too paranoid to pay using a virtual prepaid credit card for my own account, but now I'm glad I did...

      --
      "Money is a sign of poverty." - Iain Banks
  9. CNet reading comprehension by gnasher719 · · Score: 4, Informative

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

    1. Re:CNet reading comprehension by fast+turtle · · Score: 1

      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.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    2. Re:CNet reading comprehension by Paradise+Pete · · Score: 1

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

    3. Re:CNet reading comprehension by gnasher719 · · Score: 1

      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?

    4. Re:CNet reading comprehension by Njovich · · Score: 1

      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.

  10. Data was encrypted by manu0601 · · Score: 1

    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.

    1. Re:Data was encrypted by Anonymous Coward · · Score: 1

      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.

    2. Re:Data was encrypted by cbiltcliffe · · Score: 3, Insightful

      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.

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
    3. Re:Data was encrypted by Anonymous Coward · · Score: 0

      Sure, the passwords are hashes but they didn't say passwords were stolen. They did say that account details and emails might have been which are definitely accessible on the server in free-text so that pages can be rendered.

    4. Re:Data was encrypted by bondsbw · · Score: 2

      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 someone we both can agree with:

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

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    5. Re:Data was encrypted by maccodemonkey · · Score: 3, Insightful

      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.

    6. Re:Data was encrypted by Anonymous Coward · · Score: 0

      If the password database was accessed of the developers, this means the password database for everyone that uses any kind of Apple product has been accessed, they use single signon.

      This means that they are probably talking about other personal/company information, such as bank account number, VAT number, different kind of addresses and contact information. They are saying this information is encrypted. However for a web application to show this information to the user when he want to edit this information, or for the application to put money in your account, it will need to have the keys to this encrypted information.

      So if a website is compromised, say they can change the code somehow (buffer overflow, injection attack) of the website, then the attacker can also access this information and decrypt it.

    7. Re:Data was encrypted by Anonymous Coward · · Score: 0

      Not only that, but his assertion that you need the data unencrypted on the server at some point is a gigantic lie. There are asymmetric handshake photocells for dealing with exactly this situation. Does he think your private key is transmitted every time you make a handshake with an SSH server bearing your public key?

      Honestly, it amazes me that the advice for websites is to use something like a hashing algorithm to store passwords, not some kind of public/private key handshake like SRP.

    8. Re:Data was encrypted by Anonymous Coward · · Score: 1

      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
          AND
      2/ Hashed before it's even sent via SSL

    9. Re:Data was encrypted by drinkypoo · · Score: 1

      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?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    10. Re:Data was encrypted by bondsbw · · Score: 2

      Honestly, it amazes me that the advice for websites is to use something like a hashing algorithm to store passwords, not some kind of public/private key handshake like SRP.

      This is bad advice! If the private key is compromised, the password or potentially the entire database of passwords is at risk. If a database of hashes were compromised, there is no key that could ever exist that could extract the original data, because that original data is destroyed in the process of hashing.

      That's not to say that hashing is perfect and needs no thought. Of course, you need to use a hash function that reduces the chance of a collision, and you need to make sure your database is not susceptible to rainbow table attacks. For passwords, it is crucial that you use a hashing algorithm designed for passwords with built-in salting and multiple iterations, such as scrypt or bcrypt.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    11. Re:Data was encrypted by bondsbw · · Score: 1

      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 hashing function is called, the entire password is in memory at once in order to be supplied as a parameter to the hash function. The main point is to reduce the time that it is in memory in unencrypted form, so as soon as that function returns, the password memory location should be overwritten.

      No such system is perfect against a rootkit. A rootkit could access all your encrypted passwords and call your decryption function. The point, I suppose, is to make it as difficult as possible. It can help to have N servers evaluating passwords so that the number of passwords ever in jeopardy by a single rootkit are the number checked while the rootkit exists divided by N.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    12. Re:Data was encrypted by bondsbw · · Score: 1

      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" when it sees a particular input (thus allowing an attacker to login as any user). But at least the password is never compromised, and if that same password is used in multiple systems, the other systems would remain safe.

      Moral of the story: don't get rootkits.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    13. Re:Data was encrypted by DarkOx · · Score: 1

      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 the wire, the hash effective is the password; but it does provide the client's user some protection if they have reused the password on other systems and the servers password file is stolen.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    14. Re:Data was encrypted by Anonymous Coward · · Score: 0

      Actually, you can transmit the hashed password if you hash it with JS. I do it all the time for my sites. And the JS has to be sitting on a separate server, fetched through https. It's till possible to inject yourself into that circuit to get the unhashed password, but it will be a lot harder (ie: you have to compromise root on the https server to serve custom JS). Being just a static file server, the https server can be pretty hardened.

      In essence, not sure what Apple did, but that you can make the plain password live only on the client machine, you can.

      Still, hashed password can be cracked as well. Google rainbow tables.

  11. Those Silly Researchers! by Anonymous Coward · · Score: 0

    Always trying to show how smart they are and expose weaknesses in the system so they can be fixed. It's purely for the good of Apple ya know.

  12. Why take the site down? by Anonymous Coward · · Score: 3, Interesting

    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.

    1. Re:Why take the site down? by Anonymous Coward · · Score: 0

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

      Uhhh... Because in order to have got to the stage of being considered an "attacker" rather than just some skiddy running a port scan, he'll need to have managed to get somewhere into the system. They didn't say he didn't get in – they said they don't know if he got data, and if he did, which data he got. As they now know of at least some security vulnerabilities in their system, they are making the server inaccessible to attackers until they make sure those vulnerabilities are taken care of.

    2. Re:Why take the site down? by gnasher719 · · Score: 1

      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.

    3. Re:Why take the site down? by Plumpaquatsch · · Score: 1

      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?

      --
      Of course news about a fake are Fake News.
  13. The data was taken and was partially unencrypted by Anonymous Coward · · Score: 5, Interesting

    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.

  14. What do I have to burn? by EmperorOfCanada · · Score: 1

    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 banking information exposed. That could mega suck. Either if they manage to redirect payments or just do something nasty to my account.
    Was all my contact info exposed? Along with my CC this would be the worst, as a scam artist could send an email/phone me, saying they that my apps were pulled from the store because of porn or something and that I could click HERE to contact Apple to protest. Even though I would be sure it is a scam and I would log in normally to check, my blood pressure would be up for a while.

    So I would say of the various exposures banking info would be the worst.

  15. No, it doesn't have to have that... by SuperKendall · · Score: 1

    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 the card, there's no reason to think anywhere it has the whole card number - and there's pretty much no Apple Developer page where you use you credit card anyway (payment for dev accounts is handled through the Apple Store transaction system).

    Also getting to data in memory is significantly harder. The data is far more transient my nature than the main database, and you'd have to figure out what data you could access per page.

    Basically the database itself is such a richer source of data it makes little sense to target the web pages themselves as served to customers.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:No, it doesn't have to have that... by manu0601 · · Score: 1

      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.

    2. Re:No, it doesn't have to have that... by SuperKendall · · Score: 1

      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.

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
  16. Cook Takes The Money And Walks by Anonymous Coward · · Score: 0

    So how much was the payoff from NSA (proceeds from the U.S.A. Department of Treasury and 'look the other way' from the IRS) to Cook for his 'sellout' of the Developers he loves so well?

    Inquiring minds are digging for the 'dirt' and the bodies.

  17. They know what - not who by SuperKendall · · Score: 2, Insightful

    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.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:They know what - not who by jds91md · · Score: 1

      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

  18. Very little of that exposed in developer portal by SuperKendall · · Score: 1

    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 framework, which was not breached.

    Were my private app keys exposed which then probably opens my app to piracy? That would suck too.

    There's really not anything anyone could do with these though. Apps can be pirated already without any of that information if you use a jailbroken phone, because it can be made not to check the application signing.

    You also can't build new enterprise apps locally to phish companies, because that requires a private key that is only held client side, Apple does not have it.

    Also Apple is not saying that was one of the items potentially leaked.

    Was my banking information exposed.

    Apple is not saying that's any of the data exposed, and the system that holds that (iTunes Connect) is not offline.

    Was all my contact info exposed?

    Again, possibly your email address and phone in encrypted form were taken... but anyone could find those out in other ways anyway.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  19. Shouldn't more sites go offline when hacked? by SuperKendall · · Score: 3, Insightful

    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.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Shouldn't more sites go offline when hacked? by the_B0fh · · Score: 1

      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.

    2. Re:Shouldn't more sites go offline when hacked? by Anonymous Coward · · Score: 1

      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.

    3. Re:Shouldn't more sites go offline when hacked? by MassacrE · · Score: 1

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

  20. Video about the download by Anonymous Coward · · Score: 3, Interesting

    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

    1. Re:Video about the download by Anonymous Coward · · Score: 0

      What a dumbass. I'm sure he'll enjoy continuing his "research" inside a prison cell.

  21. Poor choice of words by Anonymous Coward · · Score: 0

    "an intruder attempted to secure personal information"

    let me get this straight - the intruder tried to secure information that Apple left insecure - so it was a white hat attack?

  22. Weasle words by L4t3r4lu5 · · Score: 3, Insightful

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

    --
    Finally had enough. Come see us over at https://soylentnews.org/
    1. Re:Weasle words by drinkypoo · · Score: 1

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

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Weasle words by tlhIngan · · Score: 1

      " 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 normally happens, it's a pile of mishmash that developers put up and they found that old dusty Mac running MacOS classic was still serving up stuff long after people forgotten about it.

      Given it was a developer site, there's probably a lot more experimentation that goes on there (and Apple IT probably ended up leaving it up to the developers because they always protest when they have to follow dumb rules about paperwork and change orders). And face it, it happens - developers need to test some feature that they forget to notify IT about, and scramble to set up a test server that ends up being a production server inadvertently, and so forth.

      Methinks Apple IT at least kept some oversight to the "developers playground" to discover it and maintain at least some protection on the data. But now they're probably going through everything that developers touched and adding it to the IT database and centralized management system - no more "don't update that box!" excuses.

      And probably at the same time removing a bunch of crufty machines that were long forgotten about. Even though Apple probably has a good development/qa/test/production flow and line, developers always seem to try to want to circumvent the process and push to production directly.

    3. Re:Weasle words by Anonymous Coward · · Score: 0

      I interviewed with the team that manages and develops a large chunk of the Developer Center functionality.

      I can assure you that the site isn't being served up off a Mac SE sitting under someone's desk, and that they have pretty rigorous controls around the release of updates to the site.

      You may not like Apple, but they're nowhere near as stupid as you seem to think they are.

    4. Re:Weasle words by rossz · · Score: 1

      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.

      --
      -- Will program for bandwidth
    5. Re:Weasle words by Plumpaquatsch · · Score: 1

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

      --
      Of course news about a fake are Fake News.
  23. Re:The data was taken and was partially unencrypte by L4t3r4lu5 · · Score: 3, Funny

    two vectors

    through the Apple breach
    through email harvesters
    through past business contacts

    Please tell me you write accounting software.

    --
    Finally had enough. Come see us over at https://soylentnews.org/
  24. “Researcher” posts video of Apple intr by aggemam · · Score: 1

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

  25. Re:The data was taken and was partially unencrypte by ernest.cunningham · · Score: 1

    Correlation != causation.
    Otherwise, since throughout the day Thursday I had ZERO password reset attempts on my Apple ID we must assume that the data was not taken or was taken and not partially encrypted.

    Obviously both arguments are silly.

    (PS, like you I have written apps for other companies but have not published any under my own name).

  26. Reform IRS and Tax code by Anonymous Coward · · Score: 0

    Since corporations can simply write off "damage" (funny how they tally "potential business lost" time at peak sales rate) from their taxes, their's an incentive to fluff out expenses, isn't there? And what easier way to do that then to feign "computer attack" by "evil hackers11!!!11!!! "??

  27. Someone is taking credit for the hack/disruption by JRHelgeson · · Score: 1

    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./ The bugs are all reported one by one and Apple was informed. I gave details to Apple as much as I can and I've also added screenshots.

    One of those bugs have provided me access to users details etc. I immediately reported this to Apple. I have taken 73 users details (all apple inc workers only) and prove them as an example.

    4 hours later from my final report Apple developer portal gas closed down and you know it still is. I have emailed and asked if I am putting them in any difficulty so that I can give a break to my research. I have not gotten any respond to this... I have been waiting since then for them to contact me, and today I'm reading news saying that they have been attacked and hacked. In some of the media news I watch/read that whether legal authorities were involved in its investigation of the hack. I'm not feeling very happy with what I read and a bit irritated, as I did not done this research to harm or damage. I didn't attempt to publish or have not shared this situation with anybody else. My aim was to report bugs and collect the datas for the porpoise of seeing how deep I can go within this scope. I have over 100.000+ users details and Apple is informed about this. I didn't attempt to get the datas first and report then, instead I have reported first.

    I do not want my name to be in blacklist, please search on this situation. I'm keeping all the evidences, emails and images also I have the records of bugs that I made through Apple bug-report.

    http://techcrunch.com/2013/07/21/apple-confirms-that-the-dev-center-has-potentially-been-breached-by-hackers/?hubRefSrc=permalink#lf_comment=87472293
    Short URL: http://fyre.it/tjlVmC.4

    --
    Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
  28. Re: The data was taken and was partially unencrypt by Anonymous Coward · · Score: 0

    Are the password reset emails forgeries?

  29. Re:Someone is taking credit for the hack/disruptio by Anonymous Coward · · Score: 0

    Stupidest "researcher" in the world?

    "I broke in and took 100,000 users' data. But I maintain I stole nothing, broke in nowhere, and I have kept all of the copies of the data from my hack so I can prove I didn't hack anything."

    He won't have to wait much longer for them to contact him, I'm sure. Unfortunately, that contact will come in the form of the UK police slapping cuffs on him so he can be brought in for an extradition hearing.

  30. secure! by Anonymous Coward · · Score: 0

    I bet the encryption password was “guest”.

  31. Re:Happy Sunday from The Golden Girls! by Anonymous Coward · · Score: 0

    One Million Dollars! *strokes fluffy cat*

    You realize you are automatically taken as a complete idiot on Slashdot when you have some social network profile attached to your account, right? You fucking loser?

  32. so so ... by znrt · · Score: 1

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

    1. Re:so so ... by Anonymous Coward · · Score: 0

      how a security breach where no sensitive data was compromised requires a total database rebuild?

      That's some "How is babby formed" grade stupid right there. If you have a security breach, even if you know for a fact that no sensitive data was compromised, you don't ignore it. You fix it. Anything less would be irresponsible.

      how do you "completely overhaul" a developer system just hours after being compromised?

      You don't do it in mere hours? The site has been down for days, dumbass. Apple hasn't given a timeline for when it will be back up either.

      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.

      Like you'd have any fucking clue, you ignorant asswipe. Apple hasn't even specified what this "overhaul" entails. It's likely it's restricted to the portion of their system which got compromised, not the entire thing.

      Or, at least, that's the conclusion you'd arrive at if you assume that they're reasonable people. If, on the other hand, you have an axe to grind and not too many brain cells, you end up like Slashdot poster "znrt", shitting out nonsense like this:

      and how do you want to keep customer confidence with such blatant and unnecessary lies?

      What lies would those be, then?

    2. Re:so so ... by znrt · · Score: 1

      how a security breach where no sensitive data was compromised requires a total database rebuild?

      That's some "How is babby formed" grade stupid right there. If you have a security breach, even if you know for a fact that no sensitive data was compromised, you don't ignore it. You fix it. Anything less would be irresponsible.

      a "total database rebuild" is not a fix. why needs the entire database a total rebuild?

      how do you "completely overhaul" a developer system just hours after being compromised?

      You don't do it in mere hours? The site has been down for days, dumbass. Apple hasn't given a timeline for when it will be back up either.

      days! i wasn't aware of that, thanks. so they also prove themselves incapable of fixing the issue and restoring the service. but why does the system need a "complete overhaul" to continue the service? sounds a lot like a totally broken system to me.

      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.

      Like you'd have any fucking clue, you ignorant asswipe. Apple hasn't even specified what this "overhaul" entails. It's likely it's restricted to the portion of their system which got compromised, not the entire thing.

      Or, at least, that's the conclusion you'd arrive at if you assume that they're reasonable people. If, on the other hand, you have an axe to grind and not too many brain cells, you end up like Slashdot poster "znrt", shitting out nonsense like this:

      because they haven't specified anything at all. the whole statement is just braindead business babble. as you would naturally expect from any corporation, what else? when you fuck up in business you just don't admit it. you tell a fairy tale. ditto, lies. ok, not life-threatening lies. but lies. it's ugly. doesn't help confidence. unless you're a natural born apple customer, like you seem to be, of course.

  33. Apple didn't inform *every* developer.. by doccus · · Score: 1

    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?

  34. That was not accessed by SuperKendall · · Score: 1

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

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  35. My email was stolen from this attack by Anonymous Coward · · Score: 0

    I noticed that this morning and later today there are 2 separate attempt to reset my Apple ID password so I am fairly certain my ID/email was stolen from there as I once registered as a IOS developer.