×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple: Developer Site Targeted In Security Attack, Still Down

samzenpus posted about 9 months ago | from the protect-ya-neck dept.

Security 112

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

112 comments

Happy Sunday from The Golden Girls! (-1)

Anonymous Coward | about 9 months ago | (#44345973)

Thank you for being a friend
Traveled down the road and back again
Your heart is true, you're a pal and a cosmonaut.

And if you threw a party
Invited everyone you knew
You would see the biggest gift would be from me
And the card attached would say, thank you for being a friend.

Re:Happy Sunday from The Golden Girls! (-1)

Anonymous Coward | about 9 months ago | (#44346035)

How much is Apple paying you to troll this article?

Re:Happy Sunday from The Golden Girls! (3, Funny)

Ben Dibell (2852113) | about 9 months ago | (#44346147)

One Million Dollars! *strokes fluffy cat*

Re:Happy Sunday from The Golden Girls! (0)

Anonymous Coward | about 9 months ago | (#44353761)

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?

contact information out in the open (0, Interesting)

Anonymous Coward | about 9 months ago | (#44345979)

So is sensitive information only your credit card data?

Interesting timing... (5, Interesting)

dottrap (1897528) | about 9 months ago | (#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]

Re:Interesting timing... (4, Interesting)

scdeimos (632778) | about 9 months ago | (#44346017)

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

Re:Interesting timing... (2)

Desler (1608317) | about 9 months ago | (#44346365)

Except the Apple breach was on Thursday.

Re:Interesting timing... (1)

SuperKendall (25149) | about 9 months ago | (#44347725)

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.

Re:Interesting timing... (0)

Anonymous Coward | about 9 months ago | (#44348067)

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

Re:Interesting timing... (4, Funny)

ClaraBow (212734) | about 9 months ago | (#44346031)

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

Those Silly Researchers! (0)

Anonymous Coward | about 9 months ago | (#44346435)

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.

Purpose of the attack (3, Interesting)

michelcultivo (524114) | about 9 months ago | (#44346029)

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

Re: Purpose of the attack (0)

Anonymous Coward | about 9 months ago | (#44349965)

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.

Ohne Steve geht alles schief! (5, Funny)

Anonymous Coward | about 9 months ago | (#44346051)

This wouldn't have happened if Steve was still alive

Re:Ohne Steve geht alles schief! (0)

Anonymous Coward | about 9 months ago | (#44348153)

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

Mining expedition... (1)

justcauseisjustthat (1150803) | about 9 months ago | (#44346077)

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)

Re:Mining expedition... (2)

Nerdfest (867930) | about 9 months ago | (#44346505)

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.

Re:Mining expedition... (2)

H0p313ss (811249) | about 9 months ago | (#44346659)

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.

Re:Mining expedition... (1)

93 Escort Wagon (326346) | about 9 months ago | (#44347001)

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.

Re:Mining expedition... (1)

MysteriousPreacher (702266) | about 9 months ago | (#44348507)

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.

Re:Mining expedition... (1)

drinkypoo (153816) | about 9 months ago | (#44349041)

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.

Re:Mining expedition... (1)

MysteriousPreacher (702266) | about 9 months ago | (#44349655)

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.

Re:Mining expedition... (0)

Anonymous Coward | about 9 months ago | (#44349371)

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?

Which one? (2, Interesting)

Anonymous Coward | about 9 months ago | (#44346125)

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

Re:Which one? (0)

Anonymous Coward | about 9 months ago | (#44346199)

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

Re:Which one? (1)

Anonymous Coward | about 9 months ago | (#44346243)

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

Re:Which one? (0)

Anonymous Coward | about 9 months ago | (#44346531)

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.

yuo F4il It.. (-1)

Anonymous Coward | about 9 months ago | (#44346157)

for all practical that they sideline World will have endlees conflict anybody's guess study. [rice.e3u] and has instead share. *BSD is give other people practical purposes

It's funny because (-1)

Anonymous Coward | about 9 months ago | (#44346183)

that's what you get for being a shitty company with stupid un-users. Same goes for Ubuntu.

Let Darwin's prophecy unfold to its fullest extent, hail Debian !

The summary is wrong again... (2, Informative)

gnasher719 (869701) | about 9 months ago | (#44346193)

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... (0)

Anonymous Coward | about 9 months ago | (#44346279)

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)

Re:The summary is wrong again... (0)

Anonymous Coward | about 9 months ago | (#44346629)

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.

Re:The summary is wrong again... (0, Informative)

Anonymous Coward | about 9 months ago | (#44348609)

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?

Re:The summary is wrong again... (0)

Anonymous Coward | about 9 months ago | (#44348735)

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.

Re:The summary is wrong again... (4, Informative)

Maestro485 (1166937) | about 9 months ago | (#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]

Re:The summary is wrong again... (0)

Anonymous Coward | about 9 months ago | (#44347527)

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

Re:The summary is wrong again... (2)

gmanterry (1141623) | about 9 months ago | (#44347707)

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.

Re:The summary is wrong again... (0)

Anonymous Coward | about 9 months ago | (#44347909)

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?

Re:The summary is wrong again... (1)

ecotax (303198) | about 9 months ago | (#44348939)

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

Re:The summary is wrong again... (2)

gnasher719 (869701) | about 9 months ago | (#44348663)

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

Re: The summary is wrong again... (0)

Anonymous Coward | about 9 months ago | (#44347115)

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'

Re:The summary is wrong again... (1)

IamTheRealMike (537420) | about 9 months ago | (#44348171)

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 (4, Informative)

gnasher719 (869701) | about 9 months ago | (#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".

Re:CNet reading comprehension (1)

fast turtle (1118037) | about 9 months ago | (#44346269)

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.

They know what - not who (2, Insightful)

SuperKendall (25149) | about 9 months ago | (#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.

Re:CNet reading comprehension (1)

Paradise Pete (33184) | about 9 months ago | (#44347865)

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

Re:CNet reading comprehension (1)

gnasher719 (869701) | about 9 months ago | (#44348669)

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:CNet reading comprehension (1)

Njovich (553857) | about 9 months ago | (#44353343)

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 (1)

manu0601 (2221348) | about 9 months ago | (#44346433)

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:Data was encrypted (1)

Anonymous Coward | about 9 months ago | (#44346467)

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 (3, Insightful)

cbiltcliffe (186293) | about 9 months ago | (#44346593)

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:Data was encrypted (0)

Anonymous Coward | about 9 months ago | (#44346797)

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.

Re:Data was encrypted (2)

bondsbw (888959) | about 9 months ago | (#44347135)

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.

Re:Data was encrypted (0)

Anonymous Coward | about 9 months ago | (#44347559)

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.

Re:Data was encrypted (0)

Anonymous Coward | about 9 months ago | (#44347565)

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.

Re:Data was encrypted (2)

bondsbw (888959) | about 9 months ago | (#44349253)

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.

Re:Data was encrypted (1)

drinkypoo (153816) | about 9 months ago | (#44349031)

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:Data was encrypted (1)

bondsbw (888959) | about 9 months ago | (#44349441)

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.

Re:Data was encrypted (1)

bondsbw (888959) | about 9 months ago | (#44349587)

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.

Re:Data was encrypted (3, Insightful)

maccodemonkey (1438585) | about 9 months ago | (#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:Data was encrypted (1)

Anonymous Coward | about 9 months ago | (#44347809)

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]

No, it doesn't have to have that... (1)

SuperKendall (25149) | about 9 months ago | (#44347037)

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.

Why take the site down? (3, Interesting)

Anonymous Coward | about 9 months ago | (#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.

Re:Why take the site down? (0)

Anonymous Coward | about 9 months ago | (#44347581)

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.

Re:Why take the site down? (1)

gnasher719 (869701) | about 9 months ago | (#44347901)

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.

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

Anonymous Coward | about 9 months ago | (#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.

Re:The data was taken and was partially unencrypte (3, Funny)

L4t3r4lu5 (1216702) | about 9 months ago | (#44348091)

two vectors

through the Apple breach
through email harvesters
through past business contacts

Please tell me you write accounting software.

Re:The data was taken and was partially unencrypte (1)

ernest.cunningham (972490) | about 9 months ago | (#44348453)

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

Re: The data was taken and was partially unencrypt (0)

Anonymous Coward | about 9 months ago | (#44350221)

Are the password reset emails forgeries?

Apple security (-1)

Anonymous Coward | about 9 months ago | (#44346897)

What? Apple admitting security issues exist? Remarkable.

What do I have to burn? (1)

EmperorOfCanada (1332175) | about 9 months ago | (#44346961)

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.

Very little of that exposed in developer portal (1)

SuperKendall (25149) | about 9 months ago | (#44347383)

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.

Cook Takes The Money And Walks (0)

Anonymous Coward | about 9 months ago | (#44347079)

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.

Shouldn't more sites go offline when hacked? (3, Insightful)

SuperKendall (25149) | about 9 months ago | (#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.

Re:Shouldn't more sites go offline when hacked? (1)

the_B0fh (208483) | about 9 months ago | (#44347523)

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:Shouldn't more sites go offline when hacked? (1)

Anonymous Coward | about 9 months ago | (#44347961)

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:Shouldn't more sites go offline when hacked? (1)

MassacrE (763) | about 9 months ago | (#44348591)

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

Video about the download (3, Interesting)

Anonymous Coward | about 9 months ago | (#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

Re:Video about the download (0)

Anonymous Coward | about 9 months ago | (#44348497)

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

Poor choice of words (0)

Anonymous Coward | about 9 months ago | (#44347753)

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

Weasle words (3, Insightful)

L4t3r4lu5 (1216702) | about 9 months ago | (#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."

Re:Weasle words (1)

drinkypoo (153816) | about 9 months ago | (#44349021)

" 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:Weasle words (1)

tlhIngan (30335) | about 9 months ago | (#44351271)

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

Re:Weasle words (0)

Anonymous Coward | about 9 months ago | (#44351461)

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.

Re:Weasle words (1)

rossz (67331) | about 9 months ago | (#44353697)

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.

Reform IRS and Tax code (0)

Anonymous Coward | about 9 months ago | (#44349197)

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!!! "??

Someone is taking credit for the hack/disruption (1)

JRHelgeson (576325) | about 9 months ago | (#44350121)

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 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 [techcrunch.com]
Short URL: http://fyre.it/tjlVmC.4 [fyre.it]

Re:Someone is taking credit for the hack/disruptio (0)

Anonymous Coward | about 9 months ago | (#44351427)

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.

secure! (0)

Anonymous Coward | about 9 months ago | (#44353469)

I bet the encryption password was “guest”.

so so ... (1)

znrt (2424692) | about 9 months ago | (#44354109)

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

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...