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.'"
Interesting timing. Wonder if it was related/coordinated to the Ubuntu forums attacks.
http://it.slashdot.org/story/13/07/21/0318243/ubuntuforumsorg-hacked
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
http://www.michel.eti.br
This wouldn't have happened if Steve was still alive
Spirit of transparency or because there is an entire site down without any other reason?
One Million Dollars! *strokes fluffy cat*
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.
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".
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.
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......
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
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.
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.
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.
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.
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
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
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
" 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/
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/
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.