Operation Triangulation: What you get when attack iPhones of researchers
securelist.com
securelist.com
I was willing to believe that maybe it was just a massive NSA-scale research team up until the part with a custom hash function sbox. Apple appears to have known that the feature in question was dangerous and deliberately both hidden it, whatever it is, and then gone further and protected it with a sort of (fairly weak) digital signing feature.
As the blog post points out, there's no obvious way you could find the right magic knock to operate this feature short of doing a full silicon teardown and reverse engineering (impractical at these nodes). That leaves hacking the developers to steal their internal documentation.
The way it uses a long chain of high effort zero days only to launch an invisible Safari that then starts from scratch, loading a web page that uses a completely different chain of exploits to re-hack the device, also is indicative of a massive organization with truly abysmal levels of internal siloing.
Given that the researchers in question are Russians at Kaspersky, this pretty much has to be the work of the NSA or maybe GCHQ.
Edit: misc other interesting bits from the talk: the malware can enable ad tracking, and also can detect cloud iPhone service hosting that's often used by security researchers. The iOS/macOS malware platform seems to have been in development for over a decade and actually does ML on the device to do object recognition and OCR on photos on-device, to avoid uploading image bytes: they only upload ML generated labels. They truly went to a lot of effort, but all that was no match for a bunch of smart Russian students.
I'm not sure I agree with the speaker that security through obscurity doesn't work, however. This platform has been in the wild for ten years and nobody knows how long they've been exploiting this hidden hardware "feature". If the hardware feature was openly documented it'd have been found much, much sooner.
That's the problem with this sort of security through obscurity; it's only secure as long as the people who know about it can keep it secret.
So it either has to be stolen technical docs, or a feature that was put there specifically for their usage. The fact that the ranges didn't appear in the DeviceTree is indeed a bit suspicious, the fact that the description after being added is just 'DENY' is also suspicious. Why is it OK to describe every range except that one?
But the really suspicious thing is the hash. What kind of hardware interface does arbitrary DMA protected by a secret but weak hash function? Is there any legitimate usage for such a thing? I've never heard of such an interface before.
If it's a genuine backdoor and not a weird debugging feature then it should be rather difficult to add one that looks like this without other people in Apple realizing it's there. Chips are written in source code using version control, just like software. You'd have to have a way to modify the source without anyone noticing or sounding the alarm, or modifying it before synthesis is performed. That'd imply either a very deep penetration of Apple's internal network sufficient to inject backdoors into hardware, or they have one or more agents.
This really shows how dangerous it is to intel agencies when they decide to attack security professionals. Attacking Kaspersky has led directly to them burning numerous zero days including several that might have taken fairly extreme efforts to set up. It makes you wonder what is on these guy's iPhones that's considered so valuable. Presumably, they were after emails describing more zero days in other programs.
Not the software kind, the good old listening devices.
There's a deep tool chest of spying. Heck, remember when keyboard presses were harvested through a wall? That was at least a decade ago. I think audio of key presses can be disambiguated.
Never attribute to malice that which can be attributed to incompetence. There are plenty of examples in the wild of going halfway with strong security, but halfway still leaves the barn door open.
That rule should only be applied in the normal world. The world of security where you know bad actors are out there trying to do stuff, it doesn't apply. And there are examples of spy types injecting plans to go halfway with security for their purposes - not that this proves the origin of a given plan, incompetence is still one possibility, it just returns to original point, that this stuff is mysterious.
Their review processes are so incompetent even one of the most security critical components, root login, let a totally basic “fail your security 101 class” bug through. It is absolutely inexcusable to have a process that bad and is indicative of their overall approach. As they say, “one cockroach means an infestation”.
Just to list a few process failures off the top of my head.
No proofs of specification conformance. No specification conformance tests. No specification. No regression testing. No regression testing of common failure modes. No testing of common failure modes. No enhanced review for critical components. No design conforming to criticality requirements. No criticality requirements. No intention to establish criticality requirements.
In actual safety and security critical software development you do all of those except maybe the first. Doing none of them is rank incompetence and clear evidence you do not know the first thing about actual security that can protect against real professionals. And fancy that, Apple can not and never has against attackers with minimal resources like small teams with only a few million dollars.
We can talk about a reputation for “strong” security when they can protect against the standard, commonplace 10M dollar attacks we see every day.
Since then, though, they have cleaned up their act (I've never been a fan). As a silly example, I'm pretty sure they finally check into source control the configuration of their networking equipment... Plus do a lot more to counteract the sophistication of today's nation-state attacks. They've come a long way since the hacks of 2014, when they had to scramble to enable 2FA for iCloud — previously used only for account changes or purchases. As for this vulnerability, it might be a plain bug or some NSA-style backdoor with plausible deniability, but we probably won't know which for years.
But that said, overall I agree with Mike, in that Apple is clearly committed to security of their users. It's one of the main reasons I buy Apple hardware for my mobile, personal and work devices. Nobody is forcing them to put so much effort into that security, either - they do it largely by choice, and it distinguishes them from other vendors whose business models are inherently in conflict with their customers (I don't want to buy a phone from a company that derives most of its revenue from facilitating psychological warfare between advertisers and me.)
But I've always found this security to come with interesting tradeoffs. On the one hand, I'm pro-privacy and pro-user. But certain security objectives can't be achieved without reducing privacy or increasing restrictions on the user. Over the years I've come to appreciate this tradeoff, and I think Apple does a good job of balancing it. While I certainly don't feel like the device is "fully mine," I do feel like I'm getting some extra security in exchange for giving up some freedom to tinker.
[0] https://arstechnica.com/information-technology/2017/11/macos...
Compared to other mainstream operating system, they seem to constantly be the last to introduce things like stack canaries, non executable memory segments, and all that which is considered best practice now.
I agree. This appears to likely be an intentional backdoor injected at the hardware level during design. At such a low-level I think it could have been accomplished with only a handful of employees in on it. There would have been no need to subvert Apple from the top down with large numbers of people at many levels being privy.
In early silicon there can be a bunch of registers and functions implemented for testing which are later pulled out. Except maybe one set of registers doesn't get pulled but instead a door knock is added with a weak hash function, making the registers invisible to testers and fuzzing.
It seems a little too convenient that the door knock hash was weak. After all, strong hash functions aren't unknown or hard. The reason it had to be a weak hash function was to create "plausible deniability". If it was a strong hash then once any exploitation was discovered there would be no denying the vuln was intentionally placed. If it really was just a test DMA function that someone supposedly 'forgot' to remove before production silicon, I can't think of a reason to have it behind any kind of door knock in the first place.
I read that it was patched by adding these addresses to the "access denied" list. While I don't know anything about Apple security, I'm stunned that any such low-level access list isn't 'opt-in' instead of 'opt-out'. If it was 'opt-in' it seems like any such 'undocumented' register addresses would by denied by default. And if they were on the 'opt-in' list, yet remained undocumented, then it would be obvious to anyone looking at the security docs that something was amiss.
[1] https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...
That'd probably depend on which team the dev worked in. If they were in the right team, then it might.
a) If a person is using those values daily for years (or even a couple of months), then it's very likely they'd have memorized them
b) Sometimes just knowing the concept exists for sure is good enough, as you can then go and brute force things until you've worked out the values
My theory is that defensive cyber security is so hard that it's literally easier to hack the entire world(with a focus on security people) to see if anyone has breached your systems.
A good honeypots is a counterattack on intruder psychology in a host of ways.
I don’t really have any proof but considering the massive gain it shouldn’t surprise anyone. The agencies might not even need to pay large sum of $$$ if the said assets have vulnerabilities.
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."
Similar for the GPU too. They may have started with HDL licensed from others (like I think their GPU might actually have been directly based on the PowerVR ones they used to use, but I believe the ARM one is basically from-scratch) but this vulnerability seems unlikely to have existed since then…
> but I believe the ARM one is basically from-scratch
You are wrongly believing then. There’s still a bunch of ARM IP in their CPU.
Or a joint project between several organizations.
Maybe a nation state, e.g., APT?
And while Kaspersky is refusing to speculate at all about attribution, the Russian government has claimed (without giving specific evidence) that it's NSA.
I think that was in the news back in the sochi Olympics. The value of cyber capabilities is only going up with time
The siloing may be due to multiple contractors. I imagine these exploit vendors are protective of their arsenal of attacks.
Because as has been said many times, the three letter agencies aren't exempt from the curse of government employee mediocrity.
[1] https://social.treehouse.systems/@marcan/111655847458820583
- The "hash" is probably an error correcting code fed into GPU cache debug registers which will be stored in the cacheline itself, you're expected to compute the ECC because it's so low level. That is, the goal isn't to protect the DMA interface. (but this isn't 100% certain, it's just an educated guess)
- The "sbox" is similar to but not the same as a regular ECC as commonly used in hardware.
- Martin argues that the existence of such registers and the code table could have been guessed or brute forced, even though a compromise or info leak from Apple seems more likely. Or possibly even from the old PowerVR days. But if it's the NSA then who knows, maybe they are literally fuzzing hidden MMIO ranges to discover these interfaces.
- This is possible because the GPU has full DMA access without an IOMMU for performance reasons, so it's fertile ground for such exploits. Probably more will be discovered.
So that's all reassuring.
Each of the 10 parity bits output by the function is the xor of exactly 104 of the 256 input bits.
Each of the 256 input bits contributes to (= is xor-ed into) either 3 or 5 of the 10 parity bits.
This is in line with the SEC-DED (single error correction, double error detection) ECC construction from the following paper:
https://people.eecs.berkeley.edu/~culler/cs252-s02/papers/hs...
Translating the above observations about the function into properties of the H matrix in the paper:
Each row of the matrix contains an identical number of ones (104).
Each column of the matrix contains an odd number of ones (3 or 5).
Then how did these researchers do it? Not being cheeky, I just don't follow security super closely.
[1] https://github.com/kokke/tiny-AES-c/blob/f06ac37fc31dfdaca2e...
[2] https://anh.cs.luc.edu/331/code/aes.py
“This iMessage exploit is crazy. TrueType vulnerability that has existed since the 90s, 2 kernel exploits, a browser exploit, and an undocumented hardware feature that was not used in shipped software”
https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...
https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
(talk starts at minute 26:20)
According to him the exploit chain was likely worth in the region of a 8-digit dollar value.
¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
I guess somebody is going to get fired.
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 perfect sense it'd exist for the ASCs too. Someone had a lightbulb moment. We might even be able to use some of those tricks for debugging stuff ourselves :)
Second, that "hash" is almost certainly not a hash. It's an ECC code*. I bet this is a cache RAM debug register, and it's writing directly to the raw cache memory array, including the ECC bits, so it has to manually calculate them (yes, caches in Apple SoCs have ECC, I know at least AMCC does and there's no reason to think GPU/ASC caches wouldn't too). The "sbox" is just the order of the input bits to the ECC generator, and the algorithm is a textbook ECC code. I don't know why it's somewhat interestingly shuffled like that, but I bet there's a hardware reason (I think for some of these things they'll even let the hardware synthesis shuffle the bits to whatever happens to be physically optimal, and that's why you won't find the same table anywhere else).
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?
Mistakes happen, maybe it's used in the manufacturing or fab phase to test something. Maybe it's used by the GPU firmware itself to perform some operations.
Maybe it was used by some older SoCs to do something and was just never removed.
Apple may not be a small family business but silly mistakes still happen all over the place in nearly every large system.
To quote another post by macran cause I feel like it's super relevant when trying to analyse how this kind of stuff comes about.
@nicolas17 @nil Correct. The question is, how many more of these fun bypasses are left undiscovered? The GPU is a huge amount of hardware and firmware.
Computers are so incredibly complicated now days that these kinds of hardware bugs are likely sitting around elsewhere as well, they don't come around that often because the amount of effort required to find them is likely a lot, which is likely only viable for a nation state actor.
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
Even though no public documentation exists, I'm sure thousands of Apple engineers have access to a modded gdb or other tooling to make use of it.
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 supposition of an intentional backdoor still seems more likely.
It's just a few lines of code to parse the memory map and deny all undefined regions. As well as being good for security, it also helps find out-of-bounds write bugs, and ensures you can't accidentally ship an out of date memory map.
I think you're overestimating how granular the memory mappings are (or how isolated the debug registers are). They're usually used to control access on a peripheral level, not to individual registers within a peripheral.
For Wi-Fi–only devices, the Messages app is hidden.
For devices with Wi-Fi and cellular, the Messages app is still available, but only the SMS/MMS service can be used.
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.>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, can't really remember as that was several years ago).
With Continuity, you can send and receive SMS/MMS messages on iPad using the cellular connection on your iPhone.
If it's not shown in Apple's Messages app, maybe it was a carrier-specific app?
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.
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.
But it might also be a backdoor, intended or not.
Mere differences in timing could have indicated the address was a valid address, and then the hash could perhaps have been brute forced too since it is effectively a 20 bit hash.
The fact the attackers didn't know that Boolean expression suggests they reverse engineered it rather than had documentation.
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.
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.
The later works when you are not as big as Apple. When you are as big as Apple, you are a very hot target for attackers. There is always the effort vs reward when it comes to exploiting vulnerabilities. The amount of effort that goes into all this is worth thousands of dollars even if someone is doing it just for research. If I was doing this for some random aliexpress board it would be worth nothing and probably security by obscurity would mean no one really cares and the later part works here. But I wonder what Apple is thinking when they use obscurity cause people must start working on exploiting new hardware from day 1. You literally can get one on every corner in a city these days. Hardware Security by obscurity for example would be fine for cards sold by someone like nvidia to only some cloud customers and those are then assumed obsolete in a few years so even if someone gets those on eBay the reward is very low. iPhones on the other hand are a very consumer device and people hang on to their devices for very long.
Reminder to reboot your iPhone at least weekly if you are concerned about this kind of attack.
with the Hard Reset key sequence, https://www.wikihow.com/Hard-Reset-an-iPhone
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.
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.
Did the systems software developers know about these registers?
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.
This vulnerability is they key vulnerability without which all the exploit chain would be useless.
[1] https://securelist.com/operation-triangulation-the-last-hard...
When I tried out lockdown mode out of curiousity, I found that it was aggressive about blocking PDF viewing. I quickly bailed on it because I often read research papers on the web, and it switched them from view to download.
> 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.
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.
Either a third party app would still use the same vulnerable frameworks as iMessage, or they would re-implement them potentially with more vulnerabilities, or just not implement the features, which is what Lockdown Mode gives you.
Browsers are not the only thing concerned here, there are many sectors impacted by this philosophy. Qubes-OS for Linux Distributions, replacing containers (and especially Docker) with daemon-less or even MicroVM (Firecracker, Podman, ...). I'm sure there are also heavily sandboxed clients for Matrix, SMS or Emails.
And being open source hasn’t prevented Android from being much more vulnerable to these kinds of exploits.
They’re even working on an embedded subset for embedded devices so things like microcontrollers like battery management, the Secure Enclave etc. can run it.
2-3 million dollars is pocket lint to people conducting serious business, let alone governments. It is at best okay if you are conducting minor personal business. This ignores the fact that attacks at the 2-3 million dollar range are trivially wormable. If you had actual cause to hack every phone you are only incurring marginal cents per attack. Even relatively minor attacks like targeting 10,000 people are less than one phone of cost per attack.
I don't know. $2-3m for reading code in Ghidra and throwing stuff at a wall until something sticks? Maybe some fuzzing, etc.
I get that you theoretically could find an exploit that for example, you send to 100 known wealthy people, and with it you steal saved cookies + device IDs from financial apps and then try to transfer their funds/assets to an account you control but...
Could you really pull that off 100 times before Apple catches on?
I guess you could... easily... now that I think about it.
Quite the cost in my eyes...
----
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.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.
From the articles at the above link...
C&C domains
Using the forensic artifacts, it was possible to identify the set of domain name used by the exploits and further malicious stages. They can be used to check the DNS logs for historical information, and to identify the devices currently running the malware: addatamarket[.]net backuprabbit[.]com businessvideonews[.]com cloudsponcer[.]com datamarketplace[.]net mobilegamerstats[.]com snoweeanalytics[.]com tagclick-cdn[.]com topographyupdates[.]com unlimitedteacup[.]com virtuallaughing[.]com web-trackers[.]com growthtransport[.]com anstv[.]net ans7tv[.]net
What I dislike is that it applies to all devices in your iCloud profile, and is overall pretty intrusive/annoying. Best practice if you're going to use it is probably to have multiple iCloud accounts (maybe in a "family" for license sharing), and Lockdown Mode one of them for the more secure devices. I tried using it for all of my devices last year and it was pretty unusable.
(Main pain point was how it handles unsecure wifi networks; I consider ~all networks insecure regardless of wifi encryption, but not being able to save or otherwise autoconnect to a hotel network with an iPad with nothing on it, etc. was the last straw. With a decent travel router it's fine.)
Since they're supposed to be disabled in production, what would be their point?
I'm no electronic engineer, but isn't it best for them to be fast and simple, to reduce the chance that they cause interference themselves..?
And isn't it strongly unlikely that an attacker in the supply chain (TSMC??) would be able to reliably plant this in all Apple chips from the A12 to the A16 and the M1 ??
From https://securelist.com/triangulation-validators-modules/1108...
4-year campaign backdoored iPhones using advanced exploit - https://news.ycombinator.com/item?id=38784073
(We moved the comments hither, but the article might still be of interest)
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?)
The evidence clearly indicates otherwise…
"We already know Apple cooperated with the spy agencies behind the publics back"?
I’m definitely not defending Apple to be clear. I just believe facts matter, especially when it involves security topics. Parroting around misleading and/or straight false statements related to security topics does nobody any good.
If they cooperate that's good and convenient, but that does not mean the intelligence service will not set in place contingencies for if the other side suddenly decides not to play ball anymore.
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...
Told you so.
edit: The fact that this obvious statement gets upvoted above the apple backdoor on 22:40 of the talk also says alot.
edit1: https://imgur.com/a/82JV7I9
This is getting ridiculous. How many iMessage exploits have there now been via attachments? Why aren't Apple locking down the available codecs? Why isn't BlastDoor doing its job?
This is really disappointing to see time and time again. If a simple app to send and receive messages is this hard to get right, I have very little hope left for software.
Apple really needs a paranoid mode
And even better, there are plenty of old Android phones out which will be vulnerable to various exploits because of weak OTA update support policies.
Also, there are plenty of old iPhones that do not receive updates anymore and are just as vulnerable so I’m not sure why you needed to get that in.
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?
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.
…the color isn’t the problem. It’s shorthand for the real underlying issues
"Okay well, now that we're launching an alternative to SMS, how will we distinguish iMessage messages from regular SMS messages?"
"Hm, well, SMS messages are green, so what if we picked another color?"
"Yeah okay, blue? ¯\_(ツ)_/¯"
"Sounds good, mock it up and send it to the engineers"
edit: The reason for picking green originally was probably because all the "communication"-related apps had a green color scheme, including Messages. This persists today — the app icons for Phone, Messages, and FaceTime are all green.
Nvidia has a very similar green man bad syndrome going on too. As the amount of time a HN discussion on Nvidia increases, the probability of mentioning that Linus said “fuck you nvidia” approaches 1, even though it’s irrelevant to a topic, or that he's a mercurial asshole who's said a whole lot of things.
The casual fanboyism disrupts all discourse on these topics because there’s a large minority of users who have adopted what PG describes as “hater-ism” and allowed it to dominate their thinking on a topic. Negative parasocial attachment is the same process as positive parasocial attachment and just as problematic, but largely never called out.
http://www.paulgraham.com/fh.html
In short: lotta fanboys on these topics who don't even realize they're fanboys/adopting fanboy frames, because they don't realize that anti-fanboys are still parasocially attached too. And we've casually accepted the low level of discourse on these topics, and it pollutes the whole discussion of a lot of interesting topics because of who's doing them.
Disabling iMessage would fall back to SMS, allowing messages to be snooped / modified in transit.
Hopefully they’ll also have a way to disable RCS, since it allows attackers to modify messages, and also has a larger implementation attack surface than SMS.
"Most message attachments are blocked and some features are unavailable."
iMessage with blue bubbles still works in Lockdown Mode. I think GIFs don't display properly and certain other attachments, but I can share photos, audio clips and video so I otherwise don't really notice that Lockdown Mode is enabled.
> the unknown attackers kept their campaign alive simply by sending devices a new malicious iMessage text shortly after devices were restarted.
Rate limiting phishing attacks is certainly a useful security feature, but it does nothing to protect against targeted attacks.
It can be disabled via Apple Configurator, https://news.ycombinator.com/item?id=38785311
But browser exploits require the user to visit an infected website, which is much tougher. If I recieve an email or sms with "visit applesupport.info" I'm not going to click it.
Apple has had so many zero-click exploits in iMessage, yet they insist that you have to use Lockdown mode to do anything about it, and then proceed to bundle Lockdown mode with lots of potentially unwanted behavior.
I don't think there's any way to claim that Apple is just doing whats in the customer's best security interest.
Me deciding to ride the subway to work for free is a user's choice, but that doesn't mean it's right. Using infrastructure for free because I feel like it is certainly my choice but I can't justify anger when someone makes me pay to use it since I should have paid in the first place. Currently Apple doesn't run iMessage as an open standard so it runs in "authorized riders only" mode.
>I don't think there's any way to claim that Apple is just doing whats in the customer's best security interest.
This isn't what I claimed. I claimed Apple treated unauthorized 3rd party access to their infrastructure as a security risk and worked to shore up that risk. As you pointed out, there have been plenty of zero-click exploits in iMessage. Limiting the devices sending iMessages increases security. I believe Apple doesn't allow iOS VMs in general for the same reason.
Your question assumes two things: (1) That Apple intentionally leaves vulnerabilities in the stack, and (2) that Tim Apple is occasionally willing to share this candy with governments.
Having worked at Apple, I don't believe (1) can be true. Not only is it extremely unlikely that it could be kept a secret, but Apple's thing is "obsessive control", a mindset borne of organizational PTSD which originated with its near-death experience in the mid-to-late 90s. The Apple I know would not risk intentionally leaving back doors unlocked for enemies to find and leverage.
As for (2), the existence of a "Binder of Vulns" by nation-states would expose Apple to existential risk. It's possible that it could be kept secret within Apple's walls if it were never used, but once shared with a government it could not be contained. The splash damage of such a discovery could easily kill Apple.
Knowledge of a binder of vulnerabilities is perhaps one of the greatest secrets that must be protected. Wikileaks releasing the Vault 7 leak was the death knell of Julian Assange. It proved such a binder exists in great detail.
I don't hate Apple, but assuming they can't be reached, seems naïve.
Like how the NRO used to design and launch satellites that cost more than aircraft carriers but are now working closely with private companies like Maxar to find more economical solutions.
https://www.maxar.com/press-releases/nro-awards-maxar-a-10-y...
Kapersky reaches no such conclusion. That's from an FSB release.
that said, dedollarization is unlikely even in the mid-term https://www.noahpinion.blog/p/threats-to-the-dollar-are-just...
That is one opinion. We can already see China and Japan selling off their US bonds and the BRICS countries are working on solutions to get off the dollar with high priority.
It depends on your exports. If your exports have cheaper alternatives, then a weak dollar is good.
If your exports are high utility and have no cheaper alternative, then a strong dollar is better.
Maybe this one will be more interesting https://www.noahpinion.blog/p/brics-is-fake
Payment systems are already here that avoid the dollar. (From the extremely simple blockchainish digital-synthetic currencies like Ripple XRP to the classic SWIFT-like China's CIPS[1].) And these are already in use. After Russia got thrown out of SWIFT they are now basically using CIPS. (Of course they also have their own version, SPFS. "Coincidentally" its development started in 2014.)
However, on the CIPS wikipedia page you can notice that the important things needed for the actual settlement is a boring list of stuff about each member institution (account numbers, settlement procedure description, credit rating). And each member institution has its own rules about what transfers to accept. And of course in hard times trust is in low-supply, transfers start to get manually reviewed, tolerances start to decrease, everyone starts to hoard good money, thus only bad money remains.
All in all, the important thing is that there's no magic system that can handle payments without the usual institutional-societal framework. (Well, of course there are blockchainish things. For example Visa is doing something on Solana. And Solana is pretty fast and cheap. And a horror show to develop smart contracts on, but that's not really relevant now, and not important for Visa or Russia/China/banks, because they don't care much about the ethos of decentralization, they just want to have something quasi-trustless, fast, and cheap.)
> If that trillion is halved to $500B, what happens?
It depends, but, well ... nothing really. Most of money is already at rest. It represents exactly that stuff you got for it. It represents all the wealth created. It was printed to keep inflation around 1-2%. If it disappears in some computer system people will start to scratch their heads, but the ratios will remain mostly the same, so purchasing power and wages/salaries will not change.
That said if some bank decides to flood the market with cheap US Treasury bonds nothing happens. That's already in USD, the bank loses on the transaction a lot. And a lot of these reserves are in bonds.
Okay, what happens if that bank asks for the cheap bonds not USD, but let's say rubels? Okay, they will end up with a shitton of rubels. The exchange rate shifted, but nothing actually happened, sure the ratio of flow of goods and services will adjust as the overpriced rubels will be exchanged for a bit more goods and services than without this huge transaction. But what does this lead to? More exports from the typical exporters. It's not particularly good for anything that's hard to scale up, it will just result in price inflation. And then eventually the exchange rate will go back to reflect the actual flow of goods and services.
[1] https://en.wikipedia.org/wiki/Cross-Border_Interbank_Payment...
You recognize impact to exchange rates when one currency is in more demand than another. If this causes an increase in exports sold in the devalued currency, rates could eventually stabilize, but that depends on many things. Those exports could be gold in our treasury, US land, and factories. Those assets that are fixed in place are only valuable to a foreigner if they can be assured they will not be confiscated.
I know this is simplistic, but let's walk through this flow. I print up a $100 bill and give it to China for a washing machine. China will take it because they need it to buy a barrel of oil from Saudi Arabia. That $100 floats around in the world perhaps never returning as long as others accept and use it. If Saudis start accepting Yuan in payment for oil, China does not need that $100 bill as much. They start reducing their dollar reserves and US bonds. They use those dollars to buy the gold, US land, and factories. The US then has a lot of dollars but not as many assets. The dollars become less valuable because we have so many of them but not as much demand for them. If they are afraid of US sanctions, China will be less inclined to buy assets that could be seized and so the currency is less useful to them.
Admittedly there are many other factors. We will need to see how it plays out.
What if they want to buy oil, which happens to be sold by the Saudis, who want 100 USD for it. They can do it, or they can print more yuan, and use that to buy more USD on some exchange. (And they did it a lot, to keep the yuan artificially low. That's basically half of how they ended up with this huge reserve.)
And since their inflation was around 2 percent since 2010, and currently even negative unfortunately, they can print a lot.
And this is how economic development and exchange rates connect. One man's trade deficit is another's reserve basically. As long as there's some slack in economies (mostly some unemployment metric is used as a proxy for this) it makes sense to spend. (Otherwise it'll just push up prices more, ie. lead to inflation. Hence the very technical sounding name of NAIRU, Non-Accelerating Inflation Rate of Unemployment, I think hands down the worst name for any concept over many fields.)
If China starts using its reserves to buy US assets, that leads to a lot of USD getting back into the US economy, it's like a stimulus. It would push up prices of course, the Fed would increase interest rates, maybe it would even start fiddling with some other knobs (it could increase the fractional reserve ratio, it could increase interest paid on reserves, or interest paid on excess reserves).
> If they are afraid of US sanctions, China will be less inclined to buy assets that could be seized and so the currency is less useful to them.
Yes, and one read of the belt and road initiative is basically this, instead of giving it to citizens to spend, they tried to use it for geopolitical/colonialist/mercantilist projects.
All in all, my understanding is that using their huge reserve to cause some crisis would be a zero-trick pony (because after 2008 and the recent bank crisis, and the Russian sanctions implementations the West seems capable of handling speedbumps), and a slow decoupling would be good anyway. (As it would help the non-finance sectors of the US.)
--> https://www.reuters.com/breakingviews/russian-war-economy-is...
If you would truly believe what you say, you should convert all your savings from dollar to rubles. No serious economist would think that doing so would be a masterstroke though.
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.
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.
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.
I don't know jack about hardware but it would seem obvious that when one designs a chip, you make sure it does not have 'unknown hardware registers' or unknown anything when you get it back from the manufacture.
This makes everything written on this page worthless...
>Prevent anyone except you from using your devices and accessing your information. https://www.apple.com/privacy/control/
The article doesn’t state that. It says it’s undocumented for the security researchers.
well you are in trouble then. all of modern hardware have such hidden parts in them, and are most of the time referenced as "undocumented" instead of "unknown". I know this seems pedantic, but from a public eye, anything undocumented is unknown. what makes those special however, is those are not used at all by public software, thus truly unknown as one can only guess their use or even their mere existence.
Either Apple or Arm has employees that know what these registers do. They are likely used for debugging and/or testing.
A lot of those registers can do very interesting things, since e.g. fault-injection is an important part of testing. A security-minded implementation will allow these to either be fused off or disabled very early in the boot process. The latter is probably more common, and any disconnect between the hardware and software side can cause this step to get missed.
Could have stopped writing right there.
An official visits the headquarters, and informs that certain employees need to be hired at certain departments “to help with national security”. End of story.
What even makes people think that executives whose job is to deal with everyone in order to “do business” are their long distance friends, or some kind of punks who'd jump on the table and flip birdies into faces of people making such an offer?
They have the best possible insight into the hardware and software at all stages I should think.
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.
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 describe this feature and how the attackers took advantage of it, it all comes down to this: they are able to write data to a certain physical address while bypassing the hardware-based memory protection by writing the data, destination address, and data hash to unknown hardware registers of the chip unused by the firmware.
And finally does Lockdown mode mitigate any of this?
Because Apple is busy fixing exploits discovered by Citizenlab. /s
But hey, Apple is secure.
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.
Asshats
Apple, like any other USA company, has to abide by the laws and doing what they are told to do. If that means hardware backdoors, software backdoors, or giving NSA a heads up over a vulnerability during the time it takes to fix said vulnerability (to give time for NSA to make good use of it) then they will.
Only someone with great sway (like Jobs) could have resisted something like this without fear of the US Govt coming after him. His successor either didn’t have that passion for privacy or the courage to resist working with the NSA.
Anyone, anywhere with an iPhone will be vulnerable to NSA being able to break into their phone anytime they please, thanks to Apple. And with Apple now making their own silicon, the hardware itself will be even more of a backdoor.
Almost every single staff member at Apple will be none the wiser about this obv and unable to do anything about it even if they did - and their phones will be just as fair game to tap whenever the spies want.
I am speculating. But in my mind, it’s really quite obvious. Just like how Prism made me win an argument I had with someone who was a die hard Apple fan and thought they would protect privacy at all costs… 6 months later, Snowden came along and won me that argument.