[HN Gopher] 4-year campaign backdoored iPhones using possibly mo...
___________________________________________________________________
4-year campaign backdoored iPhones using possibly most advanced
exploit ever
Author : airstrike
Score : 282 points
Date : 2023-12-27 17:15 UTC (5 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| nothercastle wrote:
| State actor attacks on another state actor. Incredible
| sophisticated and just goes to show you that it basically can't
| be defended against
| whartung wrote:
| 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 wrote:
| >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/
| dagmx wrote:
| 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 wrote:
| good point
| tuetuopay wrote:
| > 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 wrote:
| "Undocumented" as used by hardware manufacturers is an
| euphemism for "secret".
| aidenn0 wrote:
| > 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.
| tedunangst wrote:
| > I don't know jack about hardware
|
| Could have stopped writing right there.
| hnburnsy wrote:
| Agreed
| ogurechny wrote:
| > 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 wrote:
| 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 naive to think that the largest US
| corporation does not cooperate. This is why I keep donating to
| GrapheneOS.
| pushcx wrote:
| 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 wrote:
| 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 wrote:
| They've already announced that they will be adding RCS
| support.
| munk-a wrote:
| ... 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
| givinguflac wrote:
| There is a technical difference though- the current RCS
| standard doesn't have end to end encryption.
| TimeBearingDown wrote:
| 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.
| ioblomov wrote:
| I bought the very first iPhone the day after its release.
| Long before iMessage was introduced, it only supported
| SMS at the time. People forget, but those bubbles, the
| original SMS ones, were green. Blue bubbles showed up
| only when iMessage debuted three years later.
| jtsiskin wrote:
| People use "green bubbles" to just mean "no guaranteed
| delivery or delivery receipts, no read receipts, very low
| quality image and videos, bad support for reactions,
| threaded replies, and group chats".
|
| ...the color isn't the problem. It's shorthand for the
| real underlying issues
| cma wrote:
| The color is a big part of the problem, white on green is
| one of the hardest to read because of the distribution of
| color cone cells in our retinas. Only maybe white on
| yellow would be worse.
| Neil44 wrote:
| They knew exactly what they were doing when they chose that
| nice blue and that cheap looking green.
| sadjad wrote:
| Never forget the icon they used for Windows servers:
| https://i.stack.imgur.com/5rYVr.png
| Red_Leaves_Flyy wrote:
| That's hilarious
| marcellus23 wrote:
| No they didn't, because the green was first in 2007, when
| iPhone only supported SMS. It was 4 years later that
| iMessage launched. The conversation probably went like:
|
| "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? -\\_(tsu)_/-"
|
| "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.
| vultour wrote:
| Teenagers wanting blue bubbles and people looking to
| uninstall iMessage because it's a threat vector are two
| completely disjoint sets of people.
| munk-a wrote:
| Absolutely - but the business interest of wanting to keep
| teenagers on iPhones absolutely would impede Apple from
| allowing users to uninstall the application.
| paulmd wrote:
| Blue bubbles bad syndrome. Gotta bring it up when ever
| humanly possible.
|
| 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.
| Almondsetat wrote:
| what does "uninstall iMessage" mean? you can disable iMessage
| right in the settings so you only receive SMSs
| dilyevsky wrote:
| Which is what lockdown mode already does
| hedora wrote:
| Actually lockdown is better. It leaves E2E encryption
| alone, but restricts attachment types, which should be
| enough to block the initial exploit in the chain.
|
| 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.
| sevg wrote:
| No, Lockdown Mode doesn't disable iMessage.
|
| "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.
| ckcheng wrote:
| Unfortunately, Lockdown Mode disables Live Photos from
| being received via iMessage... That's a pretty big iPhone
| feature to not work under Lockdown Mode!
| pimlottc wrote:
| Not received at all or received as a still photo?
| peddling-brink wrote:
| Do you believe your other messaging apps lack vulnerabilities?
| What is most popular will always be most picked on.
| stefan_ wrote:
| I remember people were very passionately arguing iMessage can
| only be secure if the only client is the Apple sanctioned one
|
| > the unknown attackers kept their campaign alive simply by
| sending devices a new malicious iMessage text shortly after
| devices were restarted.
| hedora wrote:
| There are different aspects of security here. iMessage is
| tied to a physical device, so if you want to spam people, you
| have to purchase and burn through iPhones.
|
| Rate limiting phishing attacks is certainly a useful security
| feature, but it does nothing to protect against targeted
| attacks.
| transpute wrote:
| _> unfortunate that Apple doesn 't allow users to uninstall
| iMessage_
|
| It can be disabled via Apple Configurator,
| https://news.ycombinator.com/item?id=38785311
| teruakohatu wrote:
| Can someone explain to me why we can load vast quantities of
| untrusted code and a wide variety of image formats in our
| browsers all day long and be mostly safe today, but somehow
| even first party messenger apps seem to be a relatively easily
| compromised? Why can't messenger apps be sandboxed as well as
| browsers?
| saagarjha wrote:
| Note that the second half of this exploit chain involves
| going around and exploiting the web browser.
| riwsky wrote:
| this exploit chain involved a browser vulnerability; your
| premise is flawed
| madeofpalk wrote:
| Sending these through messaging apps is appealing because
| that usually requires zero user action - you just send a
| message and the device runs the exploit as it generates
| preview thumbnails.
|
| 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.
| nvm0n2 wrote:
| It's all relative. Chrome has plenty of sandbox escapes.
| Microsoft found one lately where Chrome was passing strings
| from JS straight into the Windows TTS engine, which turned
| out to be parsing XML from it with a C++ parser that was full
| of memory errors.
| I_Am_Nous wrote:
| In the face of this kind of threat, it's pretty obvious why
| Apple treated Beeper as a security risk and took appropriate
| measures to secure iMessage.
| hnburnsy wrote:
| >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 wrote:
| > 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.
| docfort wrote:
| 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 wrote:
| 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.
| chasil wrote:
| There is a PNG in the original article with detail of the
| malware gaining a foothold on a device:
|
| 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.
| kornhole wrote:
| 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.
| CharlesW wrote:
| 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 wrote:
| 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 wrote:
| 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.
| realusername wrote:
| We already know Apple has participated to the PRISM
| program, it's not speculation anymore.
| kornhole wrote:
| I am assuming or knowing that the national security
| apparatus can both coerce and incentivize companies and
| individuals to give it what it wants. Their power is
| great and relatively unchecked to do both. Coercion
| tactics include releasing compromising information on a
| company, person or family member and more directly
| injuring person or company. Incentives include favorable
| regulation, taxation, and deals with other companies they
| control.
|
| 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 naive.
| StayTrue wrote:
| This happened at a company I worked at so it's not out of
| the question. I figured it out by reverse engineering and
| quit on the spot. They tried to tell me I'd never work
| again if spying on users was a dealbreaker. They showed me
| a natsec slide deck that identified other collaborating
| companies as a way of making their point. Among them was
| Apple.
| caskstrength wrote:
| You are telling me that natsec people give every rando
| the full list of participants in the conspiracy? That
| just doesn't make sense for any (semi)competent security
| agency to disclose.
| ironyman wrote:
| They have the budget to do both easily.
|
| 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...
| doakes wrote:
| The Darknet Diaries episode "Zero Day Brokers" goes into
| this. Apparently Argentina hosts a lot of outsourced exploit
| development. Here's the transcript:
| https://darknetdiaries.com/transcript/98/
| pvg wrote:
| _leads Kaspersky and myself to the only rational conclusion:
| that Apple cooperated with the NSA on this exploit._
|
| Kapersky reaches no such conclusion. That's from an FSB
| release.
| SXX wrote:
| Kapersky and FSB is literally the same thing.
|
| Just like NSO and Israeli Unit 8200.
| fortran77 wrote:
| This is a complete lie.
| kornhole wrote:
| It is true that Kaspersky by policy does not make attribution
| without concrete proof. It is the responsibility of
| intelligence agencies to make the call based on preponderance
| of evidence. The video linked above leads suspicion to a very
| few options. The attacker left a list of Apple ID's in the
| code in one place to check against. Kaspersky provided them
| to Apple, and Apple did not respond with any details about
| the users of those Apple ID's. One of the main
| vulnerabilities has been available for over ten years.
| pvg wrote:
| What is more true is that the article posted explicitly
| says the exact opposite of what you suggested upthread - a
| fact you should acknowledge.
| dilyevsky wrote:
| That's only "rational" for kaspersky bc in their world they
| can't function without having actual intelligence operatives on
| staff. I seriously doubt nsa needed help here
| lame-robot-hoax wrote:
| How did sanctions backfire?
| kornhole wrote:
| Germany's economy shrunk last year while Russia's grew.
| Dedollarization has accelerated which will impact the US not
| immediately but in near future.
| pas wrote:
| the dollar as the reserve currency already has a serious
| impact on the US (ie. the big upside is that it allows the
| US to borrow for very cheap, but the nasty downside is
| keeping the purchasing power of the USD artificially high,
| which is not great for the non-finance sectors of the US,
| not great for people who work in those sectors, and double-
| plus-not-great for US exports [which are not the dollar
| itself]), basically it's the "natural resource curse" again
|
| that said, dedollarization is unlikely even in the mid-term
| https://www.noahpinion.blog/p/threats-to-the-dollar-are-
| just...
| tuetuopay wrote:
| > leads Kaspersky [..] to the [..] rational conclusion: that
| Apple cooperated with the NSA on this exploit
|
| 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.
| kornhole wrote:
| Kaspersky only said they could not prove it. They did not
| make conclusion but laid out the evidence.
| LargeTomato wrote:
| Kaspersky can't prove anything so they opted to present the
| facts. They didn't state any opinion about who they believe
| is behind the incident.
| hedora wrote:
| This looks like a typical modern security hole. There's a giant
| stack of layers of unnecessary complexity, and all of them are
| garbage. The composition is also garbage.
|
| 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.
| kornhole wrote:
| You make a good point that a team of mediocre engineers could
| be responsible for the vulnerabilities. Those doing code
| review and change control would also need to be mediocre. It
| could be a combination of compromised and mediocre
| coordinated by a manager who is in service of the apparatus.
| Knowledge of the operation would better not go all the way up
| the ranks to keep it quiet.
| WalterBright wrote:
| 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 wrote:
| 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__ wrote:
| 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 wrote:
| That's where the GPRs would live. There's no reason you
| have to put weird MMIO there too.
| pm215 wrote:
| 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-hard... concludes that they are "a
| block of CoreSight MMIO debug registers for the GPU
| coprocessor".
| mhh__ wrote:
| Indeed, my bad for only skimming.
| mhh__ wrote:
| 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.
| gusfoo wrote:
| > The extra hardware registers might have been discovered by
| examining the chip itself.
|
| 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?"
| _ink_ wrote:
| Maybe, or somebody talked.
| codedokode wrote:
| Isn't it easier just to pay to one of hundreds employees having
| access to chip design? Or even get it without paying by
| appealing to patriotism?
| sangnoir wrote:
| How many ex-Apple employees work(ed) at NSA? It may just have
| been the right person doing their regular 9-5 job, with no
| subterfuge. The list of employers for Hardware security folks
| is likely a couple of dozen companies, and Apple and NSA are
| among the most prestigious of them. I expect some employees
| to move in both directions.
| mastercheif wrote:
| Major kudos to Dan Goodin at Ars Technica for this write up. The
| article reads in a "progressive disclosure" manner, and I was
| able to follow along to the end even though I am not a
| programmer.
| Muehe wrote:
| 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-422...
|
| (talk starts at minute 26:20)
| codedokode wrote:
| I would like also to link an article with technical details of
| main exploit (memory protection bypass by using undocumented
| hadware GPU registers): https://securelist.com/operation-
| triangulation-the-last-hard...
| transpute wrote:
| 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-...
| 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 wrote:
| 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 wrote:
| _> iPad with cellular does not really show you SMS 's that's
| not from the carrier of the sim card._
|
| Does iPad support SMS? The cellular line is usually only for
| data, https://www.howtogeek.com/710767/how-to-send-sms-text-
| messag... iPads can't send SMS text messages
| through Apple's Messages app. Even if you have an iPad with a
| cellular data plan for mobile internet on the go, you still
| can't send SMS text messages.
| fishywang wrote:
| Apple's own user guide (https://web.archive.org/web/2020122
| 3140550/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).
| transpute wrote:
| No direct experience to share, but that sentence may be
| referencing Continuity via iCloud, which is optional:
| With Continuity, you can send and receive SMS/MMS
| messages on iPad using the cellular connection on your
| iPhone.
|
| _> if it 's from your carrier, it shows you via a popup
| window_
|
| If it's not shown in Apple's Messages app, maybe it was a
| carrier-specific app?
| vGPU wrote:
| > 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 was included by mistake. Since this
| feature is not used by the firmware, we have no idea how
| attackers would know how to use it
|
| Considering the targets were primarily Russia and China, odds are
| fairly high this was a US intelligence backdoor.
| TaylorAlexander wrote:
| 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...
| jrexilius wrote:
| "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 wrote:
| > _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 wrote:
| 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.
| LargeTomato wrote:
| There are different levels of secret. I would never leak
| a normal company secret. But a national security secret
| is a different story.
| LargeTomato wrote:
| There are different levels of secret. I would never leak
| a normal company secret. But a national security secret
| is a different story.
| TheCaptain4815 wrote:
| I'd disagree with this. Apple execs surely know if this
| information gets leaked they're losing 30% market cap in a
| single day, why would they risk something like that when
| administrations change every 4-8 years?
| kornhole wrote:
| Power is more important than profit. Those running the
| national security apparatus have been in power for 60 years.
| The fact that they still haven't released the documents on
| the JFK assassination evidences that they are still in power.
| westhanover wrote:
| People will call you a crank or a conspiracy theorist but
| that is only because they are afraid to think about the
| answers to those questions themselves. Its easier to
| pretend it couldn't happen.
| SV_BubbleTime wrote:
| Eh.
|
| Let's say your old boss was embezzling and got away with
| it. Now you are the boss, and if you go public with it, not
| only are they out of power and likely nothing will happen,
| but all the freedom and flexibility you have in the same
| position is gone, and you or your friends have an island-
| problem you would rather not get into.
|
| Maybe it's just better to not rile up the shareholders.
| MertsA wrote:
| I think the charitable explanation here is that this was an
| undocumented debugging interface. Apple knew about it and did
| not disclose it in any publicly available material. The NSA
| almost certainly has access to Apple's source code and
| documentation. Just look at the Snowden leaks when it was
| disclosed that the NSA was mitming Google's DC to DC links.
| They already knew Google wasn't encrypting those links before
| they surreptitiously dug up the fiber and they already knew
| enough about the system architecture to make sense of that
| firehose of data. Clearly either through NSL or bribing some
| insiders, they already exfiltrated a bunch of internal
| documentation and source code. Why would Apple be any
| different?
|
| I wouldn't expect them to have HSM keys or anything but a
| mirror of their VCS? Yeah the NSA probably has that.
| d0mine wrote:
| Highly unlikely. Nobody cares.
|
| What stock was crushed by Snowden revelations?
| OneLeggedCat wrote:
| > several of MMIO addresses the attackers used to bypass the
| memory protections weren't identified in any device tree
| documentation, which acts as a reference for engineers creating
| hardware or software for iPhones. Even after the researchers
| further scoured source codes, kernel images, and firmware, they
| were still unable to find any mention of the MMIO addresses
|
| It sure quacks like a duck.
| patrickhogan1 wrote:
| 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 wrote:
| There is a series of posts on this including one that details
| the malware payload...
|
| https://securelist.com/trng-2023/
| Despegar wrote:
| 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 wrote:
| What do you mean "no real progress"? The price used to be $100.
| Despegar wrote:
| I mean progress from today.
| stavros wrote:
| 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 wrote:
| 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 wrote:
| Yes it has been going up.
| saagarjha wrote:
| It's been going up consistently. The number of groups
| that can field a full chain these days is dwindling.
| develatio wrote:
| I am by no means a security expert whatsoever. Period. But
| reading the article carefully, there is a step in the chain of
| exploits (CVE-2023-32435) which depends on exploiting Safari.
| Apple implemented a "Lockdown mode"
| (https://support.apple.com/en-us/105120) which might have
| handled this (?).
|
| 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.
| codedokode wrote:
| If you read a better article with technical details [1],
| you'll see that Apple SOCs contain a "feature" (that
| resembles a debugging tool) that allows to bypass memory
| protection by writing into undocumented and unused GPU
| registers. Apple locks down kernel memory to stop exploits,
| but these registers allow to bypass the lock.
|
| This vulnerability is they key vulnerability without which
| all the exploit chain would be useless.
|
| [1] https://securelist.com/operation-triangulation-the-last-
| hard...
| dunham wrote:
| Yeah, lockdown mode might have handled it. If I'm reading the
| article right, the first step of the exploit was a PDF file
| sent with iMessage.
|
| 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.
| doctorpangloss wrote:
| It could author its format parsers in
| https://github.com/google/wuffs, and make them BSD-like open
| source to maximize adoption.
|
| 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.
| madeofpalk wrote:
| I struggle to believe that a third party iMessage iOS app
| would be a security improvement, beyond Lockdown Mode
| https://support.apple.com/en-us/105120.
|
| 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.
| sangnoir wrote:
| One could argue the same about alternatives to Safari, and
| yet Chrome has proven to be more secure than Safari (based
| on Pwn2Own results).
| nvm0n2 wrote:
| Sure. Rewrite sensitive parts of their stack in memory safe
| languages. They have Swift after all. A lot of the iOS security
| improvements over time have really been more like mitigations
| that try to contain the damage when the giant of pile of
| decades old C gets exploited.
| maldev wrote:
| It's already 2-3 million +. Apple has amazing security,
| especially for the Iphone and continously monitors it and
| dishes out silent patches. For a REALLY high level example, it
| restricts system calls per process and requires all calls to be
| signed with an apple key, AND it restricts who you can do the
| system call to, these are continuously monitored and updated.
| Not only this, but persistence on Iphone is effectively dead,
| meaning you have to reinfect the device after every reboot. One
| of the big things you notice in the article is the use of ROP,
| apple requires every executable page to be signed by them,
| hence why you have to have these assfisting of rop chains.
| cedws wrote:
| >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 wrote:
| 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 wrote:
| Lockdown mode exists: https://support.apple.com/en-us/105120
| nvm0n2 wrote:
| 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 wrote:
| What'sapp has had exploits. See https://gbhackers.com/new-
| whatsapp-0-day-vulnerabilities/amp...
| I_Am_Nous wrote:
| >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 wrote:
| _> reboot your iPhone at least weekly_
|
| with the Hard Reset key sequence, https://www.wikihow.com/Hard-
| Reset-an-iPhone
| wyre wrote:
| Sorry for the lay question but what's the benefit of the hard
| reset over a general restart?
| x1sec wrote:
| In a week, a lot of data can be exfiltrated. Then after you
| have rebooted, the threat actor reinfects your device.
|
| The best mitigation we have is to enable lockdown mode.
| ThinkBeat wrote:
| Attack by CIA/NSA?
|
| They have the best possible insight into the hardware and
| software at all stages I should think.
| dannyw wrote:
| It targeted Russian embassy officials, and with this level of
| sophistication, so it's quite obviously NSA/etc.
| azinman2 wrote:
| Russia has made more enemies than just the U.S.
| luke-stanley wrote:
| 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 wrote:
| 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.
| Alex3917 wrote:
| If they were using a deny list, that sounds like an intentional
| backdoor.
| jacooper wrote:
| This really looks like the NSA just flexing their muscles and
| their vulnerability arsenal.
| codedokode wrote:
| 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?
___________________________________________________________________
(page generated 2023-12-27 23:00 UTC)