What AV (if any?) would people recommend for linux? I feel that clamav is more for incoming files than something which would or could catch this?
Security researchers identify new malware targeting Linux
31–40 of 70 posts
Re: Security researchers identify new malware targeting Linux
#32Seems 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…
Less than a second to concatenate /var/lib/dpkg/info/.md5sums, currently about six seconds to concatenate and filter /var//maps. Actual checking time then depends on how much is currently mapped to memory and how performant the computer is, and how well one filters out mappings to files which were only in non-executable regions, but possibly a minute or three.
Perhaps more interestingly than how long it takes, some of the files mapped to memory are already deleted. They should have been checked at the time of loading, not hours or days later, when it's not longer possible.
Re: Security researchers identify new malware targeting Linux
#33Seems 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…
What do you mean by "intended target is KDE and GNOME"? It seems to me more like they're trying to hide the binary by using X11, KDE and GNOME file paths, but they're not exploiting KDE or GNOME desktops.
The article doesn't mention how the rootkit ended up on the machines in question, it seems to indicate a vulnerable web application. I wish I knew which one.
Re: Security researchers identify new malware targeting Linux
#34What AV (if any?) would people recommend for linux? I feel that clamav is more for incoming files than something which would or could catch this?
None, I would instead recommend monitoring file paths and alerting when they change. Known as a tripwire system.
In this case for example the attackers tried to hide their files by disguising them as other known file paths on the system.
If you use a tripwire setup you will get an alert when a file appears that is not supposed to be there. Of course this requires a more hands-on approach where you create excludes for all your applications.
Re: Security researchers identify new malware targeting Linux
#35So, 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.
I agree. Sophisticated to me would be if they tried to MITM the sudo command. Instead they simply place code into profile.d and run when the user logs in.
Re: Security researchers identify new malware targeting Linux
#36Seems 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…
Here's a .deb version; only running debsums once per package name. Errors will go to stderr:
sudo lsof | grep -o '/[^ ]*\.so[^ ]*' | awk '!seen[$0]++' | while read -r path; do
if p=$(dpkg -S "$path");then
cut -f1 -d: Re: Security researchers identify new malware targeting Linux
#37Seems 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 im…
I think most people will be served with a simple IDS that checks the entrypoints (ssh etc.), a software update routine and hardening of world accessible services to mitigate any potential damage.
Anything else is probably going to be immeasurable security theatre.
Re: Security researchers identify new malware targeting Linux
#38The use of LD_PRELOAD as part of the attack surface makes me think that a statically-linked binary has some value. Not a maximalist approach like some experimental distros, but I think there's clearly some value in your standard userland utilities always performing "as you expect," which LD_PRELOAD subverts. Plenty of Linux installs around the world get on fine using BusyBox as the main (only?) userland utility package.
Re: Security researchers identify new malware targeting Linux
#39These things always get really cool names, like "Wolfsbane" and "firewood". makes me want to make some malware to see what cool name security researchers give it lol
Re: Security researchers identify new malware targeting Linux
#40Seems 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…
What do you mean by "intended target is KDE and GNOME"? It seems to me more like they're trying to hide the binary by using X11, KDE and GNOME file paths, but they're not exploiting KDE or GNOME desktops. The article doesn't mention how the rootkit ended up on the machines in question, it seems to indicate a vulnerable web application. I wish I knew which one.
Please learn the difference of persistence and privilege escalation versus "hiding a binary".
They are certainly not trying to hide, and it has nothing to do with the initial exploit surface. You are mixing up things because you seem to be not aware how multi stage exploits work.
The article also mentioned that tomcat was targeted, but it didn't mention whether it was a zero day or a known vulnerability (like log4j vulnerabilities, for example).
- The initial access stage of that malware was a Tomcat exploit
- The privilege escalation stage was done via both userland + kernelmod, whereas userland's method was using glibc, hijacking any open() call of any process that is executed later. If you enter your sudo password any time for anything after that in any bash shell, it's escalated successfully and can install the kernel mod (that's what the .bashrc and profile entries were for).
- The persistence stage was done with a kernel mod that can now pretty much do whatever it wants.
Edit: After looking a little bit further, the initial access exploit was very likely CVE-2024-52316 [1], which is a Tomcat bug specific for that Jakarta Authentication system, given the described georegional malware campaign targets.