15 ms·

EDIT: Here's some more RE work on the matter. Has some symbol remapping information that was extracted from the prefix trie the backdoor used to hide strings. L

by junon 3y ago

EDIT: Here's some more RE work on the matter. Has some symbol remapping information that was extracted from the prefix trie the backdoor used to hide strings. Looks like it tried to hide itself even from RE/analysis, too. https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504 https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9... Full list of decoded strings here: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 -- For someone unfamiliar with openssl's internals (like me): The N value, I presume, is pulled from the `n` field of `rsa_st`: https://github.com/openssl/openssl/blob/56e63f570bd5a479439bc6f6a2499f6b86ded341/crypto/rsa/rsa_local.h#L62C5-L62C12 https://github.com/openssl/openssl/blob/56e63f570bd5a479439b... Which is a `BIGNUM`: https://github.com/openssl/openssl/blob/56e63f570bd5a479439bc6f6a2499f6b86ded341/crypto/bn/bn_local.h#L245 https://github.com/openssl/openssl/blob/56e63f570bd5a479439b... Which appears to be a variable length type. The back door pulls this from the certificate received from a remote attacker, attempts to decrypt it with ChaCha20, and if it decrypts successfully, passed to `system()`, which is essentially a simple wrapper that executes a line of shellscript under whichever user the process is currently executing. If I'm understanding things correctly, this is worse than a public key bypass (which myself and I think a number of others presumed it might be) - a public key bypass would, in theory, only allow you access as the user you're logging in with. Assumedly, hardened SSH configurations would disallow root access. However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. Wild. This is about as bad as a widespread RCE can realistically get.

jeroenhd 3y ago
> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.
- junon 3y ago
  Right, though if I'm understanding correctly, this is targeting openssl, not just sshd. So there's a larger set of circumstances where this could have been exploited. I'm not sure if it's yet been confirmed that this is confined only to sshd.
  - jeroenhd 3y ago
    The exploit, as currently found, seems to target OpenSSH specifically. It's possible that everything involving xz has been compromised, but I haven't read any reports that there is a path to malware execution outside of OpenSSH. A quote from the first analysis that I know of (https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.openwall.com/lists/oss-security/2024/03/29/4): > Initially starting sshd outside of systemd did not show the slowdown, despite the backdoor briefly getting invoked. This appears to be part of some countermeasures to make analysis harder. > a) TERM environment variable is not set > b) argv[0] needs to be /usr/sbin/sshd > c) LD_DEBUG, LD_PROFILE are not set > d) LANG needs to be set > e) Some debugging environments, like rr, appear to be detected. Plain gdb appears to be detected in some situations, but not others
- onedognight 3y ago
  > With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. Please review this commit[0] where the sandbox detection was “improved”. [0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7 https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...
  - ronsor 3y ago
    Well, the definition of "improve" depends on one's goals.
  - Denvercoder9 3y ago
    That one's a separate attack vector, which is seemingly unused in the sshd attack. It only disables sandboxing of the xzdec(2) utility, which is not used in the sshd attack.
tootie 3y ago
Mind boggling. How do you even decide what to do with privileges on a billion computers?
- junon 3y ago
  There's a reasonably high chance this was to target a specific machine, or perhaps a specific organization's set of machines. After that it could probably be sold off once whatever they were using it for was finished. I doubt we'll ever know the intention unless the ABC's throw us a bone and tell us the results of their investigation (assuming they're not the ones behind it).
  - BbzzbB 3y ago
    ABC?
    - tau255 3y ago
      3 letter intelligence agencies.
      - aaronmdjones 3y ago
        Baw, GCHQ is going to feel so left out.
    - az226 3y ago
      NSA, CIA, FBI, DHS.
  - ddalex 3y ago
    I'd disagree, based on reports of the actor trying to get this upstreamed in Debian and Fedora. Widespread net.
  - cmcaleer 3y ago
    Classic example of this being Stuxnet, a worm that exploited four(!) different 0-days and infected hundreds of thousands of computers with the ultimate goal of destroying centrifuges associated with Iran’s nuclear program.

by junon 3y ago

jeroenhd 3y ago

> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.

junon 3y ago
Right, though if I'm understanding correctly, this is targeting openssl, not just sshd. So there's a larger set of circumstances where this could have been exploited. I'm not sure if it's yet been confirmed that this is confined only to sshd.
- jeroenhd 3y ago
  The exploit, as currently found, seems to target OpenSSH specifically. It's possible that everything involving xz has been compromised, but I haven't read any reports that there is a path to malware execution outside of OpenSSH. A quote from the first analysis that I know of (https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.openwall.com/lists/oss-security/2024/03/29/4): > Initially starting sshd outside of systemd did not show the slowdown, despite the backdoor briefly getting invoked. This appears to be part of some countermeasures to make analysis harder. > a) TERM environment variable is not set > b) argv[0] needs to be /usr/sbin/sshd > c) LD_DEBUG, LD_PROFILE are not set > d) LANG needs to be set > e) Some debugging environments, like rr, appear to be detected. Plain gdb appears to be detected in some situations, but not others
onedognight 3y ago
> With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. Please review this commit[0] where the sandbox detection was “improved”. [0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7 https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...
- ronsor 3y ago
  Well, the definition of "improve" depends on one's goals.
- Denvercoder9 3y ago
  That one's a separate attack vector, which is seemingly unused in the sshd attack. It only disables sandboxing of the xzdec(2) utility, which is not used in the sshd attack.

tootie 3y ago

Mind boggling. How do you even decide what to do with privileges on a billion computers?

junon 3y ago
There's a reasonably high chance this was to target a specific machine, or perhaps a specific organization's set of machines. After that it could probably be sold off once whatever they were using it for was finished. I doubt we'll ever know the intention unless the ABC's throw us a bone and tell us the results of their investigation (assuming they're not the ones behind it).
- BbzzbB 3y ago
  ABC?
  - tau255 3y ago
    3 letter intelligence agencies.
    - aaronmdjones 3y ago
      Baw, GCHQ is going to feel so left out.
  - az226 3y ago
    NSA, CIA, FBI, DHS.
- ddalex 3y ago
  I'd disagree, based on reports of the actor trying to get this upstreamed in Debian and Fedora. Widespread net.
- cmcaleer 3y ago
  Classic example of this being Stuxnet, a worm that exploited four(!) different 0-days and infected hundreds of thousands of computers with the ultimate goal of destroying centrifuges associated with Iran’s nuclear program.