Email or username:

Password:

Forgot your password?
q3k's posts Post Back to profile
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.

30 March at 12:43 | Open on social.hackerspace.pl
29 comments
sirocyl

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

30 March at 13:09 | Open on social.treehouse.systems
q3k :blobcatcoffee:

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

30 March at 13:12 | Open on social.hackerspace.pl
Haelwenn /элвэн/ :triskell:
@q3k @sirocyl Interesting, my first thought on it was something similar to username:password.
30 March at 18:30 | Open on queer.hacktivis.me
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?

30 March at 13:16 | Open on chaos.social
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.

30 March at 13:41 | Open on hachyderm.io
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().

30 March at 20:42 | Open on chaos.social
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.

30 March at 14:14 | Open on fosstodon.org
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.

30 March at 14:23 | Open on fosstodon.org
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.

30 March at 14:45 | Open on social.hackerspace.pl
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)

30 March at 16:15 | Open on infosec.exchange
Astrid

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

30 March at 14:19 | Open on hachyderm.io
q3k :blobcatcoffee:

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

30 March at 14:38 | Open on social.hackerspace.pl
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

30 March at 16:40 | Open on hachyderm.io
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).

30 March at 16:44 | Open on social.hackerspace.pl
Astrid

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

30 March at 16:46 | Open on hachyderm.io
q3k :blobcatcoffee:
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)

30 March at 17:13 | Open on o3o.ca
elly (:neocat_phone: 3559@38C3)
@q3k Interesting that they only targeted RSA, and not "modern" ED25519
30 March at 14:34 | Open on donotsta.re
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.

30 March at 15:48 | Open on mastodon.social
Jevin Sweval

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

github.com/SideChannelMarvels/

30 March at 15:53 | Open on mastodon.social
Jevin Sweval
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.

30 March at 18:15 | Open on mastodon.social
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.

30 March at 17:22 | Open on mastodon.social
penguin42

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

30 March at 17:41 | Open on mastodon.org.uk
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.
30 March at 17:57 | Open on piaille.fr
uis

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

30 March at 19:40 | Open on pone.social
robryk

@q3k

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

30 March at 18:28 | Open on qoto.org
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

30 March at 18:57 | Open on framapiaf.org
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...

30 March at 20:01 | Open on mastodon.eus
Go Up