An attack that requires access to LD_PRELOAD, and root access to do great damage - this is nothing new.
New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
41–50 of 101 posts
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#42> 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 sear…
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.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#43At 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.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#44LD_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?
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.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#45Earlier quoted context omitted.
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
I'm curious about 2, why?
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#46Earlier quoted context omitted.
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.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#47Earlier quoted context omitted.
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?
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.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#48Earlier quoted context omitted.
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
I'm curious about 2, why?
This is a nice summary: https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on...
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#49LD_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?
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.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#50LD_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?
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.