New ultra-stealthy Linux backdoor isn’t your everyday malware discovery | Hacker News Reader

New ultra-stealthy Linux backdoor isn’t your everyday malware discovery

arstechnica.com

183 pointsrbanffy98 comments

Open articleView on HN

LD_PRELOAD rootkits are by definition not "ultra-stealthy".

Nothing here looks special, there are a plenty of these:

https://github.com/chokepoint/Jynx2

https://github.com/chokepoint/jynxkit

https://github.com/NexusBots/Umbreon-Rootkit

https://github.com/chokepoint/azazel

https://github.com/unix-thrust/beurk

https://github.com/mempodippy/vlany

https://github.com/nopn0p/rkorova

And presumably tens more I've forgotten about. Highschoolers write stuff like this.

This seems to be different from previous LD_PRELOAD vulnerabilities in that it's using eBPF as part of the mechanism to obfuscate itself.

Sure, but that’s at best a minor implementation detail. Doesn’t meaningfully increase the difficulty of detection.

How do you detect one?

I don't know what the correct thing to do, but you can easily detect processes that have the LD_PRELOAD environment variable defined. This is a rare enough use case for manual inspection. Something like

``` for f in /proc/*/environ ; do sudo strings $f | >/dev/null grep LD_PRELOAD && echo $f; done ```

1. Can't the process just scrub LD_PRELOAD from its environment? Linker already done it's job at that point.

2. I'd suggest against using `strings` (let alone with sudo) on attacker controlled inputs

Turns out (1) works:

  #include <stdio.h>
  #include <stdlib.h>

  static void begin() __attribute__((constructor));

  void begin() {
    unsetenv("LD_PRELOAD");
  }

Build with:

  gcc -shared -fpie -o library.so library.c

Test:

  LD_PRELOAD=~/library.so env | grep LD_PRELOAD

Usually guarded with an #ifndef DEBUG. Disallow LD_PRELOAD in Release builds

You could look at the maps of a process instead of the environ. That would show it.

Unless the ld_preload patches the process you are using to read the maps file, and gives you a false maps file.

I'm curious about 2, why?

Some versions of `strings` might try to parse the file as an executable, which could expose one to any vulnerabilities that may be present in the library used to do so.

However, on my Fedora 36 machine at least, it doesn't do so by default and I'd have to specify the `-d` flag for it to do this.

This is a nice summary: https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on...

Just tried it, I have it happening naturally in two places:

• libinput-gestures has spawned a /usr/lib/libinput/libinput-debug-events process with LD_PRELOAD=/usr/lib/coreutils/libstdbuf.so

• Firefox has spawned many /opt/firefox-nightly/firefox-bin processes with LD_PRELOAD=libmozsandbox.so

Can't an LD_PRELOAD virus just hijack fopen/fread/etc to modify the contents of the file if its path matches the pattern you described?

Yes it can. However I would assume the surface to block all diagnostics paths would be quite large and there is always some command/syscall left unblocked to detect any rootkit. Creating 100% stealth malware is possible, but difficult.

Wouldn't this malware be able to infect each of these steps and the shell itself to filter itself out of the results?

LD_PRELOAD rootkits are super common, you’re doing it wrong if you’re using dynamically linked binaries to look for malware on Linux.

I see those defined when I use firejail + firefox.

    LD_PRELOAD=libmozsandbox.so

One of the easiest ways would be using a statically linked BusyBox. This works because statically linked binaries are unaffected by LD_PRELOAD, and BusyBox has equivalents of several of the tools that would find it if not for its hiding attempts.

Side tangent: Why does github let these repos for Malware stay up? I understand some of them use the excuse 'this is for education, i'm not responsible for what you do with it', but some don't even bother with that, and atleast my concern would be that some person could easily pull the code, modify it slightly, and off they go if the IOC/detections for the attack method aren't good yet

Personal take: It's better to have malware code stay online and open, than to disappear into obscurity. This being open source also means that anti-malware companies can analyze the code and write detectors and counters to it.

Removing it would just mean it gets hidden from the 'good guys' as well.

Not just anti malware companies. I work for an enterprise and I regularly use such malware proof of concepts to make sure our antimalware and EDR (endpoint detection and response) systems actually do detect these. Or if we have to sharpen the detection rules to make them work better. These disclosures are invaluable.

Most companies modify their detection rules because generic rules tend to cause false positives that could potentially overwhelm the SOC (security operations center). It really depends on your environment a lot.

The 1990s "antivirus" industry was able to suppress most malware source and executable distribution. You could only find it in small print run zines, or the very occasional book. All that led to was people typing the source in themselves. The result was a proliferation of minor variants.

My guess is the suppression held back the tide of Windows malware a year or two, but also gave MSFT a few years of fat, dumb and happy ignorance. Nimda, Code Red, Word macro viruses, etc hit Windows hard. If jokey small threats had been as available as they are today, MSFT might have been able to ramp up rather than get buried.

> Why does github let these repos for Malware stay up?

Sad state of affairs when people routinely ask for more censorship on what was supposed to be the freest technology to ever exist.

Since Linux is open source, how about not only “allowing” things like this to stay up, but encouraging everyone know about them?

They could also write it from scratch themselves; having the source code available doesn't make it that much easier. Defence doesn't come from trying to scrub all records of the attackers' methods.

Taking the repos down would only inconvenience legitimate researchers. All the sketchy users discuss on forums and either post the code inline or upload to a random VPS.

Do you think it would make it harder to find for people specialize in making malware like this?

> my concern would be that some person could easily pull the code, modify it slightly, and off they go if the IOC/detections for the attack method aren't good yet

I did this and it passed every anti virus on virustotal. I could have wrote the virus myself in a weekend but I thought it was funny that anti virus can't detect a virus thats modified ever so slightly I think we just need a better way of scanning for this stuff.

Exploit DB etc, already exist. They're used for penetration tests as well, to simulate a real attacker, better to have something that you can work off of as a model to detect then let the attacks be the secrets of criminal organizations and state actors.

You train like you fight, you can't do research and build detections if you don't have some examples.

This sort of thing can be useful for white-hats.

Have you seen the malware called "bpfdoor"?

LD_PRELOAD equivalent was used in Windows malware circa 2006.

It seems all the old Windows techniques are now recycled on Linux.

Oh no, first LD_PRELOAD kits for Linux date back to the 90s.

LD_PRELOAD (ish) attacks are older than the web.

Direct link to the blog post with all details https://www.intezer.com/blog/research/new-linux-threat-symbi...

>Analysis of a New, Nearly-Impossible-to-Detect Linux Threat

Yeah, that's a straight up lie. LD_PRELOAD kits are by definition very easy to detect.

...unless that LD_PRELOAD rootkit has had a large amount of elbow grease put into patching all of the usual detection methods. Which appears to be the case here.

What exactly do you mean? The usual detection methods are essentially unpatchable while using this technique.

Symbiote Deep-Dive: Analysis of a New, Nearly-Impossible-to-Detect Linux Threat

And disclosed in a blog post, with Nearly-Impossible-to-Read text.

Do you mean text font/colour or the content itself?

Not sure about GP, but the Font / Color combo is darn near impossible for me to read.

LD_PRELOAD and hooking the libc syscall wrappers doesn't seem very reliable.

It won't work on static binaries, it depends on the user not clearing the environment and there are also many programs that use the syscall directly, bypassing the hooks. From playing with file system hooks I remember programs written in Go and sqlite used to do this.

Only a very small percentage of Linux binaries in the wild is fully static though (e.g., those that are compiled with musl). This is "thanks" to Glibc, which makes doing so nigh impossible.

I also highly doubt "many" programs make syscalls directly, but I could be wrong. I know I haven't done so since the days I dabbled in assembly, at least.

Anything in Go will.

LD_PRELOAD isn't a particularly new attack vector... and it is limited to the permissions of the user it is being run as. So it still needs an unpatched privilege excalation to do any real harm

> So it still needs an unpatched privilege excalation to do any real harm

https://xkcd.com/1200

All the important stuff you’d need to ruin someone’s life only needs their user account anyway, why is it such a relief if someone doesn’t get root access?

Yes, but somehow it affects all processes and installs a rootkit. That's going to need more than an unprivileged user account's access to the system. It's not clear from the article how that access is gained.

> Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability.

Because it only ruins the one person's life whose account got hacked. All the other users on the system are unaffected.

Also, if it just ruins a user account, you can simply delete that user's $HOME and restore their account from backups. If it elevates to root, you have to reformat the system and reinstall the whole OS from scratch (and hope it didn't patch the BIOS and/or hard disk firmware), and then reinstall all the user accounts from backups. Even if it's a single-user system, the non-root case is a lot less work to fix.

What other users?

Pretty much all today's systems, either personal or server, are single user.

"Real People" users yes, now that most "systems" are containers or VMs, the number of users that are real people might be one or even often zero.

But most linux services run under their own user identities, so even in that case you will likely have several if not dozens of users on a typical server, the idea being that if the "nginx" user is compromised, the "postgres" user is still safe. Also why it was a bad idea to have services running as "root" (or "system") as was more common a decade or two ago.

Plenty of households have lots of people using their own phone for social media and other consumption, but a shared laptop for times when a phone just isn't enough.

Not everyone can afford a laptop per family member.

And it isn't too difficult for something to elevate itself to root anyways. It could just include a basic key-logger which would work on most systems and wait for your password. Unless you're on Wayland, you can see for yourself by typing `xinput list` and `xinput test <id>` using the id of your keyboard.

edit: and another comment linked to a blog post which also explains how this specific malware gains root https://www.intezer.com/blog/research/new-linux-threat-symbi...

Yes, this is the part you mean, right?

> This process requires that the SO has the setuid permission flag set.

so you don't just have to download a binary file and somehow set LD_PRELOAD for that user, you also have to set the SUID bit on that binary file, which by itself only root can do...

Except they can't really do that. The key there is the person's password manager as most of the things mentioned there are online. The user account should just unlock the desktop.

My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking). And I don't keep important things logged in.

But xkcd in this case also forgets that the reason for the admin accounts being separate is that most of the usual activity running in the user context means that malware runs in that context too. So it has a much harder time to obtain true persistence and undetectability like this exploit does.

>The key there is the person's password manager as most of the things mentioned there are online

Are you sure your passwords/session data can't be exfiltrated by other means, e.g. your .mozilla/.chromium?

>My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking)

Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using?

> Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using?

I use a GPG-based password manager (pass) so this is not the case. Each password is encrypted individually using the GPG key in the yubikey. I hate keepass (I have to use it at work because they're stupid). I recently wrote a whole essay on why KeePass is so behind the times to our leadership, I hope they will finally go for something that actually has centralised management and auditing. We've seen teams that have used the keepass filename as master password for example and we have no way to prevent this kind of thing.

I also use Fido2 where possible which is even better of course.

And yes stuff can be exfiltrated but websites such as facebook, dropbox etc are pretty well defended against session cookie theft these days.

I'm just saying there is still a very good reason for the admin account to be boxed off, despite the XKCD makes it seem useless.

Interesting, your passwords are safe even if the machine is infected for as long as you don't use them, that's good. Root access makes absolutely no difference in that aspect though. The point is you can do very real harm without it.

No, but malware is much more capable of hiding from antimalware software if it obtains admin rights.

And yes, it also means that only the passwords I actually use are exposed if a machine is compromised. Because each password is encrypted individually.

How would a GPG-based password manager fare here, assuming it's using a Yubikey the same way?

AFAICT, the strength of both TOTP and public key protocols over fixed-response mechanisms depends on actually having two distinct parties, otherwise you're just adding keys that can likely be all exfiltrated by the same threat. I can see the yubikey being more meaningful if you're storing the passwords in a server whose security you trust more than your desktop, but having an infected desktop is still very bad.

> IPv4 (TCP or SCTP) and dst port (43253 or 43753 or 63424 or 26424)

So this is hiding network traffic from certain ports, which means that it should be easy enough to spot on spanports or netflow data

Are there any good tools which detect malware from analysing network traffic, either things like machines doing wide range attempts to connect on 137/139/445, or burte forcing on 22 etc, but also for more advanced searches for traffic like this?

I see plenty of companies selling end point protection, but that's not much use with the amount of blackboxes I have on my network.

I save all SYN packets on my router, it's noisy but a useful audit trail:

    tcpdump "tcp[13] & 2 != 0"

Yes, I'm aware malware could use UDP/ICMP. It could also domain-front on 443 and I'm not under any disillusion this adds meaningful resistance to malicious software; it's just interesting to observe.

Sure, and perhaps handy once you are hit, but how do you check those for any teltale signs of infection before you know what you're specifically looking for

I wouldn’t mind having a hardware / software network analyzing combo. Could probably do something as a plugin for OpenWRT — check consistency, packet sizes, ports in use, outbound hosts, etc. Could auto flag suspicious endpoints for further analysis, and if found to be malware for anyone, gets shoved in a db and shared.

Malware could always bounce traffic off of a known host but that would move the needle in any case.

I'd also like to know if there are any applications that can run off of the router. I'm not network savvy but the only thing I've done in the past is capture packets off of the LAN or WAN interfaces and read em later but thats hardly a good way to check your network...

This looks exactly like what one of my friends in college wrote.

Curious why this gets downvoted. Despite all the marketing talk parroted by Ars, this looks like a bog standard LD_preload rootkit.

I was thinking the same thing as GP. This particular article reads like a creepypasta, which makes me think there's nothing really to see here.

A static bin to access procfs informations and all is over... For a stealthy backdoor you should look at this : https://github.com/io-tl/degu-lib

Does it run into problems if a system has hidepid set to 2?

    proc on /proc type proc (rw,nosuid,nodev,noexec,noatime,hidepid=invisible)

No it doesn't, you just need to have sys_ptrace and net_admin capabilities in injected process

I'm curious why, if it was first detected in November, it's just now making news over half a year later?

An attack that requires access to LD_PRELOAD, and root access to do great damage - this is nothing new.

Is the name a Stargate SG-1 reference? I have to know...

But how does it spread?

It's very much a classic "if someone can get root access to your system and is given the ability to install software, they can install this rootkit and do very bad things" type of malware. That part is glossed over completely in the article(s) and the focus is on the "do very bad things" because it sells eyeballs and clicks.

After a while, in security, the blog posts, adverts, and scanners are the malware that's taking our time and money.

But then it is total nonsense to call this a “Linux backdoor”. A linux backdoor should mean a planted vulnerability in Linux itself.

No, this is widely accepted terminology. What you're trying to argue here is total nonsense.

That's my exact question. This requires getting a .so on a device, and setting an environment variable for all users. The malware itself isn't too interesting, however clever they managed to hide it, but how they actually got it on the computers is.

They admitted in the article that it doesn't. It's a "malware sample."

Presumably an RCE or trojan to infect the first machine, then once you have a foothold on the network and are capturing credentials you can move laterally and spread it using authorised access (perhaps including priv elevation)

"It rather involved being on the other side of this airtight hatchway"

https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

This is a downright stupid criticism, malware can be interesting in itself without discussing the delivery mechanisms.

it isn't. for symbionte to take hold, it has to social engineer it's way into a system, with a person executing it. there's nothing novel nor interesting in capturing a few system call to hide oneself, malware has been doing that since the nineties. unless it can get some privilege it shouldn't, this "malware" is mostly user error.

This is not being distributed by social engineering.

Yes, this particular malware is boring.

However, exploits are only tangentially related to malware. Malware by itself can be interesting and worth discussing.

> for symbionte to take hold, it has to social engineer it's way into a system, with a person executing it.

This is an utterly stupid criticism, as it could be applied to almost all actually novel malware.

At this point I'm going to assume that NSA has ability to access any system undetected. Probably not just NSA, but anyone that can become an NSO Group customer.

I doubt they can do it with Qubes OS though.

Surprised by the click-baitiness of this title from Ars. Seems like the old Arstechnica is a fading memory.

Very clever hiding techniques. Makes me wonder which state level actor(s) are behind this one?

These are not very clever hiding techniques, for the most part these are the most basic techniques known to every 15 year old malware dev reading decades old literature.

Ars fell for marketing speech from an AV company that has every reason to hype their discovery.

Any resources (books, articles) you'd recommend for those with a very technical background interested in getting up to speed on the side?

I linked a ton of git repos in another comment here, some of them have very readable code. LD_PRELOAD rootkits are super easy to understand.

Phrack has tons of relevant content, Blackhatacademy has some (https://nets.ec/LD_Preload)

A quick google search also found this simple walkthrough https://fluxius.handgrep.se/2011/10/31/the-magic-of-ld_prelo...

It certainly feels like a nation state's work, or, at the very least, an "advanced persistent threat" group. The packet capture pre-filter aspect, at very least, is strongly reminiscent of code I've seen from a couple of particular SE Asian APT-designated groups.

What reason do you have to believe that besides the targets? Feature-wise this isn't significantly more advanced than public LD_PRELOAD kits like Umbreon, developed by literal children.

A basic BPF filter isn't fancy or difficult to implement.

Primarily, similarity to forensics samples I've seen via incident response. But you're right; the individual aspects of this aren't particularly outstanding or complex, it's the lack of uncrossed T's and undotted I's, overall, that makes me lean toward the conclusion I'm making. Kids tend to be sloppier than criminal malware organizations, as criminal malware organizations tend to be sloppier than APT groups.

So it works like a “real” virus back from the good old DOS days? Neat. Evil, but neat.

Backdoor in the title suggests to me that it is something in the Linux itself.

Also sniffing for suspicious packets on the potentially compromised machine?

"Let's see if this robot is telling the truth. Hey robot, are you telling the truth?"

Reply on news.ycombinator.com