Live data from Hacker News

Security researchers identify new malware targeting Linux

welivesecurity.com

21–30 of 70 posts

Re: Security researchers identify new malware targeting Linux

#21

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…

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

Re: Security researchers identify new malware targeting Linux

#22

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

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.

Re: Security researchers identify new malware targeting Linux

#23

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

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.

Re: Security researchers identify new malware targeting Linux

#24

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

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.

Re: Security researchers identify new malware targeting Linux

#25

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…

This is interesting. Most Linux malware is targeting servers which usually don't have Gnome or KDE installed.

Re: Security researchers identify new malware targeting Linux

#26

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…

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.

Re: Security researchers identify new malware targeting Linux

#27

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…

Challenge accepted. "All files loaded" is probably not what you want to do however. It is much easier to just ask rpm directly which files under your library directory has been modified, and treat any files outside known library directories as suspicious.

Anyway, this is how you check which open files match ".so" and see if they are modified since installation:

  lsof | grep -o "/[^ ]*\.so[^ ]*" | while read path ; do
    pkg=$(rpm -qf "$path" 2>/dev/null)
    if [ $? != 0 ] ; then
      echo "$path does not belong to a package"
    else
      rpm -V $pkg | grep -F "$path"
    fi
  done

Re: Security researchers identify new malware targeting Linux

#28
post #25

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…

This is interesting. Most Linux malware is targeting servers which usually don't have Gnome or KDE installed.

It doesn't target KDE, it's just the developer of backdoor runs KDE, so a running process named kde looks innocent on his machine. Similar reason for .Xl1 folder: if rootkit hid .X11 folder, it would break xorg on the developer's machine. And some server distros allow to install with KDE interface.

Re: Security researchers identify new malware targeting Linux

#29

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

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

A backdoor is a literal door that the building was designed with. Whatever purpose it served, criminals could sometimes use it to gain covert access.

Re: Security researchers identify new malware targeting Linux

#30
post #27

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…

Challenge accepted. "All files loaded" is probably not what you want to do however. It is much easier to just ask rpm directly which files under your library directory has been modified, and treat any files outside known library directories as suspicious. Anyway, this is how you check which open files match ".so" and see if they are modified since installation: lsof | grep -o "/[^ ]*\.so[^ ]*" | while read path ; do…

Didn't check the code, but lsof seems a good approach.

How does that work with the various namespaces? From root namespace you should see everything. But in a mount namespace you could bind mount under a different name. How would that confuse things? With a SELinux module even root cannot do everything. If /proc is mounted privately does it change anything?

Not sure, just starting to think. Linux has become incredibly complex since the old days...

Edit: orc routinely loads executable sections not belonging to any package.

Post reply on HN