...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.
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
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.
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?
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.
> 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.
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.
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.
"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.
> 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...
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.
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'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.
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.
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.
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.
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
```
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.
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.
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.
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.
> 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.
> 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 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...
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
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.
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.
100 comments
[ 3.0 ms ] story [ 174 ms ] threadAnd disclosed in a blog post, with Nearly-Impossible-to-Read text.
Yeah, that's a straight up lie. LD_PRELOAD kits are by definition very easy to detect.
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?
> 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.
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.
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?
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.
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.
Pretty much all today's systems, either personal or server, are single user.
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.
Not everyone can afford a laptop per family member.
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...
> 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...
After a while, in security, the blog posts, adverts, and scanners are the malware that's taking our time and money.
Ars fell for marketing speech from an AV company that has every reason to hype their discovery.
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...
A basic BPF filter isn't fancy or difficult to implement.
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?"
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.
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.
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.
``` for f in /proc/*/environ ; do sudo strings $f | >/dev/null grep LD_PRELOAD && echo $f; done ```
2. I'd suggest against using `strings` (let alone with sudo) on attacker controlled inputs
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.
Unless the ld_preload patches the process you are using to read the maps file, and gives you a false maps file.
• 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
Removing it would just mean it gets hidden from the 'good guys' as well.
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.
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.
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?
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.
You train like you fight, you can't do research and build detections if you don't have some examples.
It seems all the old Windows techniques are now recycled on Linux.
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.
Malware could always bounce traffic off of a known host but that would move the needle in any case.
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
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.