Seems like their malware relies on a couple of things:
- intended target is KDE and GNOME
- privilege escalation through LD_PRELOAD hooking from userland via open, stat, readdir access (of any other program that the user executes, see down below)
- persistence through display manager config for KDE
- persistence through desktop autostart files for GNOME
- fallback persistence through .bashrc, profile or profile.sh in /etc
- installs trojanized ssh client version
- installs a JSP webshell
- sideloads kernel module as libselinux.so and .ko module. Probably the rootkit helpers to access them from userland
Despite the snarky comments in here, this malware is actually quite sophisticated.
If you don't agree, I challenge you now to measure the time it takes for you to find all .so files on your system that are loaded right now, and have been modified since your package manager installed them.
My point being that there is no EDR on Linux that catches this (apart from ours that's WIP), because all existing tools are just checking for windows malware hashes (not even symbols) as they're intended for linux fileservers.
Securing Linux should probably not be approached the exact same way as securing Windows. Case in point, it is true that I can't find all of the .so files that have been modified since my package manager installed them: this is because it didn't install them, because I am using NixOS. They just exist in the Nix store, which is mounted read-only, and almost all modules are loaded from an absolute runpath.
NixOS with impermanence isn't exactly a security solution, but it does have some nice properties as a base for a secure system. It's also far from the only or even most notable of the immutable Linux systems, with abroot and RPM-ostree seeing more usage. It's probable there will still be some use in endpoint security but I suspect it will be greatly diminished if immutable image-based deployments with a secure boot chain is perfected on the Linux desktop system, for similar reasons to why it isn't really as important on ChromeOS either.
I also understand that this is not a silver bullet, as it's still possible on desktop Linux to persist malware through the bashrc/etc. like this does. Personally I blank out my home directory shell profile files and keep them root-owned to try to prevent them from being used for anything. It seems like more work is needed in the Linux ecosystem to figure out what to do about attack vectors like these, though I think a proactive approach would be preferred. (Scanning for infected files is always going to be useful, but obviously it's better if you stop it from happening in the first place.) In some ways the Linux desktop has gotten a bit more secure but many things are still not sandboxed sufficiently, which is a shame considering all of the great sandboxing technology available on Linux.
If I am skimming this correctly, this is a C&C client allowing remote control over the network, and uses "a rootkit" for further compromise once it somehow gets installed?
I understand the value of in-depth security reports, but the 5th time they told me "WolfsBane is the Linux counterpart of Gelsevirine, while FireWood is connected to Project Wood." I was wondering when I'd get to the meat and potatoes.
> The FireWood backdoor, in a file named dbus, is the Linux OS continuation of the Project Wood malware...
> The analyzed code suggests that the file usbdev.ko is a kernel driver module working as a rootkit to hide processes.
Where is the backdoor coming from? If there's a backdoor, something is backdoored. An unknown exploit installing a rootkit and using a modified file, like usbdev.ko, is not a backdoor.
Which pakage / OS ships with the backdoor?
Or doesn't the author of TFA know the definition of a backdoor? Or is it me? I mean, to me the XZ utils exploit attempt was a backdoor (for example). But I see nothing here indicating the exploit they're talking about is a backdoor.
It reads like they classify anything opening ports and trying to evade detection as "backdoors".
I believe any software that, once installed on a system, gives someone else remote access to control that system is "a backdoor". So the malware itself is "the backdoor", it's not a case of "package X has a backdoor that was exploited".
Not all malware acts like a backdoor: some malware exfiltrates data, some seeks to destroy the system, some encrypts data to hold it hostage, some performs attacks on other systems using your CPU/IP/memory, etc. The malware they are describing here does act like a backdoor though, and doesn't seem to have other malicious behavior.
>The article says they don’t know how the attacker gets access to install this back door in the first place.
It doesn't really matter, because it's orthogonal. Malware like this can be installed on a system through any exploit that provides sufficient access.
So there's two parts to defending against it: 1) finding and fixing any vulnerability that allows the installation of malware like this, and 2) since #1 is a never-ending task, knowing about this malware so you can look specifically for it and delete it when you find it.
Perhaps we use the term back door in computer security because it comes from the general English expression to get someone or something in by the back door, which more generally is any exploit?
So, an aplication started as root it does a lot, if started as a normal user, does less. Sure, any first year CS student can write something like that. Or you can.. well.. install an ssh server or a vnc server or whatever.
How it gets onto the system in the first place is the interesting (and dangerous) part, that sadly gets skimmed over here.
What's the point of these kinds of articles? Most Linux malware (including this one) are not sophisticated at all, built off of pre-existing rootkit code samples off Github and quite sloppy with leaving files and traces (".Xl1", modifying bashrc, really?). And there's a weird fixation on China here, is it just more anti-China propaganda?
I was under the impression that persistent, but SILENT access was China's goal. Dropping files in home and /tmp/ seems like the total opposite of that and any competent sysadmin would detect these anomalies manually real quick with a simple "ls -a", even possibly by accident.
> The WolfsBane Hider rootkit hooks many basic standard C library functions such as open, stat, readdir, and access. While these hooked functions invoke the original ones, they filter out any results related to the WolfsBane malware.
I took this to mean some things like a simple “ls -a” might now leave out those suspicious results.
Seems like their malware relies on a couple of things:
- intended target is KDE and GNOME
- privilege escalation through LD_PRELOAD hooking from userland via open, stat, readdir access (of any other program that the user executes, see down below)
- persistence through display manager config for KDE
- persistence through desktop autostart files for GNOME
- fallback persistence through .bashrc, profile or profile.sh in /etc
- installs trojanized ssh client version
- installs a JSP webshell
- sideloads kernel module as libselinux.so and .ko module. Probably the rootkit helpers to access them from userland
Despite the snarky comments in here, this malware is actually quite sophisticated.
If you don't agree, I challenge you now to measure the time it takes for you to find all .so files on your system that are loaded right now, and have been modified since your package manager installed them.
My point being that there is no EDR on Linux that catches this (apart from ours that's WIP), because all existing tools are just checking for windows malware hashes (not even symbols) as they're intended for linux fileservers.
Securing Linux should probably not be approached the exact same way as securing Windows. Case in point, it is true that I can't find all of the .so files that have been modified since my package manager installed them: this is because it didn't install them, because I am using NixOS. They just exist in the Nix store, which is mounted read-only, and almost all modules are loaded from an absolute runpath.
NixOS with impermanence isn't exactly a security solution, but it does have some nice properties as a base for a secure system. It's also far from the only or even most notable of the immutable Linux systems, with abroot and RPM-ostree seeing more usage. It's probable there will still be some use in endpoint security but I suspect it will be greatly diminished if immutable image-based deployments with a secure boot chain is perfected on the Linux desktop system, for similar reasons to why it isn't really as important on ChromeOS either.
I also understand that this is not a silver bullet, as it's still possible on desktop Linux to persist malware through the bashrc/etc. like this does. Personally I blank out my home directory shell profile files and keep them root-owned to try to prevent them from being used for anything. It seems like more work is needed in the Linux ecosystem to figure out what to do about attack vectors like these, though I think a proactive approach would be preferred. (Scanning for infected files is always going to be useful, but obviously it's better if you stop it from happening in the first place.) In some ways the Linux desktop has gotten a bit more secure but many things are still not sandboxed sufficiently, which is a shame considering all of the great sandboxing technology available on Linux.
This is interesting. Most Linux malware is targeting servers which usually don't have Gnome or KDE installed.
>intended target is KDE and GNOME
Apologies for the dumb question, but does this mean my PiHole running on a small Debian server that has no KDE or Gnome installed, is safe from this?
If I am skimming this correctly, this is a C&C client allowing remote control over the network, and uses "a rootkit" for further compromise once it somehow gets installed?
I understand the value of in-depth security reports, but the 5th time they told me "WolfsBane is the Linux counterpart of Gelsevirine, while FireWood is connected to Project Wood." I was wondering when I'd get to the meat and potatoes.
"once it somehow gets installed?"
The report mentions: "we conclude ... exploited an unknown web application vulnerability ... ."
The chain of events, post initial exploit, is all very well but what was the initial point of entry? The IoCs etc are welcome - thanks.
I thought SQL injection but actually Tomcat ? Might be just an old unpatched server allowing PUTs
I agree it was very wordy
For signs of the analyzed version, there's this file:
/lib/systemd/system/display-managerd.service
And a process called "kde".
> The FireWood backdoor, in a file named dbus, is the Linux OS continuation of the Project Wood malware... > The analyzed code suggests that the file usbdev.ko is a kernel driver module working as a rootkit to hide processes.
Where is the backdoor coming from? If there's a backdoor, something is backdoored. An unknown exploit installing a rootkit and using a modified file, like usbdev.ko, is not a backdoor.
Which pakage / OS ships with the backdoor?
Or doesn't the author of TFA know the definition of a backdoor? Or is it me? I mean, to me the XZ utils exploit attempt was a backdoor (for example). But I see nothing here indicating the exploit they're talking about is a backdoor.
It reads like they classify anything opening ports and trying to evade detection as "backdoors".
Am I going nuts?
I believe any software that, once installed on a system, gives someone else remote access to control that system is "a backdoor". So the malware itself is "the backdoor", it's not a case of "package X has a backdoor that was exploited".
Not all malware acts like a backdoor: some malware exfiltrates data, some seeks to destroy the system, some encrypts data to hold it hostage, some performs attacks on other systems using your CPU/IP/memory, etc. The malware they are describing here does act like a backdoor though, and doesn't seem to have other malicious behavior.
firewood is a back door, ie a program installed to provide access bypassing the systems normal authentication etc.
The article says they don’t know how the attacker gets access to install this back door in the first place.
>The article says they don’t know how the attacker gets access to install this back door in the first place.
It doesn't really matter, because it's orthogonal. Malware like this can be installed on a system through any exploit that provides sufficient access.
So there's two parts to defending against it: 1) finding and fixing any vulnerability that allows the installation of malware like this, and 2) since #1 is a never-ending task, knowing about this malware so you can look specifically for it and delete it when you find it.
I don't think you're going nuts, but I do think your definition of backdoor is a specific subset.
Fits the usual definition, e.g. from Wikipedia:
> A backdoor is a typically covert method of bypassing normal authentication or encryption
Agree with OP, wikipedia is also wrong. A backdoor is something intentional. That definition fits any exploitable bug.
Perhaps we use the term back door in computer security because it comes from the general English expression to get someone or something in by the back door, which more generally is any exploit?
So, an aplication started as root it does a lot, if started as a normal user, does less. Sure, any first year CS student can write something like that. Or you can.. well.. install an ssh server or a vnc server or whatever.
How it gets onto the system in the first place is the interesting (and dangerous) part, that sadly gets skimmed over here.
What's the point of these kinds of articles? Most Linux malware (including this one) are not sophisticated at all, built off of pre-existing rootkit code samples off Github and quite sloppy with leaving files and traces (".Xl1", modifying bashrc, really?). And there's a weird fixation on China here, is it just more anti-China propaganda?
Threat actors don't create malware to impress people; they do it to accomplish their goals. Apparently, this sample was sufficient for them.
Security companies attribute activity based on their observations. ESET- a Slovakian company- is no exception.
I was under the impression that persistent, but SILENT access was China's goal. Dropping files in home and /tmp/ seems like the total opposite of that and any competent sysadmin would detect these anomalies manually real quick with a simple "ls -a", even possibly by accident.
From the article:
> The WolfsBane Hider rootkit hooks many basic standard C library functions such as open, stat, readdir, and access. While these hooked functions invoke the original ones, they filter out any results related to the WolfsBane malware.
I took this to mean some things like a simple “ls -a” might now leave out those suspicious results.
Chinese threat actors are not one homogeneous group. Just like every other country out there.