Live data from Hacker News

Operation Triangulation: What you get when attack iPhones of researchers

securelist.com

381–390 of 433 posts

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

#381

Earlier quoted context omitted.

As explained by marcan: it's not "hashing", it's an error-correcting code. Much more understandable in that light. https://social.treehouse.systems/@marcan/111655847458820583

That the secret registers are in fact cache test registers, as explained at that link, is a very plausible explanation for their existence. Nevertheless, this does not explain at all the astonishing fact that they were mapped by default in the accessible memory space, unless listed and explicitly denied in the system configuration files. No amount of incompetence seems enough to explain such a default policy, so the…

Apple's mitigation was in fact to alter boot-configured memory mappings to deny access. (And as to the mappings... if they were in the middle of a range of documented registers, or close to one, sloppiness and poor internal communication are at least plausible...)

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

#383

Earlier quoted context omitted.

As explained by marcan: it's not "hashing", it's an error-correcting code. Much more understandable in that light. https://social.treehouse.systems/@marcan/111655847458820583

That the secret registers are in fact cache test registers, as explained at that link, is a very plausible explanation for their existence. Nevertheless, this does not explain at all the astonishing fact that they were mapped by default in the accessible memory space, unless listed and explicitly denied in the system configuration files. No amount of incompetence seems enough to explain such a default policy, so the…

[deleted]

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

#384
post #345

Earlier quoted context omitted.

> Decade old Backdoors no I really doubt it's a backdoor after reading the blog post and this thread chain from a prolific M1 MacBook hacker (macran) I think it was just an unused or very rarely used feature that was left enabled by accident. https://social.treehouse.systems/@marcan/111655847458820583 Some choice quotes. First, yeah, the dbgwrap stuff makes perfect sense. I knew about it for the main CPUs, makes perf…

>I really doubt it's a backdoor after reading the blog post and this thread chain from a prolific M1 MacBook hacker (macran) I think it was just an unused or very rarely used feature that was left enabled by accident. Why? Apple isnt exactly a small family business and this is quite the drastic "feature" to be left enabled by accident. How would one look from your perspective?

> Why?

Because 1. it helps with debugging at development time; 2. it may take unreasonable effort to disable, possibly from a hardware team's point of view with no direct security background; 3. it may be worth keeping around for future patching flexibility.

Source: [0]

> Apple isnt exactly a small family business and this is quite the drastic "feature" to be left enabled by accident.

No matter how large and hierarchical a company is, there will always be teams making hundreds of small, apparently localized decisions in their own line of work, without consulting anyone outside their team, and without seriously considering ramifications. It's humans all the way down.

> How would one look from your perspective?

A feature where you poke a seemingly random 64-bit value into an apparently arbitrary memory address, which grants you access to something you wouldn't normally have. That'd be a backdoor to me.

In the case at hand, the feature neither has a hidden MMIO address (it's discoverable in a small-ish search space), nor does it require a secret knock (but instead apparently just a somewhat convoluted checksum.)

[0]: https://social.treehouse.systems/@marcan/111656703871982875

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

#385

Earlier quoted context omitted.

> iPad with cellular does not really show you SMS's that's not from the carrier of the sim card. Does iPad support SMS? The cellular line is usually only for data, https://www.howtogeek.com/710767/how-to-send-sms-text-messag... iPads can't send SMS text messages through Apple's Messages app. Even if you have an iPad with a cellular data plan for mobile internet on the go, you still can't send SMS text messages.

Apple's own user guide ( https://web.archive.org/web/20201223140550/https://support.a... ) suggests otherwise: >In the Messages app , you can send text messages as SMS/MMS messages through your cellular service, or ... Also my own experience is that it at least can receive SMS text messages, just it won't show you if it's not from your carrier (if it's from your carrier, it shows you via a popup window or something,…

iPad can neither send nor receive sms. The only way it can is through a nearby iPhone, or iMessage

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

#386

Earlier quoted context omitted.

For starters, it took them four years to detect an intrusion that takes advantage of a messaging service (iMessage) that wasn't the corporate choice for internal communications, and allowed the exfiltration of gigabytes of data from the C-suite and high level managers. This is Kaspersky. They had to be aware of the long history of iMessage security bugs. They could have disabled it. They chose to ignore it instead.

This is an exploit from an adversary that reversed undocumented MMIO registers to completely bypass kernel write protections. Do you honestly believe that disabling iMessage would keep them out? They’d just field the exploit using Exchange or HomeKit or any of the dozen other ways there are to get content onto the devices.

> Do you honestly believe that disabling iMessage would keep them out?

Maybe, maybe not. But it is still a testament to their poor security posture that iMessage was enabled in corporate devices, when it is not part of their software catalog.

Kaspersky has tried to publicly switch blame to Apple twice in a row now. Maybe it is time for them to take some.

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

#387
post #308

Earlier quoted context omitted.

Why not both? Lockdown + frequent reboots.

How frequent?

Depends on usage and threat models? If one expects their device to be attacked immediately after a forced restart, SIM PIN can stop non-emergency usage of the cellular line, while Apple Configurator can restrict WiFi to a predefined SSID that captures device traffic for forensic analysis.

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

#388

Earlier quoted context omitted.

Or, like, they have a root kit and it works so why reinvent the wheel? They have an attack payload so why reinvent the wheel? Just plug and play all the packages you need until you can compromise your target device.

But there is a very good reason to reinvent the wheel here: to not burn more zero-days than you have to.

Exactly! This is the part of the story that mystifies me completely and I would love to see some explanation.

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

#389

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"?

We'd need to scrape decades of work in hardware and software for that.

Modern software sits on a foundation that was thought for a different era. They didn't have in mind the current challenges in terms of security and scale.

Post reply on HN