5 ms·

Eh. Take a look at other state-sponsored attackers. We know they have 0-days for iOS, we know they've been used, but even Apple doesn't know what they are since

Eh. Take a look at other state-sponsored attackers. We know they have 0-days for iOS, we know they've been used, but even Apple doesn't know what they are since they are so good at hiding their tracks. I don't think a state-sponsored attack would upload their payload to the git repo and tarball for all to stare at after it's been found out, which only took about a month. NSO Group built a turing-complete VM out of a use-after-free exploit in some JBIG2 decompression code. Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison. My best guess as to what this is is an amateur hacker ring, possibly funded by a ransomware group.

orbital-decay 3y ago
That's why I mentioned the recent story. [0] [1] "Apple doesn't know" when the chain uses an internal backdoor in Apple hardware is a... stretch. And the chain gives the strong vibes of corporate-style development, with all its redundancy and mismatch between two parts. It's not alchemy, really. [0] https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/ https://securelist.com/operation-triangulation-the-last-hard... [1] https://news.ycombinator.com/item?id=38783112 https://news.ycombinator.com/item?id=38783112 - HN discussion
- ThePowerOfFuet 3y ago
  Re the secret knock in the Apple silicon, a friend of mine once said "that's how you lose the NOBUS on a backdoor", and I think they were absolutely right. The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.
  - deleted 3y ago
    [deleted]
  - cesarb 3y ago
    > The one thing which most leads me to believe this was an intentional backdoor? The S-boxes. If you look at that HN discussion, you'll find a link to a Mastodon post from an Asahi Linux developer explaining that these "S-boxes" are actually an ECC calculation, and that the registers are probably cache debug registers, which allow writing directly to the cache bypassing the normal hardware ECC calculation, so you have to do the ECC calculation yourself if you don't want a hardware exception caused by an ECC mismatch on read (of course, when testing the cache, sometimes you do want to cause an ECC mismatch, to test the exception handling).
    - ThePowerOfFuet 3y ago
      Correct, but you still have to know the values for the Hamming operation; my point stands.
  - orbital-decay 3y ago
    I don't believe it's intentional for the reason you mentioned. Although it could theoretically be like that for plausible deniability, Apple's reputation is definitely more valuable than one patchable backdoor of god knows how many others. But debug backdoor is still a backdoor.
    - vinay_ys 3y ago
      Very large companies are definitely at the mercy of governments. Just look at how they are bending over backwards to comply with DMA etc. So, it is not at all inconceivable that they are forced to put backdoors into their product by the governments.
      - 1over137 3y ago
        >Very large companies are definitely at the mercy of governments. Thankfully! At least in a democracy, the government is chosen, megacorps are accountable to no one else.
      - trogdor 3y ago
        Except Apple is known for having very publicly fought the FBI’s attempt to force a backdoor into iOS. https://en.m.wikipedia.org/wiki/Apple–FBI_encryption_dispute https://en.m.wikipedia.org/wiki/Apple–FBI_encryption_dispute
        geggo98 3y ago
        That’s true. On the other hand, Apple isn’t some kind of Borg like swarm intelligence. While Apple’s upper management doesn’t want back doors in their products, someone in middle management might have come to a different opinion.
    - lozenge 3y ago
      Intentional doesn't mean Apple approved. It could be a couple of compromised employees on the right teams.
dmitrygr 3y ago
> is clownshoes by comparison The quality of work you attract in part depends on how much you pay. Go check out how much is paid for a persistent iOS exploit, compared to a Linux user space exploit. From that, you may draw conclusions about their relative perceived difficulty and desirability. This will explain why iOS exploits are done more professionally. They are rarer, much better paid, and thus attract a better audience and more work on guarding them from discovery.
zvmaz 3y ago
> Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison. While the world is trying to understand the backdoor, you sir decided that it's "clowshoes". I can only blindly defer to your expertise... "Clownshoes, amateur, hacker ring, ransomeware group." Done.
cjbprime 3y ago
You are severely underestimating this attacker and their sponsors. Amateur hacker rings do not spend two years actually diligently maintaining the software they will later backdoor. It would not make any sense in the world of ransomware attacks and bitcoin payouts. > Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison. It has to be on the world wide web for distros to package and ship it. And this was actually the best disguise possible: this directory is one where it is normal and expected to have binary files that are not obviously analyzable, as this one wasn't -- another part of the malware rearranged it to become non-corrupt at exploitation-time. See this note from the README for the test directory: > This directory contains bunch of files to test handling of .xz, .lzma (LZMA_Alone), and .lz (lzip) files in decoder implementations. Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves. It is a brilliant solution to the problem of "okay, but where do I hide the malware payload, given the constraint that it has to be distributed alongside the code and tarballs?". The attack was detected, but not because of this file, and it's unlikely to me that it ever would have been detected purely by the means of this file, given the comment above.

orbital-decay 3y ago

That's why I mentioned the recent story. [0] [1] "Apple doesn't know" when the chain uses an internal backdoor in Apple hardware is a... stretch. And the chain gives the strong vibes of corporate-style development, with all its redundancy and mismatch between two parts. It's not alchemy, really. [0] https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/ https://securelist.com/operation-triangulation-the-last-hard... [1] https://news.ycombinator.com/item?id=38783112 https://news.ycombinator.com/item?id=38783112 - HN discussion

ThePowerOfFuet 3y ago
Re the secret knock in the Apple silicon, a friend of mine once said "that's how you lose the NOBUS on a backdoor", and I think they were absolutely right. The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.
- deleted 3y ago
  [deleted]
- cesarb 3y ago
  > The one thing which most leads me to believe this was an intentional backdoor? The S-boxes. If you look at that HN discussion, you'll find a link to a Mastodon post from an Asahi Linux developer explaining that these "S-boxes" are actually an ECC calculation, and that the registers are probably cache debug registers, which allow writing directly to the cache bypassing the normal hardware ECC calculation, so you have to do the ECC calculation yourself if you don't want a hardware exception caused by an ECC mismatch on read (of course, when testing the cache, sometimes you do want to cause an ECC mismatch, to test the exception handling).
  - ThePowerOfFuet 3y ago
    Correct, but you still have to know the values for the Hamming operation; my point stands.
- orbital-decay 3y ago
  I don't believe it's intentional for the reason you mentioned. Although it could theoretically be like that for plausible deniability, Apple's reputation is definitely more valuable than one patchable backdoor of god knows how many others. But debug backdoor is still a backdoor.
  - vinay_ys 3y ago
    Very large companies are definitely at the mercy of governments. Just look at how they are bending over backwards to comply with DMA etc. So, it is not at all inconceivable that they are forced to put backdoors into their product by the governments.
    - 1over137 3y ago
      >Very large companies are definitely at the mercy of governments. Thankfully! At least in a democracy, the government is chosen, megacorps are accountable to no one else.
    - trogdor 3y ago
      Except Apple is known for having very publicly fought the FBI’s attempt to force a backdoor into iOS. https://en.m.wikipedia.org/wiki/Apple–FBI_encryption_dispute https://en.m.wikipedia.org/wiki/Apple–FBI_encryption_dispute
      - geggo98 3y ago
        That’s true. On the other hand, Apple isn’t some kind of Borg like swarm intelligence. While Apple’s upper management doesn’t want back doors in their products, someone in middle management might have come to a different opinion.
  - lozenge 3y ago
    Intentional doesn't mean Apple approved. It could be a couple of compromised employees on the right teams.

dmitrygr 3y ago

> is clownshoes by comparison The quality of work you attract in part depends on how much you pay. Go check out how much is paid for a persistent iOS exploit, compared to a Linux user space exploit. From that, you may draw conclusions about their relative perceived difficulty and desirability. This will explain why iOS exploits are done more professionally. They are rarer, much better paid, and thus attract a better audience and more work on guarding them from discovery.

zvmaz 3y ago

> Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison. While the world is trying to understand the backdoor, you sir decided that it's "clowshoes". I can only blindly defer to your expertise... "Clownshoes, amateur, hacker ring, ransomeware group." Done.

cjbprime 3y ago

You are severely underestimating this attacker and their sponsors. Amateur hacker rings do not spend two years actually diligently maintaining the software they will later backdoor. It would not make any sense in the world of ransomware attacks and bitcoin payouts. > Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison. It has to be on the world wide web for distros to package and ship it. And this was actually the best disguise possible: this directory is one where it is normal and expected to have binary files that are not obviously analyzable, as this one wasn't -- another part of the malware rearranged it to become non-corrupt at exploitation-time. See this note from the README for the test directory: > This directory contains bunch of files to test handling of .xz, .lzma (LZMA_Alone), and .lz (lzip) files in decoder implementations. Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves. It is a brilliant solution to the problem of "okay, but where do I hide the malware payload, given the constraint that it has to be distributed alongside the code and tarballs?". The attack was detected, but not because of this file, and it's unlikely to me that it ever would have been detected purely by the means of this file, given the comment above.