Live data from Hacker News

Apple Developer Website Update

news.ycombinator.com

171–180 of 223 posts

Re: Apple Developer Website Update

#171
Here's my semi-educated guess for how the attack started: from casual observation (view source, URLs ending with .action, etc) a good chunk of the ADC is written in Java and uses WebWork/Struts2, a framework I helped create years ago.

Late last week a security advisory came out that allows for executing malicious code[1]. Atlassian, which uses similar technology, also issued announcements around the same time[2]. My wild speculation is this was the attack vector.

Sadly, I feel some responsibility for this pretty major security hole. There have been a few like this and they are all rooted in the fact that almost 9 years ago I made the (bad) decision to use OGNL as WebWork's expression language. I did so because it was "powerful" but it opened up all sorts of extra binding trickery I never intended. I haven't been contributing to the project in 5+ years, but this is a good reminder how technology choices tend to stick around a lot longer than you ever imagine :)

[1] http://struts.apache.org/release/2.3.x/docs/s2-016.html [2] https://confluence.atlassian.com/display/BAMBOO/Bamboo+Secur...

Re: Apple Developer Website Update

#173
There is an interesting comment at techcrunch:

http://fyre.it/tjlVmC.4

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

Re: Apple Developer Website Update

#174
post #92

Earlier quoted context omitted.

As I interpreted it, yes, the intruder does have your encrypted data.

I hope you were using good encryption Apple. This guy cracked 400,000 md5 hashed passwords: http://www.youtube.com/watch?v=0WPny7wk960 He says even with password salts, it could be done.

I could crack your unsalted md5 password with my Gameboy Color.

Re: Apple Developer Website Update

#175

Earlier quoted context omitted.

By "sensitive personal information" they probably just mean passwords and credit card information, not names, email addresses and mailing addresses.

Passwords could be hashed, but credit-cards are the big one you have to keep in plaintext. If you want to bill the card without asking for the number to be reentered, there's no way to avoid storing the number and expiration date. PCI does mandate that you keep less than necessary to initiate a new charge, though: you are not allowed to store the 3-digit verification code from the back of the card. Future charges fro…

> Future charges from the same vendor can go through based on the stored information (without re-sending the verification code), but charges from a new vendor would need the code, so this is intended to make it harder for someone who stole the saved information to initiate a new charge.

That's not true >"charges from a new vendor would need the code". Online credit card transactions only require a credit card number, expiry month & expiry year. The verification code is optional and is used as a fraud check / deterrent. Payments with an invalid verification code are highly suspicious. Therefore, when Apple (or any merchant) asks for the verification code initially, it passes the initial fraud tests and the card is stored as a "verified card" (or perhaps, only verified cards are stored). Further charges are then most probably legitimate (since it passed the previous fraud check).

Re: Apple Developer Website Update

#176

Earlier quoted context omitted.

What use would changing passwords be if passwords weren't stolen? If you think having your email address out there means you are at higher risk of being attacked, I've got news for you...

They said sensitive information is encrypted and can't be accessed, my interpretation of that is that the plain text can't be accessed but attackers may have the encrypted sensitive information (eg passwords). Depending on the strength of their encryption though, and the key used etc etc.. it might be perfectly accessible. In the absense of transparency on actual encryption details, you're probably better off assumin…

"Depending on the strength of their encryption though, and the key used"

I trust that Apple is competent when it comes to encryption at this point. I agree that the statement was ambiguous as to whether the data was actually taken.

Re: Apple Developer Website Update

#177

There is an interesting comment at techcrunch: http://fyre.it/tjlVmC.4 "[...] 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 an…

Looks like Apple is using Google Web Toolkit, those are GWT RPC responses. He probably found an CSRF attack.

Re: Apple Developer Website Update

#178

Earlier quoted context omitted.

Purchases of developer memberships are handled through Apple's online store. And that is still up.

There also is the bank account information for apple created payments to the developers... that could be part of the compromised items.

That is in iTunes Connect, completely separate from the developer portal.

Re: Apple Developer Website Update

#179

Earlier quoted context omitted.

The thing that people are getting annoyed at is Apple are claiming this update to be in the name of transparency, even though it's 3 days late and is worded quite poorly. >Most companies don't even tell you anything happened Seeing as you're confident with the "most companies" part, name me 5 big tech companies that suffered a data breach and didn't tell the public, or were forced to. There are laws you know, about i…

You can't have it both ways. They were transparent. Complaining that it was 3 days after the incident is irrelevant since we don't know how much investigation was required for them to understand the problem.

>You can't have it both ways.

Why not? See: Ubuntuforums

>we don't know how much investigation was required for them to understand the problem.

I agree, but i find it hard to believe a company the size of Apple, with the talented force that they have, couldn't have identified that they might've been breached, within 3 days.

3 days.

Post reply on HN