New ultra-stealthy Linux backdoor isn’t your everyday malware discovery • Hacker News Board

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

#31

Post by mid-kid » Fri, Jun 10, 2022, 12:51 PM UTC

prvit wrote: post #15

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…

How do you detect one?

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

#32

Post by bregma » Fri, Jun 10, 2022, 12:52 PM UTC

jwrallie wrote: post #5

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.

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

#33

Post by psacawa » Fri, Jun 10, 2022, 1:01 PM UTC

mid-kid wrote: post #31

prvit wrote: post #15

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…

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 ```

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

#34

Post by mid-kid » Fri, Jun 10, 2022, 1:20 PM UTC

psacawa wrote: post #33

mid-kid wrote: post #31

Earlier quoted context omitted.

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 ```

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?

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

#35

Post by shaded-enmity » Fri, Jun 10, 2022, 1:22 PM UTC

psacawa wrote: post #33

mid-kid wrote: post #31

Earlier quoted context omitted.

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

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

#36

Post by chrismorgan » Fri, Jun 10, 2022, 1:22 PM UTC

psacawa wrote: post #33

mid-kid wrote: post #31

Earlier quoted context omitted.

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 ```

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

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

#37

Post by VoidWhisperer » Fri, Jun 10, 2022, 1:27 PM UTC

prvit wrote: post #15

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…

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

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

#38

Post by Cthulhu_ » Fri, Jun 10, 2022, 1:31 PM UTC

VoidWhisperer wrote: post #37

prvit wrote: post #15

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…

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.

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

#39

Post by Cthulhu_ » Fri, Jun 10, 2022, 1:32 PM UTC

psacawa wrote: post #33

mid-kid wrote: post #31

Earlier quoted context omitted.

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 ```

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

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

#40

Post by jhugo » Fri, Jun 10, 2022, 1:34 PM UTC

VoidWhisperer wrote: post #37

prvit wrote: post #15

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…

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

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.