How I Found a Vulnerability to Hack iCloud Accounts and How Apple Reacted to It
thezerohack.com
thezerohack.com
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.
Seems they'll refund the paid account, still a weird thing to do.
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.
Companies should be trying really hard to avoid this happening by offering better rewards with less hoops to jump through.
For the first few years the company will be considered a level just above common criminals. After a few while, they will be considered an essential consumer protection service.
It’s not something to rely on at all.
In most bug bounty programs I've seen (including Apple's and Facebook's) payouts are contingent on not publishing the research without consent.
That literally sounds like a Nigerian email scam.
Pointing out that Apple follows the law, like every other company, isn’t whataboutism. In any event, Apple pays its taxes in America. The manoeuvres are on its foreign income.
'apple follows the law like every other'
you are saying 'but apple isnt the only one, whatabout'
when the companies get to make the laws, they dont also then get to hide behind them as a shield.
Oh right, Linux on Desktop lost. Stop trying to make Linux on Desktop a thing.
Of course, that's just my N+1 anecdata. I've been using Linux on my main PC for two years now without much issue, but ymmv.
I still chase these issues for server dist upgrades, but at least I don't have to do for my desktop.
Dependency management utterly sucks in Linux. I can still run windows 98 binaries on win10.
> I still chase these issues for server dist upgrades
Yeah, I don't doubt it. Full OS upgrades are always dangerous, as proven by the Windows 8 -> Windows 10 install fiasco or the Catalina wipes. LTS distros tend to get ~5-6 years of support though, so it's not like you're going to be forced to reinstall for another few years.
Linux, Windows and MacOS are all different flavors of the same shitshow. I can assure you that package/dependency management is not one of Linux's shortcomings, relative to it's competitors.
What the hell? That's one of the biggest things desktop Linux got really right! Sure older binaries don't work but you shouldn't be flinging binaries around anyway.
With Apple and Microsoft effectively abandoning their desktop OSes it's very likely that Linux will become the dominant desktop OS even among non-tech-literate users.
Apple and Microsoft "abandoning" their desktop OSes is a dubious claim at best but in a magical world where they did, their "non-tech-literate users" wouldn't flock to Linux, they'd be happy they don't have to restart their computer for updates as often anymore. Non-techie people aren't going to move to a new OS except when they get a new computer. Even when they get a new computer they're just going to use the pre-installed OS. This is a fantasy.
These things have inertia. People who don't know computers aren't arbitrarily just going to decide to switch to a new OS where they have to relearn everything and their software doesn't work and there are moderately more driver incompatibilities that cause errors that confuse them. It's just not going to happen.
All it had to do to "win" was be available to those who wanted it, which was the case. Mobile Linux is no different and in that sense it's definitely winning now.
Did you just stop reading the post at the line you quoted, and came straight here to moan? They refund it. It's how they verify your identity and banking information.
This particular comment would be just fine without the swipe. We're trying for a different sort of internet here, if possible.
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!
I made a mini series on self hosting my cloud services here: https://www.naut.ca/blog/tag/shs/
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.
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.
This is a bad assumption to make, because the device passcode recovery flow is going through an iCloud Keychain HSM cluster, which is a completely different implementation from everything else (which are just web services). In fact, it is well-documented that Apple cannot update the underlying code of their HSM clusters, as they destroy the management cards after initial provisioning. So they can't have actually fixed this bug if it existed prior to his report. That code was surely audited much more carefully, and depends on a much smaller technology stack, than all the web service stuff, and certainly handles rate-limiting within the HSM itself.
So I have no reason to believe that this flow was vulnerable to the rate limit bypass race condition like the others.
However, we have a different problem now.
I called it the iCloud Keychain HSM cluster because, as documented, that whole thing is used for iCloud Keychain escrow (i.e. password store in the cloud). That's an opt-in feature. More info here:
https://support.apple.com/guide/security/escrow-security-for...
I did not know this, but apparently if your account has 2FA, the code used for this is indeed your device passcode, which smells dodgy to me:
https://support.apple.com/en-am/guide/security/secdeb202947/...
But still, the context is iCloud Keychain.
But now Apple are claiming this flow, which does not have the problem OP discovered, is used for all Apple accounts that have logged in from a passcode-protected iOS device. This implies that they are re-using this system, originally designed for the very narrow use case of (and trade-offs that necessarily come with) iCloud Keychain, as a general account recovery mechanism for all Apple accounts. That does, in fact, mean that they have (the ability to brute-force) the device passcode of everyone who has ever logged in their device.
That's bad. The HSM cluster stuff makes this hard, but it is a huge change in attack surface. It means that your device data security now not only depends on on-device software and hardware design (and Apple are famously good at this), but also the security of an HSM cluster at Apple HQ. It means that if you manage to break into a given HSM cluster, you can then brute force the passcodes for all users managed by it. And it means that if the HSMs have a vulnerability, that is a massive liability. The HSMs are third-party, and I honestly trust HSM manufacturers much less than Apple themselves when it comes to building secure systems.
So I would very much like to know what's going on here, whether that flow really does work on all accounts regardless of whether you use iCloud Keychain or not, and why none of this is documented in the Platform Security Guide. Does the hard 10-attempt limit used for iCloud Keychain escrow recovery also apply here, or can you continue trying PIN codes forever subject only to rate-limiting? Is this the same codebase or a different one? There are many questions here, and Apple's vague answers and lack of documentation for this make it sound like something very fishy is going on here.
HSM manufacturers are essentially selling security, so any security issue could destroy their business, whereas Apple would likely survive.
I have seen pentests being done on an HSM and the steps they go to are quite impressive. Far further than I would ever have expected.
1. They're all closed-source, super-expensive devices that security researchers don't look at in any numbers.
2. We know getting security right is extremely difficult; products from big, sophisticated, motivated companies have security problems revealed by careful public scrutiny. A product that hasn't received such scrutiny seems unlikely to be better than that.
3. The first and biggest customer for obscure security hardware like TPMs and Smart Cards is the government/military. In my country, government/military tech efforts have a reputation for being delivered late and over budget; often ending in failure; and not being particularly secure. Are we to believe defence contractors managed to do a competent IT project when they couldn't do that before or after?
4. We know, from examples like Dual EC DRBG and Crypto AG, that governments will happily put in a backdoor when given the chance. If a giant defence contractor like Thales was asked by their number 1 customer to put in a backdoor, do you think they'd say no?
- Infineon and ROCA. We know the code audits the industry does are superficial and do not catch the worst bugs. That code would've been a big red flag for real cryptographers, and it would've been quickly found had it been open source.
- Government requirements. Stuff like FIPS certification decreases security by increasing bureaucracy and complexity. See vulnerabilities affecting only the YubiKey FIPS for an example. These certifications hold the industry back by mandating compliance with large suites of algorithms, forbidding newer, better cryptography, and stuff like that.
- The general culture of that industry. They sell security, and they are all about audits. Those audits are about ticking boxes. They do not measure good design, overall defense in depth, or anything like that. They are bullet point lists of security features and specific attack models. Interesting attacks use novel approaches, and those audits are completely worthless at determining whether a system is likely to be designed in a way to be robust against new attacks or not.
As I mentioned, I saw a pentest happening, that included physical, network, software, pretty much anything that could be done over months.
Issues like the Debian OpenSSL issues show that something being open source does not mean it's getting the scrutiny it needs, and while open source software is easier to apply that scrutiny to, I think the relationship is far more complicated than that.
If a defence contractor like Thales was asked to put a backdoor in, do you think that wouldn't be found if their device was tested for months on end by external testers paid to, and motivated by, finding vulnerabilities.
I'm not saying it doesn't happen, but I do think they deserve a little more credit than you may be giving them.
There are many ways to design a back door that would pass such security audits, yes.
One option is to simply give the auditors a device without the back door - or a firmware listing without it.
You can also create bugs that are undetectable by black box testing - such as generating keys with insufficient entropy.
Another is to copy subtle bugs from other products, that sat in plain sight for years.
And of course the testers will all be under NDA so if they do find your back door, they’ve already promised to take part in your cover-up.
I think it's highly likely that Apple was being honest and that the HSM service was not vulnerable to this attack. That's consistent (as you say) with this being a separate, highly-audited implementation, and frankly consistent with what Apple said--and to save, what, $200k, they have no real reason to lie to a researcher here.
To your second point, while this is indeed a big change in attack surface, I am not sure it's as problematic as you say. Doesn't the iCloud backup basically contain (for most users) all of the device contents--photos, messages, etc--that an attacker would want? Conversely, users want to be able to restore their iCloud backups from a new i-device if they lose their existing one, ideally without having to know more than the lockscreen PIN.
Given that, the two systems--the cloud system and the i-device--are storing mostly-identical data, offering mostly the same security guarantees (hardware-backed key derivation from a weak PIN, rate limiting), and the only issue is that this is just a second hardware security module that's separate from the one in the i-device.
For users who have turned off cloud backup, this might be a bad tradeoff. (Maybe turning off cloud backup turns off the HSM/PIN syncing?) But for most users, the gain in usability seems likely to far outweigh the hypothetical additional risk.
But if you want to download apps at all from the App Store you need to sign in, and if that alone gives Apple the ability to verify your device PIN even without iCloud, that's a problem.
Certainly it does increase attack surface, but if Apple said “now I-devices ship with 2 HSMs”, we’d be like, ok, shrug. No?
The fact that this is “remote” is sort of immaterial, I think. You’re trusting Apple’s (bespoke or acquired) stack the same either way, and as far as we can tell the security properties of both local and remote HSMs are the same.
I do in fact trust the SEP more than I trust cloud HSM, because the SEP is an Apple design, and the HSMs they use, as far as I know, are third-party.
I think if this excluded users who turned off iCloud sync, I'd have no qualms about it, however; the tradeoffs seem ideal for giving users a secure recovery mechanism. But users who have turned off iCloud may not want this functionality, I agree.
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!
Because you're offering money if a way in is found. I feel like that's most of their hesitance, really, they probably just don't want to pay the bounties.
The group of people who run these corps are old enough not to be grown up with the internet, and some of them just can’t understand the dangers of this new world, even if you tried explaining it to them.
They are missing the fundamentals.
The people selling to rogue states and TAO aren't talking to the vendor in the first place.
Bug bounty programs are, for the most part, bullshit.
Because they need to verify the claim and see what it really affects? If there are other repercussions?
Because you don't want to tell more than you need? (a security researcher should know that)
Vulnerability disclosure is the closest thing to a protection racket that is actually legal. So it's natural that people will be on the edge. Sure, it beats the alternative.
The issue I have often witnessed, is a higher up wanting to play down a vulnerability, or even make so nobody hears about it because they fear it will impact the stock price. You should not forget that there is a financial impact...
It can be hard to separate signal from noise.
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
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.
In my experience, security engineers, even Apple security engineers, have the same very human kind of “can’t see my own typos” bias as the rest of us.
In my experience, fresh eyes looking from a different perspective are more likely to be right. (Part of why pen testing and security researchers are a thing.)
I've written web apps, and I've written embedded security code. It's a lot easier to screw up and have a race condition in rate limiting code in a web stack than in a carefully designed HSM consensus algorithm (especially since the latter kind of depends on this being handled properly for data correctness, not just defending against attacks).
Isn't that alone sufficient to demonstrate complete iCloud account takeover?
Agreed that this should not be taken as proof that the other reset flow was not vulnerable, but to me it seems like two separate issues.
However, the first half of the article focuses on him successfully being able to reset the password on any iCloud account that hadn't been used to log in to an Apple device.
Being able to remotely change the password of an iCloud account should earn him the full $100,000 reward, even if it is only on some subset of iCloud accounts.
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.
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.
If you don't rotate the six-digit code, the probability an attacker who tries sequential codes gets the correct code in 1M attempts is 1.
But if you do rotate the code, the Bayesian probability that an attacker who tries random codes gets the correct code in 1M attempts is still about 60%, if I did my math right (and of course it asymptotically approaches 1 with more attempts).
But either way it would be insecure if you did sequential... even if you had 2000 characters for your password.
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.
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.
Who assumed that?
You're comparing a situation where there's an unpaid family member, with a situation where the only person cooking is the information worker. In reality, there are a multitude of arrangement between those extremes, invalidating your argument.
Even then, health insurance costs differ between areas. Not to mention that the cost of every option you listed apart from using own time to cook is dependent on the local circumstances.
Similarly, travel and housing are very sensitive to geographic location, unless you want to travel across the world.
I don't think that "flawed economic thinking" follows from your second argument.
I strongly disagree. If you're a large tech conglomerate, and your center of mass is in the US, then the timezone difference (California -> New Delhi is 12.5hr) largely eliminates viability of real-time collaboration (without imposing significant burdens on the remote worker) and imposes significant communication delays if conducted asynchronously (e.g. over email, where your RTT is a full business day).
> cost of electronics, housing, clothing, accessories, vacation/travel etc are all same.
Mumbai seems to be broadly accepted as the most expensive city in India.
[0] says that if you want to buy a 1-bed apartment, it'll run you ~80 lakh - 1.5 crore. This translates roughly to $100k - $200k, in the most expensive city in the country.
For reference, in Atlanta, at the start of 2019 (so pre-pandemic shifts), the median 1-bed condo was just over $200k, per [1]. If we limit to top 200 metros, that's ~85th percentile, where the median price in the broader metro is comparable price-wise to a flat in the most expensive parts of Mumbai.
But okay, maybe instead it makes more sense to rent in Mumbai, at ~$300-500 per month. This is roughly half the price of renting in Oklahoma City, the cheapest metro surveyed by [2] (where according to [1], that same 1-bed would sell for $60k).
Are salaries in India (Mumbai in particular) depressed relative to comparable areas in the US? Likely! Looking purely at cost of purchasing housing, I'd expect salaries to be comparable to, say, Chicago, but that's nowhere near the case. Or if looking at rents, half of what a US-based engineer with comparable experience makes in a cheaper labor market (e.g. a new grad at Google in Chicago might receive ~$150k in total compensation).
Here's the thing, though: the primary driver of what companies are willing to pay you is not actually your estimated cost-of-living expenses (even if that's what they call it), but your local labor market. Minimum wage in Mumbai for skilled labor for college graduates is ~$18k (USD) / year. Minimum wage in Chicago is $14/hour; at 40 hours/week, 52 weeks/year, that's ~$30k / year which you could earn stocking shelves at Walmart or flipping burgers at McDonald's, as a high school dropout. Regardless, if you're good enough that $BIGTECH thinks you're worth the high salary, then you're good enough for them to want to relocate you. That bar's just much higher when they also need to sponsor a work visa (what with H1B quotas and all).
[0] https://housing.com/news/cost-of-living-in-mumbai/
[1] https://www.zillow.com/research/data/
[2] https://www.businessinsider.com/one-bedroom-apartment-cost-l...
> 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.
Cheapest median rents in the Bay Area are about $2k / month for a 1-bed, although pre-pandemic you were almost definitely compensating with transportation costs / time spent commuting. If you work at a startup in SF and make a modest $100k/year, that's 25% of your pre-tax income (a third of your post-tax income) going to housing alone. Add on cost of food, utilities, commuting costs (let's underestimate each of these at $100 / month), and now you're looking at nearly 40% of your post-tax income. I don't consider that a small part of the paycheck.
(Okay, maybe you make $150k pre-tax instead because you're an engineer. Now it's "only" 30% of your post-tax income on these non-discretionary expenses, just to support yourself.)
You do realize that global average GDP per capita is $11k? If you are in the US or Western Europe then the switch to "global economy" would probably push your salary down to $30k or less.
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.
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.
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.
I hope you‘ll never have to reset your password then as I‘ll happily send out those 5 requests every hour to lock you out ;-)
This is also a kind of attack.
Not sure your point on “resetting” passwords, though. This applies to any validation flow, i.e. just logging in.
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.
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...
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
[1] https://thezerohack.com/how-i-hacked-your-facebook-photos
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.
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.
Well done Apple.
Patching of the vulnerability probably, so they could weasel out of paying the full bounty.
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
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.
Apple probably thinks they’re protected themselves but if this guy “turns” the entire industry is at risk due to Apple’s thrift.
> 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.