Live data from Hacker News

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

arstechnica.com

61–70 of 101 posts

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

#61
post #52
post #17

Earlier quoted context omitted.

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

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

#62
post #49
post #8

Earlier quoted context omitted.

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

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 reaso…

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

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

#64
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

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

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

#65
post #33
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 ```

I see those defined when I use firejail + firefox.

    LD_PRELOAD=libmozsandbox.so

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

#66
post #56

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)

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

#67
post #32
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 taki…

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

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

#68
post #20
post #2

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.

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

#70
post #57

Earlier quoted context omitted.

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…

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.

Post reply on HN