Unbelievable work by @AmnestyTech, done in spite of @Apple’s reticence to provide means to verify the integrity of iOS devices. What’s it going to take for Apple to stop burying its head in the sand?
These remarks on the limitations when inspecting iOS devices should give us pause… there’s a mistaken belief that privacy is protected by limiting checks on system integrity and correlation of anomalies. What privacy is protected in these cases? (@tim_cook@radian)
I love Apple products. Wonderful things are regularly done under the hood to increase the cost of attack. But it’s clearly not enough to tinker with security engineering alone. Plenty of unscrupulous actors are finding it affordable and we can’t even tell how big that iceberg is.
I promise you @Apple has no idea how deep the iceberg of targeted iOS malware goes. Not by a long shot. They’ve just accepted it as an unremarkable inevitability and we can’t.
Since this is blowing up, let me add that I know great folks who are or have worked security at Apple with the best intentions. If anything this is a plea to empower those folks to do more, prioritize their concerns, give them avenues to innovate, notify, and publish.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
As to NSO’s blanket denial of having any access to how their customers use their software, that’s not entirely true by design —they manage the exploit delivery infrastructure for their clients. This is a hard-earned lesson from the HackingTeam days—
HT had a lot of woes attempting to idiotproof their payload building and exploit delivery process. The former was characterized by a prompt urging operators NOT to upload to VT (aimed primarily at dim Saudi operators). Exploits were handled more carefully via support portal—
The support portal required a backdoor created with the HT masternode and a lure document of the customer’s choosing. HT would create the exploit-laced file and host it via a one-time link that the operators could deliver in the method of their choosing.
Ok, I have to admit this @Apple vs. @CorelliumHQ business just doesn’t sit right with me. Let me @ @tim_cook and pretend to have some meaningful engagement regarding Apple’s larger security dilemma. #Thread
Everyone knows I’m a huge Apple fanboy. Until the cheese grater Mac Pro came out, I more or less had one of every apple product in my house (with some wiggle room). While I may gripe about missing function keys, there’s no system I’d rather use than MacOS and iOS.
I’ve also, at diverse points in my career, had the privilege to report ongoing APT campaigns directly to Apple alongside colleagues (h/t @craiu) and was treated kindly by folks invested in securing the Apple ecosystem within the means available to them.
1st point is that we (private sector threat intel researchers) mistook the provenance of Neuron and Nautilus. NCSC’s previous advisory denounced the use of both tools alongside Turla’s staple rootkit and we assumed new tools from the Turla devs but it seems they’d been stolen.
Keep in mind that the advisory is hinting at some dev access, some infrastructure access, but perhaps not complete access to Iran’s full operational stack. Turla first deploys the tool to their rootkit victims for testing and further functionality.
Those non-existent norms were originally shattered by Flame subverting the actual Windows Update mechanism via an unheard of md5 collision to impersonate signing certs (implemented in its GADGET module).
Flame really doesn't get the credit it deserves as the first public harbinger of so many trends we'd come to know all too well in cyberespionage over the following 7 years.
It’s surprising how often folks mistake familiarity and expertise with one area as competency in a field writ large. This happens often in the vuln-dev vs AVs/TI debates, the ‘if you’d only used Chrome’ camp, and ‘experts’ vs the people debates.
It’s usually not worth engaging, however, I think it’s important to counteract myopic views that may affect effective recruitment in infosec writ large.