Email or username:

Password:

Forgot your password?
q3k :blobcatcoffee:

I have managed to extract a list of encoded strings within the liblzma/xz backdoor payload (5.6.1):

gist.github.com/q3k/af3d93b6a1

The code has a dictionary of strings that are encoded as a prefix trie, which helps to keep things stealthy. This is eg. then used to look up symbols, eg. bd_elf_lookup_hash(..., 0x2b0, ...) means bd_elf_lookup_hash(..., "__libc_stack_end", ...). This is also why it's slow :).

This should bring us one step closer to knowing what the binary payload does.

29 comments
sirocyl

@q3k that yolAbejyiejuvnup=Evjtgvsh5okmkAvj string is very 🤨​ indeed.

q3k :blobcatcoffee:

@sirocyl Set that as an env var, run the payload and win a mystery prize!

Haelwenn /элвэн/ :triskell:
@q3k @sirocyl Interesting, my first thought on it was something similar to username:password.
waldi

@q3k There is one string that stands out: ssh-rsa-cert-v01@openssh.com

Would they allow some hard coded key to sign certificates and just allow them through?

Ross Burton

@waldi @q3k That's a SSH key type (cvsweb.openbsd.org/src/usr.bin) but it's definitely doing *something* with keys. I wonder if the crazy foo=bar assignment is used to identify a key with hidden attributes.

waldi

@q3k Yeah. Can’t quote it right now, but it seems they use broken certificates that contain encrypted stuff in the rsa public key, which is then directly executed with system().

cesarb

@q3k The first thing I thought when seeing this list of strings was "they directly copied part of the openssh code into the backdoor, and just replaced all strings with encoded strings". For instance, the "mm_" strings can all be found on a normal sshd executable. So my guess is that they divert the flow into their modified copy of the openssh code, instead of doing smaller changes.

cesarb

@q3k I just did a quick look at the openssh-portable source code, and many of these strings (including the "xcalloc: zero size" one, which does not make much sense for a backdoor code) can be found there. So my guess is that there's a good chance that a lot of the code you'll find is just the openssh code, the hard part would be to find what has been changed in it.

q3k :blobcatcoffee:

@cesarb I think it might be something like looking for functions which call some symbols, or looking for function calls with debug statements. We're pretty sure somewhere in there is a small x86_64 disassembler :). All of this to be able to patch different versions of openssh.

drone

@q3k @cesarb I think this is right. We confirmed it hooks additional functions (RSA_get0_key), and we speculate its modifying logs as well (check out what it's doing around the "Accepted password for" strings)

Astrid

@q3k What file is this extracted from? the liblzma_la-crc64-fast.o from the original mail?

q3k :blobcatcoffee:

@astrid I took this from a 5.6.1 fedora build of liblzma. But it should also be extractable from that .o.

Astrid

@q3k It looks like there are a few more symbols in the .o file from there - I think I found the function you call bd_elf_lookup_hash (at 0x1860)? it's called crc_init in there, which isn't a name that exists in the xz source itself

q3k :blobcatcoffee:

@astrid The symbol names from the .o are just fanfiction, they're just made to look like legit liblzma symbols.

But yes, the function at 0x1860 in the 5.6.0 .o seems to be what I call bd_elf_lookup_hash. 0x0a8a0 is what I call bd_hash (even though I now know it's not a hash).

Astrid

@q3k makes sense! neat trick (unsure if common) to hide like that. any clue where the data itself is stored?

Riatre

@astrid The trie? In liblzma_la-crc64-fast.o it's at 0xC340 (has_child masks) and 0xAEE0 (node info).

Here is the parser, but so far I've only seen one version of this: gist.github.com/Riatre/527a34d

(Offsets hardcoded here is for snapshot.debian.org/archive/de)

elly
@q3k Interesting that they only targeted RSA, and not "modern" ED25519
Jevin Sweval

@q3k I wonder if it would detect Intel PT tracing. Could make a lighthouse trace from that and throw it in your favorite RE tool. Wonder if stock QEMU user-mode (I know there are lots of older forks with trace functionality) with its new plugin feature can do execution traces. Maybe Qiling could do it but I dunno if its loader emulation would handle ifuncs.

Jevin Sweval

@q3k Or Pin with SideChannelMarvels Tracer - instruction and memory access logging.

github.com/SideChannelMarvels/

Jevin Sweval

@q3k Eh I got execlog qemu plugin working but to get qemu-user to work with sshd forking I’d need to use binfmt and do everything in an arm64 vm. And the logging is just to stderr not a nice binary trace file and I don’t feel like improving it. It does log instruction, memory access, and register changes tho.

And I’m not sure if binfmt qemu-user needs static qemu which doesn’t support plugins so that would be more h4x.

AndresFreundTec

@jevinskie @q3k Fairly sure it's not. I actually did a fair bit of my analysis with PT and it does still redirect RSA_public_decrypt etc with it present.

I think the detection of debugging tools is fairly simplistic. It didn't even seem to detect gdb reliably.

penguin42

@q3k Hmm what's the magic string 2nd from the last one?

zeno

@q3k I got too curious about what that weird string was so I did a test, seems to just "defuse" the backdoor as running sshd with it makes it exit much faster than without.

uis

Should have installed Gentoo: it doesn't use redhat's patches

robryk

@q3k

Re the supposed killswitch: I don't get the point of a killswitch. Where would malware authors use it?

Boud

@robryk

My guess is that they want to use the killswitch when they want to use the real sshd rather than their replacement one. Especially in case their replacement one is ... buggy.

@q3k @zeno

Xabi

@robryk @q3k maybe to close the backdoor, to make it undetectable, once the computer has been compromised. Or to fix and protect some servers from several countries...

Go Up