Hacker News Reader

Comment by 58x14 | Hacker News Reader

This is such an incredible amount of vulnerable mission-critical data.

- all contacts, including 3rd party messaging apps, with metadata (interactions, timestamps, other stats) - full address book - whether any app is installed - SSID of connected wifi

and formerly,

- medical info - device usage - screen time - device accessories

I don't keep anything mission critical on mobile, but this is still a gargantuan set of exploits, and each appear extremely straightforward to validate and pay out the security researcher (and maybe even patch). It's utterly tragic how Apple (and others) have devolved to become the same monolithic, careless organizations they once displaced.

I really, really hope something changes. Soon.

View on HN

The only mitigating factor is that they’re not remote vulnerabilities.

That being said, this is more or less the industry standard. And even if the other person mentioning this was downvoted, they are right: this has been the case since forever and can only be remedied through laws making companies responsible for their failures. But neither the US government nor said companies want this. It will have to get so bad that it visibly harms US or EU security for something to move in this space.

And if you try to deploy these in an actual app, you will be getting banned very, very hard.

Do you have any evidence that Apple has been checking for these vulnerabilities in apps? I mean, if you tried now, sure, I'm guessing you'd get caught (or will be soon). But these have been around a long time.

No, I mean if you try it now.

That seems a generous guess, given the mitigation of fixing the bug would be much less arduous to do and hasn't been done (for two of the exploits).

https://twitter.com/izmcm/status/1441491002259218432

The remedy for this is not just making the company's responsible for the failures, but hunting down criminals who abuse it globally and sentencing them to death.

Is that really the case? Or were they just not such a big target before when everyone was spending most of their time in a windows desktop. Maybe they just got away with it more easily in the past.

100% - they got away with it because they were small. Hacking Mac OS was unattractive - whereas, hacking iOS is the most attractive target. High gain, low security.

Apple does not have security in its DNA, as is obvious from all these exploits. Apple lives in the past where it was OK to kinda fudge it, to kinda give home apps special passes, to bypass stuff to make the game center work, and so on and so forth. These are all red flags.

Apple's threat model is script kiddies and Russian hacker groups. It's very naive vs real world exploits conducted by state level actors, companies serving state level actors, and a $1M market rate for iPhone zero day p0wn exploits.

In this cat and mouse game, the hackers are leagues ahead at this point - motivated by money and a whole different mindset.

Relying on the app store review process to catch these things is naive. A company that takes security seriously would never even think this way, obviously there's many ways around app store reviews, and hackers who went through all the trouble of finding exploits will find a way around the app store reviews, too.

> I really, really hope something changes. Soon.

I would not hold my breath... it's been like this for decades at least.

If these are gargantuan, how would you describe a remote zero click complete device compromise (complete with camera/microphone access)? What about an exploit that can cause the users phone to explode?

I would be an order of magnitude less concerned with camera/mic access, compared to perfect historical proof of my usage and communication patterns.

Exploits often feel like pathogens, probably why they share the term virus. If a virus has a high mortality rate, contagion is lower, because it frequently kills the host before it can spread.

Similarly, I think a 'complete device compromise' is much more likely to be identified, prioritized, and patched. The vulnerabilities mentioned here represent the highest severity without an immediately noticeable fallout. Props to the researcher.

P.S. I wonder if the researcher's Russian nationality (assumed from their other post) had any impact on their lack of payout.

It's hardly 'perfect historical proof', not to diminish the seriousness of the vulnerability. But more importantly, the mechanism matters a great deal. This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation. This leaves a trace and exposes the attacker to consequences. No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it.

To exploit this you only have to infect one of the many dependencies off user installed app. It is not true that the attacker has to forge an identity in the App Store. It is enough to insert your code somewhere along the whole software supply chain. And that can be long, think about ReactNative apps using NPM dependencies.

> This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation.

It's a much higher bar when it's a targeted attack but not necessarily if it's a dragnet like when a malicious party buys a browser extension from the creator to harvest user data. The only real difference between the two scenarios is iOS's significantly stricter review process and sandbox - if this exploit can bypass both [1], it doesn't matter whether the malicious developer can be traced because it'll just be some indie dev who just sold his username/password and signing keys for $X0-Y00k to some shell corp in the Bahamas.

[1] Are these exploits detectable through static analysis or some other automation? (I have no idea)

The 'only real difference' is a pretty big difference - the iOS developer is much more strongly identified. It's also not the only difference - what you can do with the access is different and what you end up doing with the access is different. But in both cases, there are strong disincentives not to do very overtly malicious shit - few extension takeovers go around stealing your online banking password, even though they could.

A drive-by exploit has a lot fewer of these constraints.

Dumb implementations can be caught via static analysis. Smart ones are not going to be caught until Apple realizes they are exploiting people and reverse engineers them by hand.

> No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it.

Except Facebook. Or another behemoth that felt they could weather Apple's wrath if it ever came to it. Or a company that Apple had granted special permission to do this, like they did with Uber.

Apple killed a bunch of FB's tracking a few months ago and the story is still making the rounds and is on the front page as we speak.

The point isn't that this isn't a serious vulnerability or is somehow unexploitable. It's just that there's a great deal of friction in exploiting it for relatively paltry returns. Nobody is going to get into a spat with Apple and invite regulatory and law enforcement attention to traceably and with undeniable intent steal your contact list. Nobody is going to (like another commented hypothesized) launch a supply chain attack to steal your contact list with this vuln. At that point you'd find a better vuln. This one isn't all that much better than just misleading people into giving you contact list permission.

The OP is saying it's somehow worse than drive-by or low-interaction vulns that own up entire devices and have been repeatedly found in the wild. I don't think that holds up.

I’ve always been curious how many developers might drop this in their code but only activate against potentially valuable targets

I'd think also almost zero. A lot of sleazy data collection operates under at least some fig leaf pretense of user consent, in this case there's none. Once the vulnerability is discovered, Apple could find out if you've deployed such code more or less ever. Then you'd probably have problems bigger than just a contractual dispute with Apple.

Maybe some devs are allowed to do this. And that's why it wasn't patched.

> What about an exploit that can cause the users phone to explode?

Possibly world ending, at least from the perspective of the user whose phone explodes next to their face?

Do like GM, keep your phone at least 5 feet away from other phones while not in use.

I’m not saying the above issues don’t matter, but they’re hardly the most critical things you could do to an iPhone.

You can do a lot more damage with someone's bank account than you can by exploding their phone.

Currently holding my phone, with a full charge. Basically a hand grenade, about 12” from my face, with (thanks to oversized phones), both hands on it.

At best id be blind and unable to use my hands. I don’t give a stuff about my bank account compared with that.

There are no explosives in a phone though. Lithium batteries might burn when short circuited... however, this requires physically damaging the battery, or shorting the circuitry. This requires some seriously silly hardware vulnerabilities (lithium cell protection is typically implemented in dedicated silicon), not simply a software vulnerability. And if you could successfully perform an exploit like this, you would probably drop the phone before it hurt you.

https://youtu.be/osfgkFyq7lA?t=246

Won’t matter much if it burns your house down while you’re inside.

A complete compromise can also get access to your bank, mail accounts, message history, mic and camera. Which vulnerability would you prefer be used against you?

I'd marry mic access, F#$% camera access, and kill bank access. Maybe that's just a personal opinion, though.

Depends on where the phone is at the time. Do it while they’re on a call and it’s going to really suck.

Gargantuan.

Cynically I feel like we’re maybe expecting a lot here. Privacy (and I’d assume security, given it’s a necessity to achieve that) was a well-timed marketing drive at Apple, but that was months ago. You can’t expect them to support these minor features forever!

Besides, why focus on something as superficial as keeping your private data safe when the new iPhone now comes in a gorgeous pink finish. And with Ceramic Shield and the lightning-fast A15 chip? It’s truly the best iPhone they’ve ever made.

These puppies sell themselves without all that expensive privacy talk.

Honestly their attitude to the bug bounty makes me wonder if there’s not a small group of engineers that keep screaming about this problem just to have the door closed behind them and a “lol nerds” giggle heard from the execs on the other side of the door.

Reply on news.ycombinator.com