14 ms·

How I Found a Vulnerability to Hack iCloud Accounts and How Apple Reacted to It

447 points by alexcos 5y ago

xvector 5y ago
Do companies want people to ignore responsible disclosure and/or sell these vulnerabilities on grey/black markets? I suspect they don't care in the end. The privacy/security stories are more there for marketing. End consumers won't know if the technicalities actually hold up in practice, so there's little incentive to run a tight and honest bounty program. Disgusting behavior by Apple.
- intricatedetail 5y ago
  Once you become too big to fail, an ability to ignore issues is one of the perks.
- anshumankmr 5y ago
  I don’t think it is good for Apple’s image if they have another iCloud leak disaster.
  - xvector 5y ago
    Oh, definitely, if another Fappening happens Apple's privacy story turns into a complete joke, which is why Apple's incompetence with regards to this bug bounty is particularly baffling.
peytn 5y ago
I would take the 18k for a brute force attack dude… that’s more than fair. People tend to already know when you can brute force stuff. > Rate limiting would be performed in the Apple server itself or in HSM (hardware security module). Either way, the rate limit logic should be programmed as such to prevent race hazard. There is very bleak chance for this endpoint to be not vulnerable to race hazard before my report because all the other endpoints I tested was vulnerable The HSMs they’re using at Apple aren’t patchable… that’s kinda the point. Sorry.
- laxmanmuthiyah 5y ago
  HSM is not handling the http requests directly. If you send an improper request data like not sending proper xml, you will see the errors from the iCloud server endpoint. The endpoint that is sending data to HSM could be patched to validate concurrent requests. Of course I may be missing something but we will never know the truth until Apple confirms it.
jtaft 5y ago
Good finds :). Most of 2 factor auth or password reset flows I came across while consulting had bugs. One of the more fun findings was an authenticated encrypted username was used for password resets. Another part of the application used the same encryption key and acted as an encryption oracle. Copy ciphertext for the target username into the password reset link, and voila.
ishiz 5y ago
Do these bug bounty programs usually take a year from submitting the report to being approved for a bounty?
- laxmanmuthiyah 5y ago
  Not every other program. I have seen apple bug bounty reports of others completed in a month or so. But I don't know what took so long for them in my case.
  - Leparamour 5y ago
    >But I don't know what took so long for them in my case. Patching of the vulnerability probably, so they could weasel out of paying the full bounty.
cantsingh 5y ago
How sophisticated the attack/exploit may be is not the point here. The salient point is that he demonstrated complete iCloud account takeover, and Apple lists that as a $100k bounty reward, but are only offering him $18k. Please correct me if there is something I'm missing.
- Magodo 5y ago
  The sophistication is relevant because he proves that the vulnerability he originally reported could take over any icloud account but he wasn't able to do so himself as it was patched between the time he first reported it and 8 months later when he tries it again. Apple then seems to refuse to acknowledge this and offers only 18K vs. 350K
  - rubatuga 5y ago
    It’s not that implausible that passcode hashing was rate limited.
  - marcan_42 5y ago
    He claims the vulnerability as originally reported could take over any iCloud account. Apple claimed otherwise. We do not have hard evidence from either side. However, given the implementation involved, I think Apple's claims are more likely, as I detail here; OP is assuming the stack used for the passcode recovery is likely vulnerable because the others were, while we know it is a completely different validation technology and, given how it works, I would expect it not to be vulnerable (unlike the web service stuff): https://news.ycombinator.com/item?id=27567730 https://news.ycombinator.com/item?id=27567730 My take on this is: 1) Apple are probably not lying when they say this wouldn't have worked on most accounts. 2) The author is likely wrong in his assumption that the passcode flow was vulnerable like the others were. 3) $18k is still way too low for an account takeover exploit that only affected a subset of accounts. 4) Apple are not being open about how this system works, and if I'm not mistaken, this is a new system/flow. 5) The author's discoveries aside, Apple need to document how this works, because as far as I can tell they are massively increasing the attack surface for the data security of iOS users who log in to their Apple accounts on-device, using a new, undocumented mechanism/use case.
yumraj 5y ago
To me this looks like a case of someone looking that this dude was based in India, doing a cost of living/Apple US-India salary comparison and coming up with a ratio of ~1:5 (for $100K) or ~1:14 (for $250K) and deciding that he would be happy with $18K.
- throwawaybchr 5y ago
  Yes I'm sure they price their MacBooks in India based on the same logic
- intricatedetail 5y ago
  This assumes a person doesn't travel. Often going on holiday to Europe will be more expensive to a person in India than in the US. This kind of thinking in Apple has racist connotations.
- vinay_ys 5y ago
  Cost of living indexation being applied to salary of a knowledge worker is a flawed economic thinking that is being perpetuated by some. Firstly, knowledge workers should be paid market competitive rates – and the definition of market in a digital economy is global. Secondly, cost of living index for a software engineer in India vs US is not that different - cost of electronics, housing, clothing, accessories, vacation/travel etc are all same. In some cases, things are more expensive due to global trade economics – for example cars/bikes, fuel, travel, luxury goods etc are way more expensive in India than US. Food and housekeeping was assumed to be cheaper – but that was based on flawed logic that someone is cooking food at home for you for free (an unemployed family member) and you are exploiting some poor person for housekeeping without caring about their healthcare or their children's education (these are basically un-costed externality that keeps poor families poor). In reality, today's generation of software engineers have to cook their own food (costs time which is learning opportunity cost which is nothing but money) or hire professional help (costs money) or eat catered food (which is possible due to app based delivery services in major cities like Bangalore, costs money) every day. Besides, no matter where you are living, only a small part of your paycheck goes towards non-discretionary expenses like basic food and basic shelter. A large part of your paycheck should be going towards future savings/investments and discretionary spending like leisure/travel and enhancing your quality of life through better nutrition/healthcare, continued education etc. None of these things cost less in India than US. Expecting Indian engineers to do this any less than US engineers is just another form of discrimination.
stirlo 5y ago
In the second half of the post he suggests remotely determining an iDevice passcode was possible with his rate limit bypass. Essentially a salted version of the devices passcode is uploaded to the apple server which he could then bypass the rate limit to brute force it. Isn't this a backdoor that would enable passcode bypass like was requested for the San Bernardino and Pensacola shooters phones? This vulnerability is a massive deal. With the passcode determined there's nothing stopping bad actors surreptitiously access your data. After all this a $2,180,000,000,000 market cap company offers a reward of $18,000. What a disgrace!
- rubatuga 5y ago
  Yeah, the “Your password is encrypted and cannot be read by Apple” is a bold faced lie. This can definitely be used to crack a passcode. Log out of iCloud if possible. I made a mini series on self hosting my cloud services here: https://www.naut.ca/blog/tag/shs/ https://www.naut.ca/blog/tag/shs/
  - kevin_nisbet 5y ago
    I'm not sure it's really fair to say it's a bold faced lie. It's been awhile since I looked at SRP, but it looks like server side only require storage of Username, Salt, Verifier in it's database according to http://srp.stanford.edu/design.html http://srp.stanford.edu/design.html Unless I'm missing something this is really an artifact of allowing a user to use a short pin on the device, but also because this short pin is allowed to be used somehow as part of the password recovery flow which as such requires properties to prevent brute force. Unless I'm missing something, choosing an alphanumeric pin of sufficient length would avoid this and be difficult to brute force. So it would seem the guarentee's are weaker than expected due to this, but I doubt it's a bold faced lie. Unless I'm missing something of course.
    - marcan_42 5y ago
      The point is SRP is no different, in this context, from storing a standard password hash. You can brute force the passcode if you have access to the verification material on the server. Apple's device security model relies on rate- and attempt-limiting unlock attempts, so that people can in fact use short numeric passcodes. Their on-device model is carefully designed to make it very hard to bypass this. The problem is now they have extended that model and attack surface to their HSM clusters. That's 1) not Apple hardware (I trust Apple hardware more than I trust the third-party HSMs they use), 2) not (only) Apple code (again I have less trust in HSM frameworks than Apple's), 3) shared for many users, so break one HSM cluster and you get to bruteforce a lot of passcodes, 4) strangely not documented in Apple's Platform Security Guide, which is very suspicious.
alexashka 5y ago
This is how you turn someone with good intentions into someone who'll choose to get paid and fuck the rest next time. Well done Apple.
- deleted 5y ago
  [deleted]
AnonC 5y ago
> If you do not have a paid Apple Developer Account, please sign up at <our site>, pay the membership fee and send us the associated Developer ID. You can’t make this stuff up! It’s completely and utterly ridiculous that even when you do get a bounty, they’ll take a cut from it. Leave aside the fact that some stingy hands found a way to devalue a person’s contributions to their platforms by offering a tiny fraction as a reward. I didn’t understand the later parts of this post well, but the correspondence frequency and the way this has been handled is a mark of shame to all the information security folks working at Apple. P.S.: I intentionally put <our site> instead of the actual link. That site doesn’t deserve to be linked in this context.
- rmkrmk 5y ago
  > Once all steps are complete, we will reimburse you the cost of creating this account. Seems they'll refund the paid account, still a weird thing to do.
  - deleted 5y ago
    [deleted]
  - camkego 5y ago
    They are saying, in effect, you must sign/agree to our 81-page developer agreement to receive the reward.
    - sneak 5y ago
      Lots of bug bounties are really just hush money, that you have to sign an NDA to get. Always just publish your research. You can optionally offer it privately to the affected party in advance, but don't agree to any TOSes to do free work. Full disclosure is responsible, too.
      - Leparamour 5y ago
        I assume lots of bug hunters (especially those from third world countries or those currently unemployed) depend on the bounty money to support their livelihoods.
miles 5y ago
Just 6 blog posts prior, the author was writing about "How To Create A Blog On Bluehost In 3 Simple Steps".[1] While admittedly that was 3 years ago, still quite an impressive feat of leveling up! [1] https://thezerohack.com/create-blog-bluehost https://thezerohack.com/create-blog-bluehost
- justshowpost 5y ago
  Seems like he was already hacking around on Facebook in 2015 [1] [1] https://thezerohack.com/how-i-hacked-your-facebook-photos https://thezerohack.com/how-i-hacked-your-facebook-photos
  - ergwwrt 5y ago
    $18k this time. $12.5k last time. Seems like this is his range
    - cantsingh 5y ago
      He got 30k from Instagram for the exact same concurrent bruteforce attack on their password reset flow.
justshowpost 5y ago
Why are the Security Departments of ever company so unfriendly? I feel like every blog post of a disclosed vulnerability has had some form or another of: - no replies - delayed replies - vague replies - playing down the vulnerability - reducing the bounty It’s like they still treat a white hat hacker as a risk, instead o cooperating with them. I don’t get the corporations. The white hat hacker is in this case your best friend. They proved their ethics already by reporting it to them, and they know it already because they found it. There is literally no reason to try to keep the white hat hacker in the dark, not update them, etc. The white hat hacker could have exploited the vulnerability already!
- beermonster 5y ago
  I found and reported a security issue to Microsoft. They responded nearly right away and it was a real person . I was soon talking directly to the right team to explain it to. I provided assets required to replicate and they jumped right on it and fixed it. They even told me what KB* it was resolved in via follow up email. I didn’t want any kind of monetary reward - just happy to have it fixed. I regularly report security issues in open source projects too. Now, I also once tried to report a fairly serious issue that impacted iOS and MacOS X (at the time) and you’d have thought (naively) they’d have been super interested and helpful as Microsoft were. Wrong. In fact their first response basically meant I never ended up getting past their first auto reply.
  - dandanua 5y ago
    That's a superiority complex. It can be seen especially well in Russia. I've read stories that their companies even start legal actions against white hackers that submit vulnerabilities to them.
    - contriban 5y ago
      This sounds like it happens a lot everywhere outside large American companies. The reasoning probably goes like “why were you even trying to break in, that’s illegal.”
chris_wot 5y ago
All Apple have done here is ensure that if an account take over or information disclosure vulnerability is found in the future, nobody will trust they will get paid the expected bug bounty. Congrats, Apple. You just helped increase the chance that researchers sell very bad exploits to state-sanctioned attackers, and you won’t ever know about it.
curiousgal 5y ago
I mean honestly if money is what you're after, you should go to the dark market directly. You don't owe these corporations shit. And their consistent haggling with people who responsibly disclose vulns is proof of that.
- Leparamour 5y ago
  Who's to say that the specific dark market isn't run/infiltrated by the FBI or other LEAs?
amelius 5y ago
I wonder how much he had to pay to use those 28k IP addresses.
- ergwwrt 5y ago
  Any idea how I can even go about acquiring this many IPs?
  - mdaniel 5y ago
    So long as your method is able to travel through HTTP, https://duckduckgo.com/?q=residential+proxy&ia=web https://duckduckgo.com/?q=residential+proxy&ia=web are quite prolific. I have heard more than one time that those exit points are why a lot of VPNs are "free of charge" I also recognize that it might take some additional effort to ensure subsequent requests exit from different IPs, but given the number of vendors in that space, I would guess it's not ludicrous, either
tumblewit 5y ago
It seems that the author found a vulnerability in the iCloud password reset that could have potentially allowed you to not only gain access to an iCloud account but also the passcode of a device. The reason why I think Apple decided not to give him a combined 350,000$ bounty is because from my understanding he didn’t actually realise the severity of what he found initially to exploit it and provide a proof of concept and so his bug bounty claim was limited to what he found initially and then Apple patched it (not a coincidence really) before anyone could do anything more. As a result now he wants the full bounty but Apple has decided to come to a random number as bounty. It’s easy to see why. Apple doesn’t want the bad PR from the fact that some random enthusiast found a way to compromise both iCloud and passcode of an iPhone without even having the targets physical device (insert Hollywood movie scene) and the fact that Apple with all their might may be vulnerable to something like this. On the other hand the author is pissed he did not fully exploit it in the first place and claim the full bounty by maybe showing a proof of concept and tried to be the good guy.
- ElViajero 5y ago
  > Apple doesn’t want the bad PR from the fact that some random enthusiast found a way to compromise both iCloud and passcode of an iPhone It is always problematic to do free work for big corporations. Corporations have an incentive to create "competitions" and similar "challenges" were many people participate doing free work, as they find nothing, and they can still under-pay the few that find something. Can you even imagine the cost for Apple/Amazon/Google/... if they had to find all this problems by themselves? Can you see the amount of free labor that they get? I found this free work justified for open source, like Linux, as everybody profits from it. It is a contribution to society. To fix big corporation problems in your spare time, only causes security experts salary to go down, as you are doing the job for free.
  - TheOtherHobbes 5y ago
    Can you even imagine the cost to Apple/Amazon/Google if the white hat community decides these companies have no ethics or integrity, so why not just go black hat instead? I have no idea what the dark market rate is for hacking a high profile iCloud account, but I'd be very surprised if it's less than $18k.
ldjb 5y ago
This isn't directly related to the article, but does anyone know of any good resources or best practices on how to report a vulnerability? A few days ago I discovered a pretty major vulnerability on a certain website, but security isn't the focus of my day job and I wasn't sure where to begin and what to keep in mind. The author of this article had some problems with the disclosure process; maybe there are best practices that could avoid these. I found the OWASP cheat sheet [0] really useful, but other than that, I didn't find too many other relevant resources. The vulnerability I reported has now been fixed, but I'm still pondering whether to publish the details or if it would just stir up unnecessary trouble. So it would be good to have resources that will help inform my decision. I think a lot of people who want to report vulnerabilities probably feel like they don't know what they're doing, and they probably don't feel very well supported through the disclosure process. At least, that's my experience. [0] https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability...
- mdaniel 5y ago
  I would think any general contact form that merely opens the conversation would be reasonable (mailto:hello@example.com?subject=how+to+contact+your+security+team) as would checking the major bounty websites for a listing -- not that you would be shopping for the bounty, but because that's where a receptive audience would already be listening for such reports As for whether to publish a fixed vuln, I would guess that boils down to whether you value the blog traffic and any commentary enough to wade into that. In my mental model, so long as your research was your own, then you generated that content and have every right to talk about it, perhaps even inspiring other non-traditional security researchers to try their hand, too
neximo64 5y ago
Apple is right, if you login with an iPhone, or iOS the device is upgraded to not use SMS verification anymore. While the author of the article has found something its not anywhere as serious as they think. The second part of the article with the on device based codes vs sms where 29/30 requests didn't work before was most likely that way before they found the vulnerability. It is upsetting not to get the $100k but the post comes off a bit as a lash out against that.
- Anunayj 5y ago
  I agree. This is a sorry situation to see, and neither of parties seem correct here. $18k is seems a little lowballing for a vulnerability that does actually work on a subset of iCloud accounts. and provides a method to bypass 2FA. At the same time the person lashing at Apple for handling seems quite unprofessional. In a perfect world a issue like this would be solved with better communication by both parties.
josefresco 5y ago
Looked at another way: Bad guys now know this guy has talent, they also know Apple ripped him off, what’s to stop them from making… a better offer? Apple probably thinks they’re protected themselves but if this guy “turns” the entire industry is at risk due to Apple’s thrift.
MauranKilom 5y ago
I still don't understand what the author means with his exploits (also against Instagram[0]) involving a race condition. A race condition means that something unexpected happens when you do something concurrently. Not "it gives the same result as when done one by one, but we're doing it faster" (which is what the author appears to be doing). It has to be different from the result any sequential operation could achieve. They used a few thousand IPs to hammer an endpoint, staying below the per-IP rate limit. Did it matter that this was done during the same time from all the IPs? If yes, it's not clear from the blog post how/why it mattered. If no (i.e. the result is the same when first completing all requests from the first IP, then the second, etc.), then it is not a race condition - just concurrency. [0]: https://thezerohack.com/hack-any-instagram https://thezerohack.com/hack-any-instagram
- Closi 5y ago
  The race condition he was referring to might be that if you go fast enough at making requests, you can make more requests than the request limit.
- PufPufPuf 5y ago
  From my understanding, there is a hard limit on how many attempts are allowed for entering the code for a specific account, regardless of the IP address. You can bypass that limit by sending all the attempts concurrently at once. The multiple IP addresses were used to bypass a different limit (a limit on concurrent connections).
- md_ 5y ago
  A slightly more detailed answer than the other two you got: It's likely a well-designed password (or similar) validation endpoint will both limit attempts per IP and per user, to avoid exactly the attack you describe. This limit probably isn't permanent (though I think the design of Apple's HSM may be different here; too many attempts may lock or delete user data entirely?). Rather, it would be something like "allow 5 attempts per hour per user." So, first, even if the attacker only exploits concurrency to speed things up--which implies the limits are only per IP--they can conduct attacks which are otherwise infeasible. (E.g. with 10k IPs at 5 attempts per hour per IP, they can brute force a six digit PIN in an average of an hour, as opposed to over a year.) But second, what I think the attacker is describing is actually worse: he's saying that the quota "counter" is updated with a "read-modify-write pattern that's not safe for concurrent HTTP requests, so that you might have something like: [request 0] read counter value = 0 [request 1] read counter value = 0 [request 0] set counter value = 1 [request 1] set counter value = 1 In this error, the counter is never incremented at all. It's easy to imagine people making this mistake when they store the counter in something that does not support transactional updates.
gizmo 5y ago
We see, time and time again, password recovery systems getting exploited. Aside from Apple's shitty response to the brute force vulnerabilities discovered here, I'm also annoyed that Apple isn't nearly as paranoid as they ought to be about the security of what is likely to be the #1 hacker target in their system. Instead of using a 6 digit 2 factor key, they could easily use 12 character alphanumeric key. That's (20 + 10) ** 12 / (10 ** 6) = 500 billion times harder to brute force. And honestly, is having to type 12 characters such a burden for the exceptional case of a password reset? I don't think so. Building secure systems is hard, I get that. I've made dumb mistakes myself. But Apple's iCloud contains people's locations, their photos, where they live, their email, notes and other secrets, and iCloud also circumvents all Apple's on-device encryption. It's fundamentally a system that sacrifices security for convenience, and it really sucks that all the real and serious security efforts made by other teams at Apple are negated by iCloud. There are many people, myself included, who use password managers and who will never ever lose their full disk encryption keys, passwords, or recovery keys. I don't want backdoors. I don't want forgot-my-password systems. I want to opt out of all of it.
- Black101 5y ago
  6 digit is perfectly fine if you only give one try before requiring a different code?
  - gizmo 5y ago
    It's a truism that secure things are secure. But engineers make mistakes and that's why you need layers of defense. And when you use recovery codes that are in the realm that can be brute forced you automatically have a problem when rate limiting or other anti-brute force measures fail. Which is why using stronger 2factor codes should be the default, especially for super high impact things like password recovery.
    - Black101 5y ago
      > And honestly, is having to type 12 characters such a burden for the exceptional case of a password reset? I don't think so. If those "engineers" need minimum of 26 characters 1-time use passwords that can only be used one time to feel secure, I don't trust those engineers (unless they allow me to copy and paste it). A one-time-use 6 digit password that can only be tried once is pretty damn secure if it is random.
mabbo 5y ago
It's dangerous to get this kind of publicity. What happens the next time a security researcher finds a way to bypass Apple? They'll find this post and ask themselves "who is going to pay me more, Apple or the NSA?".
renonce 5y ago
While it feels HN to hate any companies that didn't do security "right", I think what Apple says makes total sense here. At least, the author claims that under his assumptions, his exploit would have worked and affected a majority of iCloud accounts, but it won't. You can't claim that you found a vulnerability without actually demonstrating it. Key takeaway from Apple: > They concluded that the only way to brute force the passcode is through brute forcing the Apple device which is not possible due to the local system rate limits. The author did not understand that sentence accurately: > There is very bleak chance for this endpoint to be not vulnerable to race hazard before my report because all the other endpoints I tested was vulnerable – SMS code validation, email code validation, two factor authentication, password validation was all vulnerable. How I interpret that sentence is that, while other forms of verification are done on the server and thus subject to the vulnerability, the passcode verification is done on the device. When you send a passcode from another device, it is sent to the server and then routed to the device storing the passcode to perform the verification. Apple's servers do not store the hash throughout the process, and no form of brute force would have worked against the server. Instead, they are routed to the device storing the passcode, say iPhone, and the iPhone's HSM performs the verification. It's the HSM doing the rate limit here, and thus it's not subject to the vulnerability.

447 points by alexcos 5y ago

Do companies want people to ignore responsible disclosure and/or sell these vulnerabilities on grey/black markets? I suspect they don't care in the end. The privacy/security stories are more there for marketing. End consumers won't know if the technicalities actually hold up in practice, so there's little incentive to run a tight and honest bounty program. Disgusting behavior by Apple.

intricatedetail 5y ago
Once you become too big to fail, an ability to ignore issues is one of the perks.
anshumankmr 5y ago
I don’t think it is good for Apple’s image if they have another iCloud leak disaster.
- xvector 5y ago
  Oh, definitely, if another Fappening happens Apple's privacy story turns into a complete joke, which is why Apple's incompetence with regards to this bug bounty is particularly baffling.

peytn 5y ago

I would take the 18k for a brute force attack dude… that’s more than fair. People tend to already know when you can brute force stuff. > Rate limiting would be performed in the Apple server itself or in HSM (hardware security module). Either way, the rate limit logic should be programmed as such to prevent race hazard. There is very bleak chance for this endpoint to be not vulnerable to race hazard before my report because all the other endpoints I tested was vulnerable The HSMs they’re using at Apple aren’t patchable… that’s kinda the point. Sorry.

laxmanmuthiyah 5y ago
HSM is not handling the http requests directly. If you send an improper request data like not sending proper xml, you will see the errors from the iCloud server endpoint. The endpoint that is sending data to HSM could be patched to validate concurrent requests. Of course I may be missing something but we will never know the truth until Apple confirms it.

jtaft 5y ago

Good finds :). Most of 2 factor auth or password reset flows I came across while consulting had bugs. One of the more fun findings was an authenticated encrypted username was used for password resets. Another part of the application used the same encryption key and acted as an encryption oracle. Copy ciphertext for the target username into the password reset link, and voila.

ishiz 5y ago

Do these bug bounty programs usually take a year from submitting the report to being approved for a bounty?

laxmanmuthiyah 5y ago
Not every other program. I have seen apple bug bounty reports of others completed in a month or so. But I don't know what took so long for them in my case.
- Leparamour 5y ago
  >But I don't know what took so long for them in my case. Patching of the vulnerability probably, so they could weasel out of paying the full bounty.

cantsingh 5y ago

How sophisticated the attack/exploit may be is not the point here. The salient point is that he demonstrated complete iCloud account takeover, and Apple lists that as a $100k bounty reward, but are only offering him $18k. Please correct me if there is something I'm missing.

Magodo 5y ago
The sophistication is relevant because he proves that the vulnerability he originally reported could take over any icloud account but he wasn't able to do so himself as it was patched between the time he first reported it and 8 months later when he tries it again. Apple then seems to refuse to acknowledge this and offers only 18K vs. 350K
- rubatuga 5y ago
  It’s not that implausible that passcode hashing was rate limited.
- marcan_42 5y ago
  He claims the vulnerability as originally reported could take over any iCloud account. Apple claimed otherwise. We do not have hard evidence from either side. However, given the implementation involved, I think Apple's claims are more likely, as I detail here; OP is assuming the stack used for the passcode recovery is likely vulnerable because the others were, while we know it is a completely different validation technology and, given how it works, I would expect it not to be vulnerable (unlike the web service stuff): https://news.ycombinator.com/item?id=27567730 https://news.ycombinator.com/item?id=27567730 My take on this is: 1) Apple are probably not lying when they say this wouldn't have worked on most accounts. 2) The author is likely wrong in his assumption that the passcode flow was vulnerable like the others were. 3) $18k is still way too low for an account takeover exploit that only affected a subset of accounts. 4) Apple are not being open about how this system works, and if I'm not mistaken, this is a new system/flow. 5) The author's discoveries aside, Apple need to document how this works, because as far as I can tell they are massively increasing the attack surface for the data security of iOS users who log in to their Apple accounts on-device, using a new, undocumented mechanism/use case.

yumraj 5y ago

To me this looks like a case of someone looking that this dude was based in India, doing a cost of living/Apple US-India salary comparison and coming up with a ratio of ~1:5 (for $100K) or ~1:14 (for $250K) and deciding that he would be happy with $18K.

throwawaybchr 5y ago
Yes I'm sure they price their MacBooks in India based on the same logic
intricatedetail 5y ago
This assumes a person doesn't travel. Often going on holiday to Europe will be more expensive to a person in India than in the US. This kind of thinking in Apple has racist connotations.
vinay_ys 5y ago
Cost of living indexation being applied to salary of a knowledge worker is a flawed economic thinking that is being perpetuated by some. Firstly, knowledge workers should be paid market competitive rates – and the definition of market in a digital economy is global. Secondly, cost of living index for a software engineer in India vs US is not that different - cost of electronics, housing, clothing, accessories, vacation/travel etc are all same. In some cases, things are more expensive due to global trade economics – for example cars/bikes, fuel, travel, luxury goods etc are way more expensive in India than US. Food and housekeeping was assumed to be cheaper – but that was based on flawed logic that someone is cooking food at home for you for free (an unemployed family member) and you are exploiting some poor person for housekeeping without caring about their healthcare or their children's education (these are basically un-costed externality that keeps poor families poor). In reality, today's generation of software engineers have to cook their own food (costs time which is learning opportunity cost which is nothing but money) or hire professional help (costs money) or eat catered food (which is possible due to app based delivery services in major cities like Bangalore, costs money) every day. Besides, no matter where you are living, only a small part of your paycheck goes towards non-discretionary expenses like basic food and basic shelter. A large part of your paycheck should be going towards future savings/investments and discretionary spending like leisure/travel and enhancing your quality of life through better nutrition/healthcare, continued education etc. None of these things cost less in India than US. Expecting Indian engineers to do this any less than US engineers is just another form of discrimination.

stirlo 5y ago

In the second half of the post he suggests remotely determining an iDevice passcode was possible with his rate limit bypass. Essentially a salted version of the devices passcode is uploaded to the apple server which he could then bypass the rate limit to brute force it. Isn't this a backdoor that would enable passcode bypass like was requested for the San Bernardino and Pensacola shooters phones? This vulnerability is a massive deal. With the passcode determined there's nothing stopping bad actors surreptitiously access your data. After all this a $2,180,000,000,000 market cap company offers a reward of $18,000. What a disgrace!

rubatuga 5y ago
Yeah, the “Your password is encrypted and cannot be read by Apple” is a bold faced lie. This can definitely be used to crack a passcode. Log out of iCloud if possible. I made a mini series on self hosting my cloud services here: https://www.naut.ca/blog/tag/shs/ https://www.naut.ca/blog/tag/shs/
- kevin_nisbet 5y ago
  I'm not sure it's really fair to say it's a bold faced lie. It's been awhile since I looked at SRP, but it looks like server side only require storage of Username, Salt, Verifier in it's database according to http://srp.stanford.edu/design.html http://srp.stanford.edu/design.html Unless I'm missing something this is really an artifact of allowing a user to use a short pin on the device, but also because this short pin is allowed to be used somehow as part of the password recovery flow which as such requires properties to prevent brute force. Unless I'm missing something, choosing an alphanumeric pin of sufficient length would avoid this and be difficult to brute force. So it would seem the guarentee's are weaker than expected due to this, but I doubt it's a bold faced lie. Unless I'm missing something of course.
  - marcan_42 5y ago
    The point is SRP is no different, in this context, from storing a standard password hash. You can brute force the passcode if you have access to the verification material on the server. Apple's device security model relies on rate- and attempt-limiting unlock attempts, so that people can in fact use short numeric passcodes. Their on-device model is carefully designed to make it very hard to bypass this. The problem is now they have extended that model and attack surface to their HSM clusters. That's 1) not Apple hardware (I trust Apple hardware more than I trust the third-party HSMs they use), 2) not (only) Apple code (again I have less trust in HSM frameworks than Apple's), 3) shared for many users, so break one HSM cluster and you get to bruteforce a lot of passcodes, 4) strangely not documented in Apple's Platform Security Guide, which is very suspicious.

alexashka 5y ago

This is how you turn someone with good intentions into someone who'll choose to get paid and fuck the rest next time. Well done Apple.

deleted 5y ago
[deleted]

AnonC 5y ago

> If you do not have a paid Apple Developer Account, please sign up at <our site>, pay the membership fee and send us the associated Developer ID. You can’t make this stuff up! It’s completely and utterly ridiculous that even when you do get a bounty, they’ll take a cut from it. Leave aside the fact that some stingy hands found a way to devalue a person’s contributions to their platforms by offering a tiny fraction as a reward. I didn’t understand the later parts of this post well, but the correspondence frequency and the way this has been handled is a mark of shame to all the information security folks working at Apple. P.S.: I intentionally put <our site> instead of the actual link. That site doesn’t deserve to be linked in this context.

rmkrmk 5y ago
> Once all steps are complete, we will reimburse you the cost of creating this account. Seems they'll refund the paid account, still a weird thing to do.
- deleted 5y ago
  [deleted]
- camkego 5y ago
  They are saying, in effect, you must sign/agree to our 81-page developer agreement to receive the reward.
  - sneak 5y ago
    Lots of bug bounties are really just hush money, that you have to sign an NDA to get. Always just publish your research. You can optionally offer it privately to the affected party in advance, but don't agree to any TOSes to do free work. Full disclosure is responsible, too.
    - Leparamour 5y ago
      I assume lots of bug hunters (especially those from third world countries or those currently unemployed) depend on the bounty money to support their livelihoods.

miles 5y ago

Just 6 blog posts prior, the author was writing about "How To Create A Blog On Bluehost In 3 Simple Steps".[1] While admittedly that was 3 years ago, still quite an impressive feat of leveling up! [1] https://thezerohack.com/create-blog-bluehost https://thezerohack.com/create-blog-bluehost

justshowpost 5y ago
Seems like he was already hacking around on Facebook in 2015 [1] [1] https://thezerohack.com/how-i-hacked-your-facebook-photos https://thezerohack.com/how-i-hacked-your-facebook-photos
- ergwwrt 5y ago
  $18k this time. $12.5k last time. Seems like this is his range
  - cantsingh 5y ago
    He got 30k from Instagram for the exact same concurrent bruteforce attack on their password reset flow.

justshowpost 5y ago

Why are the Security Departments of ever company so unfriendly? I feel like every blog post of a disclosed vulnerability has had some form or another of: - no replies - delayed replies - vague replies - playing down the vulnerability - reducing the bounty It’s like they still treat a white hat hacker as a risk, instead o cooperating with them. I don’t get the corporations. The white hat hacker is in this case your best friend. They proved their ethics already by reporting it to them, and they know it already because they found it. There is literally no reason to try to keep the white hat hacker in the dark, not update them, etc. The white hat hacker could have exploited the vulnerability already!

beermonster 5y ago
I found and reported a security issue to Microsoft. They responded nearly right away and it was a real person . I was soon talking directly to the right team to explain it to. I provided assets required to replicate and they jumped right on it and fixed it. They even told me what KB* it was resolved in via follow up email. I didn’t want any kind of monetary reward - just happy to have it fixed. I regularly report security issues in open source projects too. Now, I also once tried to report a fairly serious issue that impacted iOS and MacOS X (at the time) and you’d have thought (naively) they’d have been super interested and helpful as Microsoft were. Wrong. In fact their first response basically meant I never ended up getting past their first auto reply.
- dandanua 5y ago
  That's a superiority complex. It can be seen especially well in Russia. I've read stories that their companies even start legal actions against white hackers that submit vulnerabilities to them.
  - contriban 5y ago
    This sounds like it happens a lot everywhere outside large American companies. The reasoning probably goes like “why were you even trying to break in, that’s illegal.”

chris_wot 5y ago

All Apple have done here is ensure that if an account take over or information disclosure vulnerability is found in the future, nobody will trust they will get paid the expected bug bounty. Congrats, Apple. You just helped increase the chance that researchers sell very bad exploits to state-sanctioned attackers, and you won’t ever know about it.

curiousgal 5y ago

I mean honestly if money is what you're after, you should go to the dark market directly. You don't owe these corporations shit. And their consistent haggling with people who responsibly disclose vulns is proof of that.

Leparamour 5y ago
Who's to say that the specific dark market isn't run/infiltrated by the FBI or other LEAs?

amelius 5y ago

I wonder how much he had to pay to use those 28k IP addresses.

ergwwrt 5y ago
Any idea how I can even go about acquiring this many IPs?
- mdaniel 5y ago
  So long as your method is able to travel through HTTP, https://duckduckgo.com/?q=residential+proxy&ia=web https://duckduckgo.com/?q=residential+proxy&ia=web are quite prolific. I have heard more than one time that those exit points are why a lot of VPNs are "free of charge" I also recognize that it might take some additional effort to ensure subsequent requests exit from different IPs, but given the number of vendors in that space, I would guess it's not ludicrous, either

tumblewit 5y ago

It seems that the author found a vulnerability in the iCloud password reset that could have potentially allowed you to not only gain access to an iCloud account but also the passcode of a device. The reason why I think Apple decided not to give him a combined 350,000$ bounty is because from my understanding he didn’t actually realise the severity of what he found initially to exploit it and provide a proof of concept and so his bug bounty claim was limited to what he found initially and then Apple patched it (not a coincidence really) before anyone could do anything more. As a result now he wants the full bounty but Apple has decided to come to a random number as bounty. It’s easy to see why. Apple doesn’t want the bad PR from the fact that some random enthusiast found a way to compromise both iCloud and passcode of an iPhone without even having the targets physical device (insert Hollywood movie scene) and the fact that Apple with all their might may be vulnerable to something like this. On the other hand the author is pissed he did not fully exploit it in the first place and claim the full bounty by maybe showing a proof of concept and tried to be the good guy.

ElViajero 5y ago
> Apple doesn’t want the bad PR from the fact that some random enthusiast found a way to compromise both iCloud and passcode of an iPhone It is always problematic to do free work for big corporations. Corporations have an incentive to create "competitions" and similar "challenges" were many people participate doing free work, as they find nothing, and they can still under-pay the few that find something. Can you even imagine the cost for Apple/Amazon/Google/... if they had to find all this problems by themselves? Can you see the amount of free labor that they get? I found this free work justified for open source, like Linux, as everybody profits from it. It is a contribution to society. To fix big corporation problems in your spare time, only causes security experts salary to go down, as you are doing the job for free.
- TheOtherHobbes 5y ago
  Can you even imagine the cost to Apple/Amazon/Google if the white hat community decides these companies have no ethics or integrity, so why not just go black hat instead? I have no idea what the dark market rate is for hacking a high profile iCloud account, but I'd be very surprised if it's less than $18k.

ldjb 5y ago

This isn't directly related to the article, but does anyone know of any good resources or best practices on how to report a vulnerability? A few days ago I discovered a pretty major vulnerability on a certain website, but security isn't the focus of my day job and I wasn't sure where to begin and what to keep in mind. The author of this article had some problems with the disclosure process; maybe there are best practices that could avoid these. I found the OWASP cheat sheet [0] really useful, but other than that, I didn't find too many other relevant resources. The vulnerability I reported has now been fixed, but I'm still pondering whether to publish the details or if it would just stir up unnecessary trouble. So it would be good to have resources that will help inform my decision. I think a lot of people who want to report vulnerabilities probably feel like they don't know what they're doing, and they probably don't feel very well supported through the disclosure process. At least, that's my experience. [0] https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability...

mdaniel 5y ago
I would think any general contact form that merely opens the conversation would be reasonable (mailto:hello@example.com?subject=how+to+contact+your+security+team) as would checking the major bounty websites for a listing -- not that you would be shopping for the bounty, but because that's where a receptive audience would already be listening for such reports As for whether to publish a fixed vuln, I would guess that boils down to whether you value the blog traffic and any commentary enough to wade into that. In my mental model, so long as your research was your own, then you generated that content and have every right to talk about it, perhaps even inspiring other non-traditional security researchers to try their hand, too

neximo64 5y ago

Apple is right, if you login with an iPhone, or iOS the device is upgraded to not use SMS verification anymore. While the author of the article has found something its not anywhere as serious as they think. The second part of the article with the on device based codes vs sms where 29/30 requests didn't work before was most likely that way before they found the vulnerability. It is upsetting not to get the $100k but the post comes off a bit as a lash out against that.

Anunayj 5y ago
I agree. This is a sorry situation to see, and neither of parties seem correct here. $18k is seems a little lowballing for a vulnerability that does actually work on a subset of iCloud accounts. and provides a method to bypass 2FA. At the same time the person lashing at Apple for handling seems quite unprofessional. In a perfect world a issue like this would be solved with better communication by both parties.

josefresco 5y ago

Looked at another way: Bad guys now know this guy has talent, they also know Apple ripped him off, what’s to stop them from making… a better offer? Apple probably thinks they’re protected themselves but if this guy “turns” the entire industry is at risk due to Apple’s thrift.

MauranKilom 5y ago

I still don't understand what the author means with his exploits (also against Instagram[0]) involving a race condition. A race condition means that something unexpected happens when you do something concurrently. Not "it gives the same result as when done one by one, but we're doing it faster" (which is what the author appears to be doing). It has to be different from the result any sequential operation could achieve. They used a few thousand IPs to hammer an endpoint, staying below the per-IP rate limit. Did it matter that this was done during the same time from all the IPs? If yes, it's not clear from the blog post how/why it mattered. If no (i.e. the result is the same when first completing all requests from the first IP, then the second, etc.), then it is not a race condition - just concurrency. [0]: https://thezerohack.com/hack-any-instagram https://thezerohack.com/hack-any-instagram

Closi 5y ago
The race condition he was referring to might be that if you go fast enough at making requests, you can make more requests than the request limit.
PufPufPuf 5y ago
From my understanding, there is a hard limit on how many attempts are allowed for entering the code for a specific account, regardless of the IP address. You can bypass that limit by sending all the attempts concurrently at once. The multiple IP addresses were used to bypass a different limit (a limit on concurrent connections).
md_ 5y ago
A slightly more detailed answer than the other two you got: It's likely a well-designed password (or similar) validation endpoint will both limit attempts per IP and per user, to avoid exactly the attack you describe. This limit probably isn't permanent (though I think the design of Apple's HSM may be different here; too many attempts may lock or delete user data entirely?). Rather, it would be something like "allow 5 attempts per hour per user." So, first, even if the attacker only exploits concurrency to speed things up--which implies the limits are only per IP--they can conduct attacks which are otherwise infeasible. (E.g. with 10k IPs at 5 attempts per hour per IP, they can brute force a six digit PIN in an average of an hour, as opposed to over a year.) But second, what I think the attacker is describing is actually worse: he's saying that the quota "counter" is updated with a "read-modify-write pattern that's not safe for concurrent HTTP requests, so that you might have something like: [request 0] read counter value = 0 [request 1] read counter value = 0 [request 0] set counter value = 1 [request 1] set counter value = 1 In this error, the counter is never incremented at all. It's easy to imagine people making this mistake when they store the counter in something that does not support transactional updates.

gizmo 5y ago

We see, time and time again, password recovery systems getting exploited. Aside from Apple's shitty response to the brute force vulnerabilities discovered here, I'm also annoyed that Apple isn't nearly as paranoid as they ought to be about the security of what is likely to be the #1 hacker target in their system. Instead of using a 6 digit 2 factor key, they could easily use 12 character alphanumeric key. That's (20 + 10) ** 12 / (10 ** 6) = 500 billion times harder to brute force. And honestly, is having to type 12 characters such a burden for the exceptional case of a password reset? I don't think so. Building secure systems is hard, I get that. I've made dumb mistakes myself. But Apple's iCloud contains people's locations, their photos, where they live, their email, notes and other secrets, and iCloud also circumvents all Apple's on-device encryption. It's fundamentally a system that sacrifices security for convenience, and it really sucks that all the real and serious security efforts made by other teams at Apple are negated by iCloud. There are many people, myself included, who use password managers and who will never ever lose their full disk encryption keys, passwords, or recovery keys. I don't want backdoors. I don't want forgot-my-password systems. I want to opt out of all of it.

Black101 5y ago
6 digit is perfectly fine if you only give one try before requiring a different code?
- gizmo 5y ago
  It's a truism that secure things are secure. But engineers make mistakes and that's why you need layers of defense. And when you use recovery codes that are in the realm that can be brute forced you automatically have a problem when rate limiting or other anti-brute force measures fail. Which is why using stronger 2factor codes should be the default, especially for super high impact things like password recovery.
  - Black101 5y ago
    > And honestly, is having to type 12 characters such a burden for the exceptional case of a password reset? I don't think so. If those "engineers" need minimum of 26 characters 1-time use passwords that can only be used one time to feel secure, I don't trust those engineers (unless they allow me to copy and paste it). A one-time-use 6 digit password that can only be tried once is pretty damn secure if it is random.

mabbo 5y ago

It's dangerous to get this kind of publicity. What happens the next time a security researcher finds a way to bypass Apple? They'll find this post and ask themselves "who is going to pay me more, Apple or the NSA?".

renonce 5y ago

While it feels HN to hate any companies that didn't do security "right", I think what Apple says makes total sense here. At least, the author claims that under his assumptions, his exploit would have worked and affected a majority of iCloud accounts, but it won't. You can't claim that you found a vulnerability without actually demonstrating it. Key takeaway from Apple: > They concluded that the only way to brute force the passcode is through brute forcing the Apple device which is not possible due to the local system rate limits. The author did not understand that sentence accurately: > There is very bleak chance for this endpoint to be not vulnerable to race hazard before my report because all the other endpoints I tested was vulnerable – SMS code validation, email code validation, two factor authentication, password validation was all vulnerable. How I interpret that sentence is that, while other forms of verification are done on the server and thus subject to the vulnerability, the passcode verification is done on the device. When you send a passcode from another device, it is sent to the server and then routed to the device storing the passcode to perform the verification. Apple's servers do not store the hash throughout the process, and no form of brute force would have worked against the server. Instead, they are routed to the device storing the passcode, say iPhone, and the iPhone's HSM performs the verification. It's the HSM doing the rate limit here, and thus it's not subject to the vulnerability.