48 ms·

Operation Triangulation: What you get when attack iPhones of researchers

• nothercastle 3y ago
  State actor attacks on another state actor. Incredible sophisticated and just goes to show you that it basically can’t be defended against
  • whartung 3y ago
    It can be defended against. The detail is that the only way to harden those defenses is to toss it out in the world and let folks poke holes in it. 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.
    • hnburnsy 3y ago
      >It was complex because of all of the defenses put in place by Apple and others. 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/ https://www.apple.com/privacy/control/
      • dagmx 3y ago
        You’re assuming the registers are unknown to the chip designer. The article doesn’t state that. It says it’s undocumented for the security researchers.
        • hnburnsy 3y ago
          good point
      • tuetuopay 3y ago
        > 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. 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.
        • adrian_b 3y ago
          "Undocumented" as used by hardware manufacturers is an euphemism for "secret".
          • deleted 3y ago
            [deleted]
          • nl 3y ago
            It's actually not at all. Secret means "do not disclose". Undocumented can include that set but also a bunch of other things.
      • aidenn0 3y ago
        > 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. 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.
    • ogurechny 3y ago
      > Compromise an employee? 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?
  • kornhole 3y ago
    However this one seems to have been coordinated with Apple. A nonprofit nonaligned independently managed project could be more immune to pressures of the national security apparatus. I think it is incredibly naïve to think that the largest US corporation does not cooperate. This is why I keep donating to GrapheneOS.
  • deleted 3y ago
    [deleted]
• gustavus 3y ago
  [flagged]
  • FergusArgyll 3y ago
    > “Due to the closed nature of the iOS ecosystem, the discovery process was both challenging and time-consuming, requiring a comprehensive understanding of both hardware and software architectures... " -Kaspersky researcher Boris Larin 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"
    • manuelabeledo 3y ago
      To be fair, that was just Kaspersky taking a jab at Apple, after being absolutely gutted by hackers because of their own poor security posture.
      • saagarjha 3y ago
        I don’t really see anything wrong with their security posture here.
        • gghffguhvc 3y ago
          Article says large data files were sent from device to servers. Perhaps they could have configured their networks to detect/block this part.
          • saagarjha 3y ago
            This would have a very high false positive rate.
          • jacooper 3y ago
            They did, because they detected it using their network monitoring stack.
• pushcx 3y ago
  It’s quite unfortunate that Apple doesn’t allow users to uninstall iMessage, it seems to be the infection vector for advanced threats like this, NSO group, etc. Presumably it’s to avoid the support burden, but they could gate it behind having Lockdown Mode enabled for a week or something to shake out the vast majority of mistaken activations.
  • munk-a 3y ago
    They gotta, gotta, have those blue bubbles. Some teenagers fight to get an overpriced phone solely to avoid the deep deep shame of having a green bubble when chatting. 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.
    • bdcravens 3y ago
      They've already announced that they will be adding RCS support.
      • munk-a 3y ago
        ... And they've already announced[1] that they will be retaining the exclusive blue bubble for iMessage messages for... reasons? The green/blue bubble distinction will continue even when there is no technical difference between messages. 1. https://mashable.com/article/apple-rcs-support https://mashable.com/article/apple-rcs-support
        • givinguflac 3y ago
          There is a technical difference though- the current RCS standard doesn’t have end to end encryption.
        • TimeBearingDown 3y ago
          Yep, why would they drop it? It’s especially egregious as Apple disregards its own human interface guidelines to make green bubbles excessively low-contrast. Very intentional.
• hnburnsy 3y ago
  >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 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?
  • hulitu 3y ago
    > Why isn't Apple detecting the spyware\malware payload? If only Apps approved by Apple are allowed on an iPhone, detection should be trivial. Because Apple is busy fixing exploits discovered by Citizenlab. /s But hey, Apple is secure.
    • deleted 3y ago
      [deleted]
  • docfort 3y ago
    I think Lockdown would help here since it doesn’t decode message attachments. So the original link in the chain (decoding a PDF) would be impossible. 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.
  • saagarjha 3y ago
    This chain isn’t delivered via an app, it is sent through iMessage. The checks for “only apps approved by Apple” are not relevant if you exploit your way past them.
• kornhole 3y ago
  Who had motive to target Russian government officials, knowledge of the attack vectors, history of doing so, and technical and logistical ability to perform it leads Kaspersky and myself to the only rational conclusion: that Apple cooperated with the NSA on this exploit. I assume they only use and potentially burn these valuable methods in rare and perhaps desperate instances. I expect the Russian and Chinese governments' ban on use of Iphones will not be lifted and expand to other governments. Similarly to how the sanctions have backfired, this tactic will also backfire by reducing trust in Apple which is the core of their value proposition.
  • deleted 3y ago
    [deleted]
  • CharlesW 3y ago
    My adjacent conspiracy theory is that the NSA and other state agencies do both original research and pay hackers for exploits that Apple hasn’t yet discovered.
    • kornhole 3y ago
      but why pay hackers to try to find a backdoor when you can just walk in the front door and use the carrot and stick to get what you want?
      • CharlesW 3y ago
        Here's my serious answer that still works if you hate Apple. 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.
• WalterBright 3y ago
  The extra hardware registers might have been discovered by examining the chip itself. One could find where the registers were on it, and notice some extra registers, then do some experimenting to see what they did.
  • smith7018 3y ago
    Do you know how this is possible? Would decapping the SoC or taking an xray of it provide a physical map of the registers?
    • mhh__ 3y ago
      You can find the register file relatively easily because it's a block of memory that's the same on each core but isn't cache, but it isn't a 1:1 map from architectural registers that we would recognize: the chip is designed to find an optimal allocation of slots in the register file to runtime values.
      • saagarjha 3y ago
        That’s where the GPRs would live. There’s no reason you have to put weird MMIO there too.
      • pm215 3y ago
        These particular registers aren't part of the CPU proper anyway, so not in the register file in that sense -- they're mmio mapped, and https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/ https://securelist.com/operation-triangulation-the-last-hard... concludes that they are "a block of CoreSight MMIO debug registers for the GPU coprocessor".
        • mhh__ 3y ago
          Indeed, my bad for only skimming.
  • mhh__ 3y ago
    Maybe, but chips already have vast, vast, quantities of physical registers in a big blob. Assuming it wasn't a lucky guess, timing attacks are often used to find this stuff.
• anotherhue 3y ago
  More important than getting their newly found exploits, you get to know which of yours might be compromised. Prevents counterintelligence.
• hcarrega 3y ago
  Theres a talk on ccc today
• WhackyIdeas 3y ago
  It’s kind of simple imo. Apple is an American company and after Jobs died, Apple quickly signed up to working with the NSA and enrolled in the Prism programme. 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.
  • onetokeoverthe 3y ago
    [dead]
• soupdiver 3y ago
  https://streaming.media.ccc.de/37c3/relive/11859 https://streaming.media.ccc.de/37c3/relive/11859
  • contingencies 3y ago
    Begins @ 27:21 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.
    • mike_hearn 3y ago
      It's really a pity they explain all the mistakes that helped the malware be detected.
      • halJordan 3y ago
        It's not, it really isnt. Honestly just apply this mentality to one other scenario to test the waters. We should stop publishing yara rules because it flips our hand to the malware makers? It's nonsense to even say.
• sampa 3y ago
  [flagged]
  • chatmasta 3y ago
    Reading between the lines of TFA, it seems the researchers may also suspect that to be the case: > 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.
    • sampa 3y ago
      well of course nobody would have NSA_friendly_override() in the source plausible deniability is essential in such cases, hence the term bugdoor
      • halJordan 3y ago
        This is the same conspiracy mindset of flat earthers, and you deserve your own netflix mockumentary over it. Because a bug is a bug, it's very nature means you cannot prove it isn't malicious, therefore you take it as positive proof of malice and sit pretty bc no one can prove a negative.
        • LanzVonL 3y ago
          Are you posting from Eglin AFB? Which outfit are you with?
        • 3y ago
• Muehe 3y ago
  For those interested in the talk by the Kaspersky researches, the cleaned video isn't uploaded yet but you can find a stream replay here: https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-4227-baae-aece190e9de5 https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422... (talk starts at minute 26:20)
  • Sweepi 3y ago
    ...and its online: https://media.ccc.de/v/37c3-11859-operation_triangulation_what_you_get_when_attack_iphones_of_researchers https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...
• mike_hearn 3y ago
  That's pretty astonishing. The MMIO abuse implies either the attackers have truly phenomenal research capabilities, and/or that they hacked Apple and obtained internal hardware documentation (more likely). 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.
  • sampa 3y ago
    or Apple just implemented this "API" for them, because they've asked nicely
    • chatmasta 3y ago
      Or they have assets working at Apple... or they hired an ex-Apple employee... etc. 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.
• neilv 3y ago
  > 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. Did the systems software developers know about these registers?
• fragmede 3y ago
  [flagged]
  • deleted 3y ago
    [deleted]
• transpute 3y ago
  iMessage can be disabled by local MDM for supervised devices, via free Apple Configurator in macOS app store, https://support.apple.com/guide/deployment/restrictions-for-iphone-and-ipad-dep0f7dd3d8/web https://support.apple.com/guide/deployment/restrictions-for-... 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. SMS/MMS messages and non-emergency cellular radio traffic can be disabled by a SIM PIN, e.g. when using device for an extended period via WiFi.
  • fishywang 3y ago
    We purchased an iPad with cellular, with the plan to put my home country's sim card in it so I can still receive SMS (as most of the banks there still requires SMS verification when you login), and it turns out that iPad with cellular does not really show you SMS's that's not from the carrier of the sim card.
    • transpute 3y ago
      > 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-messages-from-an-ipad/ 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.
      • fishywang 3y ago
        Apple's own user guide (https://web.archive.org/web/20201223140550/https://support.apple.com/guide/ipad/set-up-messages-ipad70482978/ipados 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, can't really remember as that was several years ago).
• jeffreygoesto 3y ago
  Some agencies will be very sad now...
  • barryrandall 3y ago
    Those will be the most delicious tears wept in all of 2023.
    • cald0s 3y ago
      Not really, the decision to do this is calculated. I'm sure many more tears would be shed by those affected if they knew they were compromised...
• vGPU 3y ago
  [flagged]
  • TaylorAlexander 3y ago
    Yeah people keep talking about reverse engineering but it’s just as real a possibility that this was simply engineered to be there. Apple and the government made a big public show about the San Bernardino iPhone situation[1] but that could have easily been a cover to convince people the government can’t get in to iPhones - because eventually the government dropped the court case, got in anyway, and the whole thing was quickly forgotten. 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-case-dropped-san-bernardino-iphone https://www.theguardian.com/technology/2016/mar/28/apple-fbi...
    • jrexilius 3y ago
      "the government" isn't really a single entity. domestic LE and foreign intelligence have different laws and processes enforced by the constitution (thankfully). Its certainly reasonable that domestic LE really can't force Apple to handover US citizens data, while foreign intelligence services can effect supply chain attacks, back-dooring and other methods not permitted for US citizens..
    • JumpCrisscross 3y ago
      > that could have easily been a cover The problem with conspiracies is everyone involved knows it’s a secret. If you’re the CIA, it’s much less risky to compromise a chip design engineer than have everyone from the CEO down at Apple in on the plant.
      • TaylorAlexander 3y ago
        Maybe but then again what’s another secret when at a high level these firms are already very secretive. It’s not apple but I think a lot about how Eric Schmidt of google was directly meeting with US military officials and talking about how important US defense was. You can end up with a situation where the chip designer and some higher up both know what is happening and the higher up is there as a check to provide cover in case the chip designer is caught up in suspicion. (“No we asked for this for the manufacturing team.” Kind of thing.) Of course this is all conjecture with no evidence and I understand why we don’t want to spend much energy on discussions we can’t confirm, but at the same time it is frustrating when the default assumption is that apple had no knowledge about this. The truth is that we don’t know and likely will never know.
• xvector 3y ago
  Does Lockdown Mode prevent agains this?
  • 542458 3y ago
    I think lockdown drops most iMessage features, so I would suspect the answer is yes. But as far as I can tell, lockdown prevents use of mdm, so it might be a net negative for security… instead, using the mdm policy that disables iMessage might be preferable.
    • rdl 3y ago
      Lockdown prevents new enrollment in MDM/adding profiles, but you can use an MDM you're already enrolled in. It's pretty good from a security perspective. 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.)
    • Obscurity4340 3y ago
      You can still supervise which allows for that all the same, IIRC
  • halJordan 3y ago
    It likely does. Lockdown mode stops most ios auto-processing wrt to message attachments and this was delivered via a message attachment.
• stefan_ 3y ago
  Maybe I'm too dumb to find it on this page but if you are looking for the actual recording instead of a calendar entry in the past, it's here (a stream dump for now, fast forward to 27 mins): https://streaming.media.ccc.de/37c3/relive/11859 https://streaming.media.ccc.de/37c3/relive/11859
• patrickhogan1 3y ago
  Knowing more about the exfiltration component where it sends data to a remote server would be helpful. According to the article it’s sending large audio microphone recordings. I assume a company like Kapersky would explicit deny all outgoing network connections and then approve one by one.
  • hnburnsy 3y ago
    There is a series of posts on this including one that details the malware payload... https://securelist.com/trng-2023/ https://securelist.com/trng-2023/
  • twobitshifter 3y ago
    yeah, I’m wondering the same. Maybe they can’t point a finger at who did it, but there were no clues on the exfiltration?
    • hnburnsy 3y ago
      > yeah, I’m wondering the same. Maybe they can’t point a finger at who did it, but there were no clues on the exfiltration? 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
• Despegar 3y ago
  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"?
  • stavros 3y ago
    What do you mean "no real progress"? The price used to be $100.
    • Despegar 3y ago
      I mean progress from today.
      • stavros 3y ago
        I don't understand what you mean. They've always been making progress, driving the price up. They can just keep doing what they're doing, and there will be progress from today.
        • Despegar 3y ago
          Is that actually true? Has the price of these exploits been going up year after year, or has it topped out at some level?
          • westhanover 3y ago
            Yes it has been going up.
          • saagarjha 3y ago
            It’s been going up consistently. The number of groups that can field a full chain these days is dwindling.
• londons_explore 3y ago
  What are the chances this MMIO register could have been discovered by brute force probing every register address? 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.
  • londons_explore 3y ago
    Looking at that sbox implementation, I can't believe it was implemented as a lookup table in the hardware of the chip - there must be some condensed Boolean expression that gives the same result. The fact the attackers didn't know that Boolean expression suggests they reverse engineered it rather than had documentation.
  • chatmasta 3y ago
    It looks like the registers could have been identified fairly easily via brute force. They're physically close to documented GPU registers, and accessing them triggers a GPU panic, which is how the researchers attributed them to the GPU component. The attackers could have used that same test to identify the existence of the registers. 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.
• kevinwang 3y ago
  Wow, that's amazing. I wonder if attacker like this feel unappreciated since they can't take credit for their work.
  • belter 3y ago
    Public key cryptography was developed in 1970s at GCHQ but that was classified.
• cedws 3y ago
  >This attachment exploits vulnerability CVE-2023-41990 in the undocumented, Apple-only TrueType font instruction ADJUST for a remote code execution. This instruction existed since the early 90’s and the patch removed it. 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.
  • throwoutway 3y ago
    If I were an embassy employee (covert or overt), I'd want zero iMessage features beyond ASCII and the thumbs-up/down reactions. No attachments, no GIFs, no games, no Apple Pay, no easter eggs, no rich text Apple really needs a paranoid mode
    • et1337 3y ago
      Lockdown mode exists: https://support.apple.com/en-us/105120 https://support.apple.com/en-us/105120
      • xvector 3y ago
        you can't use this with MDM unfortunately, so useless for govts, corporations, etc.
  • nvm0n2 3y ago
    iOS has a reputation for having the best security, but how many times have Android/WhatsApp had these sorts of silent-instant-root exploits via invisible messages? I don't remember it happening. Maybe the strategy of writing lots of stuff in Java is paying off there.
    • azinman2 3y ago
      What’sapp has had exploits. See https://gbhackers.com/new-whatsapp-0-day-vulnerabilities/amp/ https://gbhackers.com/new-whatsapp-0-day-vulnerabilities/amp...
• LanzVonL 3y ago
  Isn't the most obvious answer that Apple, like other US tech firms such as Google, simply creates these wild backdoors for the NSA/GCHQ directly? Every time one's patched, three more pop up. We already know Apple and Google cooperate with the spy agencies very eagerly.
  • jsjohnst 3y ago
    > We already know Apple and Google cooperate with the spy agencies very eagerly. The evidence clearly indicates otherwise…
    • Aerbil313 3y ago
      Ahem, Snowden, PRISM anyone?
      • jsjohnst 3y ago
        Ahem, you mean you have a single example, from a decade ago, one where Apple was hardly a key player (hence why Apple didn’t sign onto PRISM until half a decade after Yahoo, Microsoft, Google, et all), as conclusive evidence of “eagerness to partner with spy agencies”, despite numerous public cases where they’ve done the opposite… got it!
        • smallnix 3y ago
          That makes sense, would you agree to the revised statement: "We already know Apple cooperated with the spy agencies behind the publics back"?
          • jsjohnst 3y ago
            No, I won’t agree to context free blanket statements which are specifically worded to imply something which is simply not provably true, especially given evidence to the opposite. If you knew anything about PRISM at all, even the technical details publicly available with the minimalist of effort on your part, you wouldn’t be asking.
• I_Am_Nous 3y ago
  >Although infections didn’t survive a reboot Reminder to reboot your iPhone at least weekly if you are concerned about this kind of attack.
  • transpute 3y ago
    > reboot your iPhone at least weekly with the Hard Reset key sequence, https://www.wikihow.com/Hard-Reset-an-iPhone https://www.wikihow.com/Hard-Reset-an-iPhone
    • wyre 3y ago
      Sorry for the lay question but what’s the benefit of the hard reset over a general restart?
      • transpute 3y ago
        [dead]
      • Mattwmaster58 3y ago
        Layperson here so just guessing. If not using the hard reset method, the exploit might fake the reboot sequence to maintain its own persistence. AFAIK, a hard reset is built in hardware and thus impossible to fake.
      • carleton 3y ago
        I believe they’re assuming that malware can do a pretend reboot whereas the hardware keystroke can’t be faked.
  • x1sec 3y ago
    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.
• ThinkBeat 3y ago
  Attack by CIA/NSA? They have the best possible insight into the hardware and software at all stages I should think.
  • dannyw 3y ago
    It targeted Russian embassy officials, and with this level of sophistication, so it’s quite obviously NSA/etc.
    • azinman2 3y ago
      Russia has made more enemies than just the U.S.
  • deleted 3y ago
    [deleted]
• guwop 3y ago
  Crazy!
• mb4nck 3y ago
  At least the first version of the recording is now up: https://media.ccc.de/v/37c3-11859-operation_triangulation_what_you_get_when_attack_iphones_of_researchers https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...
• londons_explore 3y ago
  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.
  • londons_explore 3y ago
    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 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.
    • tedunangst 3y ago
      Like a CRC? I'm reminded of the the Broadcom compression algorithm that required tedious reverse engineering, or a look at the Wikipedia page with sample code.
    • the-rc 3y ago
      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.
• DantesKite 3y ago
  Steve Weis on Twitter described it best: “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=E3U2EI7EXIhlBQmxg6oZ2g https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...
• sweis 3y ago
  The video of the talk is online now too: https://www.youtube.com/watch?v=7VWNUUldBEE https://www.youtube.com/watch?v=7VWNUUldBEE
• luke-stanley 3y ago
  I didn't hear anyone mention fuzzing once. I guess there was probably very specific insider knowledge being made use of and they wanted to point a finger, which is fair enough I guess. I'm just a bit surprised that it has not been mentioned so far in the discussion. Anyhow it seems that a allow-list approach by Apple would have been better than a deny list approach! Literally not checking out of expected bounds!
  • camkego 3y ago
    This is a really good question. 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.
    • cf1241290841 3y ago
      Its one of the major arguments against backdooring systems even if you think this to be acceptable. In the end you create a backdoor for everyone, even if you dont do it as moronic as here. You are the hostile actor.
  • Alex3917 3y ago
    If they were using a deny list, that sounds like an intentional backdoor.
    • luke-stanley 3y ago
      It might just be that they couldn't think of another way to code it though.
• jacooper 3y ago
  This really looks like the NSA just flexing their muscles and their vulnerability arsenal.
  • deleted 3y ago
    [deleted]
  • cf1241290841 3y ago
    And motivate state actors to get their supply chain in check. After all, whats the difference between a secure coprocessor and a silicone bug?
• londons_explore 3y ago
  Coresight is not some backdoor - it's a debug feature of all ARM CPU's. This looks like a necessary extension to coresight to work with Apples memory protection stuff. 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.
  • smallnix 3y ago
    That does not explain the weird hashing.
    • duskwuff 3y ago
      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 https://social.treehouse.systems/@marcan/111655847458820583
      • adrian_b 3y ago
        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 supposition of an intentional backdoor still seems more likely.
        • rst 3y ago
          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...)
          • londons_explore 3y ago
• apienx 3y ago
  Reminder that Lockdown Mode helps reduce the attack surface of your iPhone. It also helps tremendously with detection. https://support.apple.com/en-us/105120 https://support.apple.com/en-us/105120
  • chatmasta 3y ago
    I've had Lockdown mode enabled for a few months. It's great, and not much of an annoyance at all. You do need to be fairly tech-savvy and remember that it's enabled, because sometimes something silently breaks and you need to opt-out of it (which you can do for a specific website, or WebViews within a specific app). And it won't auto-join "insecure" WiFi which can be annoying at a hotel, but frankly it's probably for the best. Also you won't receive texts with attachments in them, which is usually desirable but breaks workflows like activating a new SIM card while traveling (it's possible this was broken for me due to some other setting to exclude texts from unknown numbers). 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?)
• codedokode 3y ago
  I see that one of the steps in exploit was to use GPU registers to bypass kernel memory protection. Does it mean that the vulnerability cannot be fixed by an update and existing devices will stay vulnerable?
  • transpute 3y ago
    https://x.com/alfiecg_dev/status/1740025569600020708 https://x.com/alfiecg_dev/status/1740025569600020708 It’s a hardware exploit, using undocumented registers. It can only be mitigated against, but not fully patched.
  • flakiness 3y ago
    I don't think there is any JIT on GPU and all the code has to go through a host-side kernel call so it should be able to protect the register I guess?
    • saagarjha 3y ago
      The kernel cannot protect against this, in fact the attackers have full read/write control and code execution capabilities to mount this attack. The fix is blocking this range from being mapped using features that are more powerful than the kernel.
  • ipython 3y ago
    The mitigation is that the mmio range in question has been marked as unwritable in the device trees on recent versions of iOS.
• haecceity 3y ago
  This wouldn't be zero click if iMessage didn't parse attachments without user consent.
  • deleted 3y ago
    [deleted]
• cf1241290841 3y ago
  As its about a 37c3 presentation here a comment from Fefe¹ in German https://blog.fefe.de/?ts=9b729398 https://blog.fefe.de/?ts=9b729398 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 https://en.wikipedia.org/wiki/Felix_von_Leitner I guess somebody is going to get fired.
  • saagarjha 3y ago
    Why? Having exploits “burned” is part of the business.
    • cf1241290841 3y ago
      Exploit yes Decade old Backdoors no
      • _kbh_ 3y ago
        > 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 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).
• cf1241290841 3y ago
  Years ago i argued about the danger of pdfs with another account and was told not to be a paranoid nutjob. 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 https://imgur.com/a/82JV7I9
• g-b-r 3y ago
  Are hashes of the data ever used in known chip debugging features? 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 ??
• trustingtrust 3y ago
  >Hardware security very often relies on “security through obscurity”, and it is much more difficult to reverse-engineer than software, but this is a flawed approach, because sooner or later, all secrets are revealed. 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.
• dang 3y ago
  Related: 4-year campaign backdoored iPhones using advanced exploit - https://news.ycombinator.com/item?id=38784073 https://news.ycombinator.com/item?id=38784073 (We moved the comments hither, but the article might still be of interest)
• throwaway81523 3y ago
  Philip Zimmermann a while back was working on a secure phone product called the Black Phone. I tried to convince him that a secure phone should not contain any microphones of any kind. That sounds a bit weird for a phone, but it's ok, if you want to make a voice call, just plug a headset into it for the duration of the call. He wasn't convinced, but this iphone exploit makes me believe it more than ever.
  • x1sec 3y ago
    Perhaps a physical switch that connects or disconnects the electrical signal from the microphone to the handset could be a more convenient approach. There is a photo of Mark Zuckerberg with a cut off 3.5mm jack plugged into his laptop - likely to achieve a similar outcome.
  • fsflover 3y ago
    My phone has a hardware kill switch for mic/camera.
• codedokode 3y ago
  Now I am thinking Kaspersky should not have published this information. What a wrong decision. Instead they should have sold it to Russian government which I am sure could find lot of interesting uses for these "debugging features" and offer a good reward.
  • Klaster_1 3y ago
    Kaspersky are already firmly under the full control of the state, selling anything is redundant. The whole video comes off as a massive flex, giving off the same vibes as athletes representing the country at the Olympics. 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.
• kristofferR 3y ago
  Why would the attackers target Kasperspy employees? Seems like a great way to get your exploit chain exposed
  • youngtaff 3y ago
    Perhaps Kasperspy is doing offensive work for someone?
• Luc 3y ago
  This made me laugh: "Upon execution, it decrypts (using a custom algorithm derived from GTA IV hashing) its configuration [...]" From https://securelist.com/triangulation-validators-modules/110847/ https://securelist.com/triangulation-validators-modules/1108...
• amai 3y ago
  See also the article from Ars Technica in June 2023: https://arstechnica.com/information-technology/2023/06/clickless-ios-exploits-infect-kaspersky-iphones-with-never-before-seen-malware/ https://arstechnica.com/information-technology/2023/06/click...
• MagicMoonlight 3y ago
  That’s going to be a Chinese tool. Knowing the hardware that intimately and having all these convenient undocumented areas to play with is exactly the kind of thing you can put in place if you control the manufacturing.
• Liebnitz 3y ago
  ....
• Liebnitz 3y ago
  >Apple declined to comment for this article.
• joanne123 3y ago
  [dead]