Live data from Hacker News

Operation Triangulation: What you get when attack iPhones of researchers

securelist.com

301–310 of 433 posts

Re: Operation Triangulation: What you get when attack iPhones of researchers

#301

Earlier quoted context omitted.

Is that actually true? Has the price of these exploits been going up year after year, or has it topped out at some level?

It’s been going up consistently. The number of groups that can field a full chain these days is dwindling.

Perhaps Apple should provide research devices directly to the US's and China's intelligence agencies and pit them against each other to help close more vulnerabilities. The agencies can decide on their own where to strike the balance between offense and defense, but I suspect it would lead to more closed vulnerabilities over time.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#302

I'm curious to know from experts if there's anything Apple can do to create a step-change in terms of security of iPhones? Like if the going rate for a zero day is $1 million, is there anything Apple can do that can drive that up to $2 or $3 million? Or is it just going to be a perpetual cat and mouse game with no real "progress"?

I am by no means a security expert whatsoever. Period. But reading the article carefully, there is a step in the chain of exploits (CVE-2023-32435) which depends on exploiting Safari. Apple implemented a "Lockdown mode" ( https://support.apple.com/en-us/105120 ) which might have handled this (?). Answering more broadly to your question, the "step-change" that you're asking for is precisely the "Lockdown mode" in iOS…

The Safari vulnerability wasn't necessary (the device was completely owned before that), and was really just a "nice to have" - it allowed verification of the targeted user and, presumably, customizable malware delivery. From the article, if you look at the bullet points under the Kaspersky diagram of the exploit chain:

> After exploiting all the vulnerabilities, the JavaScript exploit can do whatever it wants to the device and run spyware, but attackers chose to: a) launch the imagent process and inject a payload that cleans the exploitation artifacts from the device; b) run the Safari process in invisible mode and forward it to the web page with the next stage.

In other words, if looking at the diagram, https://cdn.arstechnica.net/wp-content/uploads/2023/12/trian... , it's completely "game over" once you get to the skull icon in the lower left corner, and the Safari exploit is after that.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#303

I'm curious to know from experts if there's anything Apple can do to create a step-change in terms of security of iPhones? Like if the going rate for a zero day is $1 million, is there anything Apple can do that can drive that up to $2 or $3 million? Or is it just going to be a perpetual cat and mouse game with no real "progress"?

I mean, this is already an extremely complex chaining of exploits that requires extremely sophisticated research. I can assure you that this is not being used on the average person.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#304
post #236

I'm curious to know from experts if there's anything Apple can do to create a step-change in terms of security of iPhones? Like if the going rate for a zero day is $1 million, is there anything Apple can do that can drive that up to $2 or $3 million? Or is it just going to be a perpetual cat and mouse game with no real "progress"?

It's already 2-3 million +. Apple has amazing security, especially for the Iphone and continously monitors it and dishes out silent patches. For a REALLY high level example, it restricts system calls per process and requires all calls to be signed with an apple key, AND it restricts who you can do the system call to, these are continuously monitored and updated. Not only this, but persistence on Iphone is effectively…

That is good info, but why does Apple make it non obvious on how to reboot an iOS device and AFAICT there is no way to schedule a regular reboot.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#305

I'm curious to know from experts if there's anything Apple can do to create a step-change in terms of security of iPhones? Like if the going rate for a zero day is $1 million, is there anything Apple can do that can drive that up to $2 or $3 million? Or is it just going to be a perpetual cat and mouse game with no real "progress"?

It could author its format parsers in https://github.com/google/wuffs , and make them BSD-like open source to maximize adoption. An even bigger change: It could allow users to choose their iMessage client freely. Why not open up the protocol? I’m sure a security focused client would be popular and in the grand scheme of things easy to author. Perhaps they could open up more of the OS and apps. Perhaps their claims ab…

You do realize that this is an extremely complicated exploit which is not being used on the average user, right?

And being open source hasn’t prevented Android from being much more vulnerable to these kinds of exploits.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#306

>The resulting shellcode, in turn, went on to once again exploit CVE-2023-32434 and CVE-2023-38606 to finally achieve the root access required to install the last spyware payload. Why isn't Apple detecting the spyware\malware payload? If only Apps approved by Apple are allowed on an iPhone, detection should be trivial. And why has no one bothered to ask Apple or ARM about this 'unknown hardware'? >If we try to descri…

>Apple declined to comment for this article.

> >Apple declined to comment for this article.

Asshats

Re: Operation Triangulation: What you get when attack iPhones of researchers

#307
post #236

Earlier quoted context omitted.

It's already 2-3 million +. Apple has amazing security, especially for the Iphone and continously monitors it and dishes out silent patches. For a REALLY high level example, it restricts system calls per process and requires all calls to be signed with an apple key, AND it restricts who you can do the system call to, these are continuously monitored and updated. Not only this, but persistence on Iphone is effectively…

That is good info, but why does Apple make it non obvious on how to reboot an iOS device and AFAICT there is no way to schedule a regular reboot.

Need to restart your non responsive iPhone, hope you have some dexterity...

----

Force restart iPhone

If iPhone isn’t responding, and you can’t turn it off then on, try forcing it to restart.

    Press and quickly release the volume up button.


    Press and quickly release the volume down button.


    Press and hold the side button.


    When the Apple logo appears, release the side button.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#308
post #242

Earlier quoted context omitted.

In a week, a lot of data can be exfiltrated. Then after you have rebooted, the threat actor reinfects your device. Frequently rebooting the device can’t hurt but it likely isn’t going to prevent a threat actor from achieving their objectives. The best mitigation we have is to enable lockdown mode.

Why not both? Lockdown + frequent reboots.

How frequent?

Re: Operation Triangulation: What you get when attack iPhones of researchers

#309
post #207

Earlier quoted context omitted.

> reboot your iPhone at least weekly with the Hard Reset key sequence, https://www.wikihow.com/Hard-Reset-an-iPhone

Sorry for the lay question but what’s the benefit of the hard reset over a general restart?

I believe they’re assuming that malware can do a pretend reboot whereas the hardware keystroke can’t be faked.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#310

Notice that the hash value for a data write of all zero's is zero... And for a single bit, the hash value is a single value from the sbox table. That means this hash algorithm could reasonably have been reverse engineered without internal documentation.

This 'smells' like a typical way to prevent memory writes to random addresses accidentally triggering this hardware. Doesn't look like it was intended as a security feature. In fact, this is how I'd implement it if someone said to me it was important that bugs couldn't lead to random writes. This implementation also effectively prevents someone using this feature whilst giving a buffer address they don't know the con…

On the Amiga, you had to write to a blitter control register (BLTSIZE?) twice with the same value or it wouldn't do anything. This might be the same, only a lot more paranoid.

But it might also be a backdoor, intended or not.

Post reply on HN