3 ms·

Has anybody done a writeup of the obfuscation in the backdoor itself (not the build script that installs it)? I threw the binary into Ghidra and looked thru the

Has anybody done a writeup of the obfuscation in the backdoor itself (not the build script that installs it)? I threw the binary into Ghidra and looked thru the functions it found, but having no familiarity with the ifunc mechanism it uses to intercept execution I have up and set it aside for others. I'd have to assume since there's anti-debug functionality that the code is also obfuscated. Since it shipped as an opaque binary I assumed at least some of the code would be encrypted with keys we don't have (similar to parts of the STUXNET payload).

bilekas 3y ago
No full dissemination of the backdoor itself has been done yet, as for the anti-debug, sure you can avoid things like that with flags. But this was done at compile level so its a bit more tricky. > I'd have to assume since there's anti-debug functionality that the code is also obfuscated. Not really, as above it was done at build time.. So you have already set your home up. It's shown the problems with package managers not taking source from the right place.
- EvanAnderson 3y ago
  So ifunc is a link-time thing and not a runtime thing, then? (My background, when it comes to linking, is DOS and Windows.)
  - asveikau 3y ago
    It's runtime, but I think dynamic linker. The Windows equivalent would be if a library patched some code at dllmain. Actually the Detours library in the Windows world is similar. But it's for performance; the idea is you would patch some function references based on the CPU revision to get faster code specific to your CPU.
    - bilekas 3y ago
      This is a really nice windows analogy, however it goes without saying this package wasn't aiming for Windows, ironically, it chose the path (as we seen so far) of least resistance. If you're hooked to an sshd service, your golden. They put 5 checks (maybe comically) in a row to make sure it was linux I this case .. who knows what's next.
- bannable 3y ago
  What do you mean by "package managers not taking source from the right place"?
  - sho_hn 3y ago
    I assume they are advocating for package managers to preferably grab signed git tags from repositories rather than download tarballs. The backdoor relied on the source in the tarballs being different from the git tag, adding additional script code. This is common for projects that uses GNU autotools as build system; maintainers traditionally run autoconf so that users don't have to and ship the results in the tarballs. I agree that this should be discouraged, and that distros should, when possible, at least verify that tarbal contents are reproducible / match git tags when importing new versions.
    - bilekas 3y ago
      Correct. The onus should be now be on the package delivery to provide transperant packages maybe? Maybe add the extra step of pulling instead of trusting the push from maintainers? It's just an extra step the might get more eyes. All said, even in hindsight I wouldn't have called this one out.
    - account42 3y ago
      I think saying that the backdoor relied on it is too strong. The changes were obfuscated enough that it's unlikely anyone would have noticed if they were pushed to git, not doing that is just an additional layer of safety.

bilekas 3y ago

No full dissemination of the backdoor itself has been done yet, as for the anti-debug, sure you can avoid things like that with flags. But this was done at compile level so its a bit more tricky. > I'd have to assume since there's anti-debug functionality that the code is also obfuscated. Not really, as above it was done at build time.. So you have already set your home up. It's shown the problems with package managers not taking source from the right place.

EvanAnderson 3y ago
So ifunc is a link-time thing and not a runtime thing, then? (My background, when it comes to linking, is DOS and Windows.)
- asveikau 3y ago
  It's runtime, but I think dynamic linker. The Windows equivalent would be if a library patched some code at dllmain. Actually the Detours library in the Windows world is similar. But it's for performance; the idea is you would patch some function references based on the CPU revision to get faster code specific to your CPU.
  - bilekas 3y ago
    This is a really nice windows analogy, however it goes without saying this package wasn't aiming for Windows, ironically, it chose the path (as we seen so far) of least resistance. If you're hooked to an sshd service, your golden. They put 5 checks (maybe comically) in a row to make sure it was linux I this case .. who knows what's next.
bannable 3y ago
What do you mean by "package managers not taking source from the right place"?
- sho_hn 3y ago
  I assume they are advocating for package managers to preferably grab signed git tags from repositories rather than download tarballs. The backdoor relied on the source in the tarballs being different from the git tag, adding additional script code. This is common for projects that uses GNU autotools as build system; maintainers traditionally run autoconf so that users don't have to and ship the results in the tarballs. I agree that this should be discouraged, and that distros should, when possible, at least verify that tarbal contents are reproducible / match git tags when importing new versions.
  - bilekas 3y ago
    Correct. The onus should be now be on the package delivery to provide transperant packages maybe? Maybe add the extra step of pulling instead of trusting the push from maintainers? It's just an extra step the might get more eyes. All said, even in hindsight I wouldn't have called this one out.
  - account42 3y ago
    I think saying that the backdoor relied on it is too strong. The changes were obfuscated enough that it's unlikely anyone would have noticed if they were pushed to git, not doing that is just an additional layer of safety.