Well, the point of kerckhoff's principle is that it should have been openly documented and then anyone lookindg at the docs even pre-publication would have said "we can't ship it like that, that feature needs to go."

[1] https://social.treehouse.systems/@marcan/111655847458820583

Or a joint project between several organizations.

[1] https://github.com/kokke/tiny-AES-c/blob/f06ac37fc31dfdaca2e...

[2] https://anh.cs.luc.edu/331/code/aes.py

[3] https://en.wikipedia.org/wiki/S-box

[4] https://en.wikipedia.org/wiki/Rijndael_S-box

Then how did these researchers do it? Not being cheeky, I just don't follow security super closely.

Maybe a nation state, e.g., APT?

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 contents of.

10 bits of security is probably enough for that as long as you reboot the system whenever the hash value is wrong. The coresight debug functionality can totally reboot the system if it wants to.

The part that's less easily explained is how they were able to reconstruct a custom sbox table to execute the debug code. That's where the "insider threat" insinuations are strongest, but personally I'm not convinced that it precludes any number of other plausible explanations. For example, the attackers could have extracted the sbox from: older firmwares, OTA update patches, pre-release development devices (probably purchasable on ebay at some points), iOS beta releases, or a bunch of other leaky vectors.

The researcher basically says "I couldn't find this sbox table in any other binary where I looked for it." Well, that's not necessarily surprising since it appears to be Apple specific and thus there are a limited number of binaries where it might have appeared. And as the researcher notes, this includes now unpublished binaries that might have been mistakenly released. It's totally plausible that the attackers got lucky at some point while they were systematically sniffing for this sort of leak, and that the researcher is unlikely to have the same luck any time soon.

The fact the attackers didn't know that Boolean expression suggests they reverse engineered it rather than had documentation.

In addition contents of the presentation, in terms of timeline...

2018 (September): First undocumented MMIO-present CPU launched, Apple A12 Bionic SOC.

2021 (December): Early exploit chain infrastructure backuprabbit.com created 2021-12-15T18:33:19Z, cloudsponcer.com created 2021-12-17T16:33:50Z.

2022 (April): Later exploit chain infrastructure snoweeanalytics.com created 2022-04-20T15:09:17Z suggesting exploit weaponized by this date.

2023 (December): Approximate date of capture (working back from "half year" quoted analysis period + mid-2023 Apple reports.

The presenters also state that signs within the code reportedly suggested the origin APT group has used the same attack codebase for "10 years" (ie. since ~2013) and also uses it to attack MacOS laptops (with antivirus circumvention). The presenters note that the very "backdoor-like" signed debug functionality may have been included in the chips without Apple's knowledge, eg. by the GPU developer.

So... in less than 3.5 years since the first vulnerable chip hit the market, a series of undocumented debug MMIOs in the Apple CoreSight GPU requiring knowledge of a lengthy secret were successfully weaponized and exploited by an established APT group with a 10+ year history. Kaspersky are "not speculating" but IMHO this is unlikely to be anything but a major state actor.

Theory: I guess since Apple was handed ample evidence of ~40 self-doxxed APT-related AppleIDs, we can judge the identity using any follow-up national security type announcements from the US. If all is quiet it's probably the NSA.

Assuming it wasn't a lucky guess, timing attacks are often used to find this stuff.

Perhaps. But it's easier to phone the technical librarian and say "Hi! I'm Bob from the password inspection department. Can you verify your current password for me?"

There is a photo of Mark Zuckerberg with a cut off 3.5mm jack plugged into his laptop - likely to achieve a similar outcome.

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.

with the Hard Reset key sequence, https://www.wikihow.com/Hard-Reset-an-iPhone

  It’s a hardware exploit, using undocumented registers. It can only be mitigated against, but not fully patched.

Fuzzing is about searching a state-space of an entity: function, method, and I suppose even a hardware-block for unexpected or undefined, or maybe even undocumented behavior.

Certainly this could have been used by the exploiters of these bugs to find undocumented but desirable effects in the hardware of iOS hardware blocks or devices.

Answering more broadly to your question, the "step-change" that you're asking for is precisely the "Lockdown mode" in iOS devices. It disables most of the features in order to reduce the attack surface of the device.

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 about the security of users and the App Store is kind of BS.

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.

https://securelist.com/trng-2023/

The most noticeable difference is that SVG elements (?) are replaced with emojis. I'm not sure how that fallback works but it's funny to see buttons have seemingly random emojis embedded in them. (Does anyone know the details of how this replacement is done? Is it actually glyph fonts being replaced, not SVG?)

Particularly considering how in the past Apple has been very willing to be on the receiving end of negative headlines for not giving US agencies decrypted access to iCloud accounts of terrorist suspects, with Google I don't remember it ever having been the target of such controversy, meaning they willingly oblige with all incoming requests.

[0] https://qz.com/1145669/googles-true-origin-partly-lies-in-ci...

The evidence clearly indicates otherwise…

I'd like to meet the person who suggested even sending .watchface files as iMessage attachments in the first place. What were you thinking? Did you not have a large enough attack surface already?

Apple really needs a paranoid mode

It can be disabled via Apple Configurator, https://news.ycombinator.com/item?id=38785311

> the unknown attackers kept their campaign alive simply by sending devices a new malicious iMessage text shortly after devices were restarted.

If apple is forced to shut down iMessage being the exclusive option and have some pure SMS application they might see a sudden noticeable drop in market share.

All the NSA needs to launch attacks like this is to get a bunch of mediocre engineers to layer complexity atop complexity. They don’t need Apple to know about the attack.

Honestly, they probably didn’t actually have to do anything to get Apple (or any other large company) to self-pwn itself by hiring and promoting engineers and project managers for adding features, but not for improving product stability or software correctness, or deleting forgotten legacy cruft.

Anyway, the most effective approach to sabotage is to be indistinguishable from incompetence, so it’s hard to say if the people responsible for the vulnerability chain were working with the NSA or not.

Kapersky reaches no such conclusion. That's from an FSB release.

doesn't the article states precisely otherwise? that while the FSB accuses Apple of cooperation, Kaspersky does not have any reason to believe so, especially since it does not look like any known state actor.

This was an extremely complex exploit. It was complex because of all of the defenses put in place by Apple and others. It required State level resources to pull it off.

We also don't know what, if any, external skullduggery was involved in the exploit. Did someone penetrate Apple/ARM and get internal documentation? Compromise an employee? Did Apple/ARM participate? Maybe they just dissolved a CPU cover, and reverse engineered it.

But, that cat is not out of the bag, and it's been patched.

Progress.

As many folks say, when it comes to dealing with security, consider the threat model. Being under the lens of an advanced State is different from keeping your young brother out of your WoW account.

This exploit wasn't done by a bunch of scammers selling "PC Support". That's the good news.

When stuff like this happens, I always go back to Stuxnet, where not only did they breach an air gap, they went in and did a sneak and peek into some other company to get the private signing keys so that their corrupted payload was trusted. There's a difference between an intelligence operation and a "hack".

Making stuff like this very expensive is part of the defensive posture of the platform.

> Our guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory, or that it was included by mistake. Because this feature is not used by the firmware, we have no idea how attackers would know how to use it.

However, keep in mind that this level of "bugdooring" is possible without Apple's explicit cooperation. In fact, the attackers don't even need to force a bug into the code. It would probably be sufficient to have someone on staff who is familiar with the Apple hardware development process (and therefore knows about the availability of these tools), or to simply get a copy of the firmware's source code. Sophisticated attackers likely have moles embedded within Apple. But they don't even need that here; they could just hire an ex-Apple employee and get all the intel they need.

> "The documents identified several technology companies as participants in the PRISM program, including Microsoft in 2007, Yahoo! in 2008, Google in 2009, Facebook in 2009, Paltalk in 2009, YouTube in 2010, AOL in 2011, Skype in 2011 and Apple in 2012. The speaker's notes in the briefing document reviewed by The Washington Post indicated that '98 percent of PRISM production is based on Yahoo, Google, and Microsoft'"

With the rise of end-to-end encryption in the wake of the Snowden revelations, this put large tech corporations in a bind, given the conflict between consumer desire for secure snoop-proof devices, and government desire for backdoor access. Pressure might have been applies by government contracting decisions, so no cooperation == no big government contract. The general rise of end-to-end encryption also meant that things like deep packet inspection along the trunk no longer worked, putting a premium on breaking into devices to install keyloggers etc.

All the fear of China doing this with Huawei (probably well-justified fear) may have risen in part as projection by politicians and insiders who knew the US government was doing it already with Apple, Android, Intel, ARM, etc. The US government has certainly retained legalistic justification for such behavior, even though the Act expired in 2020[1]. Also, corporations have been given retroactive immunity for similar illegal activites before [2], so Apple has that precedent to go by.

[1] https://www.cjr.org/the_media_today/section_702_renewal_pres...

[2] https://www.aclu.org/news/national-security/retroactive-tele...

The people finding and building these chains are doing so as part of nation-state intelligence operations; they go well beyond what any reasonable civilian threat model contains.

Put another way: if someone in a competent nation state's IC decides that you're worth $10+ million dollars to compromise, they are going to get you. This is true whether you have an Android, an iPhone, or a Tamagotchi. The only thing that sets Apple apart here is that they've historically beaten Google to the punch on mitigations for these kinds of exploits. But from a threat modeling perspective, this attack is not comparable to the kind that most people have to deal with. Treating it as indicative of an overall security differentiator will not help you make ordinary security decisions, because anybody who gets this kind of attention will be Mossad'ed upon[2].

[1]: https://en.wikipedia.org/wiki/FORCEDENTRY

[2]: https://www.usenix.org/system/files/1401_08-12_mickens.pdf

supports your point but it's not an easy argument to win either way. It's "everyone can see it so the good guys will find it first" vs "bad guys have harder time discovering vulns but once they do they have gold"

The OpenSSL debacle kinda disproved that point, didn’t it?

It's easy to laugh at Juicero users, it's harder to notice the bigger elephant in the room.

We can imagine that the government either has ideological capture of apple - that the management of apple agree to install hard to exploit vulnerabilities tailored for US government use - or legal capture through FISA rulings.

I’d be curious if anyone can summarize the latest understanding of FISA court actions in this realm.

[1] https://www.theguardian.com/technology/2016/mar/28/apple-fbi...

It sure quacks like a duck.

I was disappointed that nobody in the audience dared to ask the obvious question of how much time has passed between disclosing the vulnerability to the state agencies and Apple. I very much doubt the state didn't seize the opportunity to use the exploit against its enemies first and tactically disclose it later. If anything, the talk demonstrates that if they opted to disclose such a valuable exploit, they could afford to because they have the capability to discover more and have other exploits that did yet not outlive their use. I bet there is an interesting story behind the talk, hopefully, the details will eventually surface up.

As for detecting unauthorized apps, I would imagine that once you’ve taken over control of the OS kernel, it’s game over for such software-based restrictions. The Halting theorem guarantees such limitations to any software-based restriction. And as long as you can form a Turing complete mechanism from pieces of the computer, such software limitations will apply.

https://cdn.arstechnica.net/wp-content/uploads/2023/12/trian...

As you can see, it starts with a PDF coming into iMessage, and that PDF has a font that is able to exploit ROP gadgets.

Because Apple is busy fixing exploits discovered by Citizenlab. /s

But hey, Apple is secure.