Live data from Hacker News

NSO group iPhone zero-click, zero-day exploit captured in the wild

citizenlab.ca

821–830 of 886 posts

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#821

I would expect them to get to iCloud via this attach chain even with advanced data protection on. Which means if you are targeted, they not only get data from your iPhone but also all the data you backed up to iCloud from your other apple devices. I suspect they would be able to compromise apps like 1Password through this. Which means all services whose password and 2FA is stored together in 1Password is compromised.…

I cannot fathom how terrifyiny it is to be using iCloud Keychain. Would honestly rather become a new customer with Lastpass over that.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#822
post #23

Here we go again... NSO Group has a long history of 0-click, 0-days against iMessage, and just a few months ago Kaspersky caught a different zero day iMessage exploit targeting their staff. If Apple repeatedly fails at securing their devices from an attack vector that has been demonstrated over, and over, and over... no wonder China is banning government officials from using their devices.

>no wonder China is banning government officials from using their devices A totalitarian regime can have a different, plausible reason: no sufficient control over said devices.

iPhones can be provisioned with pretty extensive profiles/MDM so I doubt that part. They probably see all the zero-days and decide game respects game. Just not secure enough for such an incredibly insular power structure as theirs, even without the US connections.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#823
post #511

Question. Back in the dark ages, a "zero day exploit" was a piece of malware which would lay in wait, doing nothing, counting down the days, until it hit day zero, and then it would trigger and do naughty things. Some folks also referred to this as a time bomb, but that was a less `|33+ term for it. We used to see a lot of these available on sites such as asta... never mind. Fast forward to the era of "cyber" being h…

The more important designation is whether a hack is "zero-click", meaning it requires no user interaction.If such is the case, it cannot truly be defended against, it is purely automatic or automatistic and if your phone is on and has the conditions necessary for it to take root, it will happen without fail.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#824
post #457

Earlier quoted context omitted.

What code auditing? Are you claiming NSO has access to iMessage and iOS source code? NSO seems to be finding more and more bugs by poking a black-box alone, while Apple cannot seem to be able to fix by looking at the source code with all the fuzzing and verification tools, and much more $$$ at their disposal.

Sorry I thought it was obvious that I meant reverse engineering the closed source pieces of iMessage and auditing the open source bits. Source code just speeds up the process for vulnerability researchers, so Apple has a leg up in this regard. "Are you claiming NSO has access to iMessage and iOS source code?" The last NSO zero-click was in an open-source library reachable from iMessage. This vulnerability is likely n…

They also probably use simulation software like Correllium that eerily simulates iOS seemingly to the extent Apple wanted them shut down. If anything, iPhones would be far more secure if everyone could get eyes on their OS and be able to toy with it experimentally. I suspect they aren't the only actor against such radical transparency at the corporate and governmental levels.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#825
post #462
post #448

Earlier quoted context omitted.

Given all the major tech companies aggressively fuzz everything maybe, just maybe, you're missing the additional possibility: fuzzing is still random and extensive fuzzing does not mean you will encounter the same code paths as anyone else. You need to understand "do fuzzing" is not a magic trick to find all bugs in software. Similarly: definitionally you will only ever see the bugs that are not found prior to shippi…

Fuzzing is not a magic trick, in the same way as invariants are not, and unit tests are not, and debugging is not. All these techniques have degrees of mastery, and if applied carefully, and in combination, can save you a lot of grief. Dumb fuzzing will not get you anywhere, same as dumb unit testing, and dumb debugging. In this case, iMessage is particularly well suited for some smart fuzzing because all the attack…

You're missing the point: It is possible fro multiple distinct groups to all fuzz the same code and find different non-overlapping bugs.

You are erroneously saying "one group of people found a bug that could be found by fuzzing therefore apple is not fuzzing".

LibJPEG is decades old at this point and is still getting around 10 CVEs a year, despite being one of the projects I believe google constantly fuzzes.

zlib is getting a few a year despite being a vastly more constrained format than anything else imaginable, and again being a heavily fuzzed library.

If "do lots of fuzzing" caught every bug, then you'd get a big release that fixed all of them, and you'd never see any more.

> In this case, iMessage is particularly well suited for some smart fuzzing because all the attack vectors seem to involve smallish malicious attachment files.

I chose to include libjpeg above specifically to rebut this comment. That there are still CVEs coming in for libjpeg this year, despite years of fuzzing should be sufficient to show that even small attachments aren't magically invulnerable due to fuzzing.

Fuzzing is a useful tool but pretending that some project or software is going to be secure because it's been fuzzed a lot is nonsense, and pretending that fuzzing will find all the bugs is complete fiction.

Even software written in memory safe languages benefits from fuzzing: a memory safe language simply means your code will not continue if doing so would result in a memory safety violation, but for most memory safe languages that means at best an exception, but in most cases it means termination - that's what you get in Rust, Swift, or even functional languages like Haskell - and program termination can mean user data loss, or at least a bad user experience, so fuzzing is helpful even if bugs don't cause "security" issues.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#826

Earlier quoted context omitted.

I use Lockdown Mode on my Mac because I don’t use iMessage, FaceTime, or other apple services on that device. It’s literally just a computer for software dev and maybe YouTube videos. I haven’t noticed any difference with web content either, but I also use Firefox / Chrome instead of Safari. What I would really like to see is options. For example on iOS I use shared photo albums, so it would be nice to keep that feat…

Lockdown mode? How do I enable it? As someone who owns a Macbook as their only Apple product, I hate seeing or dealing with Apple pushing their services to me

Read this page: https://support.apple.com/en-us/HT212650

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#827
post #751

Earlier quoted context omitted.

That is not a reasonable position, "peacefully" writing software that you know is to be used to murder and silence other people makes you just as complicit those crimes (definitely an accessory). No better than a getaway driver.

Software is speech (ie protected expression), like writing books. A getaway driver is involved after the crime is committed. To assign the same level of culpability to a tool-maker would imply that they have the ability to predict the future. A better example would be a car or firearm manufacturer. How the tool is used is up to the user. Software doesn't root people's phones, cops and spies do. Someone sent that iMes…

Speech can be murderous, and more importantly, it can be punishable. Ok, what about if the getaway driver drove him there as well, and explicitly expressed knowledge of the crime that was to occur and refused to abandon the effort upon receipt of such knowledge.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#828

Wow, so much discussion of Apple and their software, and so little of NSO group and why they're even a thing. I just want to add this: these people operate pretty much in the open. They're not ashamed of it either, or else they wouldn't put it on their CV: https://www.linkedin.com/company/nso-group/people/ That right there tells me that we as "the tech community" are way too okay with this sort of application of the…

I don't see why companies that facilitate criminal acts are not swiftly brought to legal justice. We should not be tolerating companies like NSO group in any sense. If the Israeli government wants to look the other way, we should designate NSO group a terrorist organization and start sanctioning any country that won't bring them to justice.

If Snowden and Assange can be extradited to the US and tried for crimes, executives of NSO group absolutely should as well. Lock 'em up!

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#829
post #17

Earlier quoted context omitted.

It does. The page even recommends lockdown mode as a mitigation for affected parties (people who aren't updated)

Its super interesting to me how much its emphasized that you shouldn't use this (Lockdown Mode) unless you are a journalist or otherwise in direct danger. They really do try to talk you out of it. Its curious, because there's very little difference in functionality other than disabling a lot of Apple nonsense from running in the background expanding your attack surface.

Blocking "most attachments", including links, from iMessage would be a very visible and annoying change

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#830

Earlier quoted context omitted.

If you reimplemented it they'd just change it. It's Google, they can't stop themselves.

I don't believe you, frankly. I don't believe that Google makes breaking changes to existing image formats often.

They already did - WebP added a lossless mode and VP8 was updated to VP9.

Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)

Post reply on HN