Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security researchers identify new malware targeting Linux

welivesecurity.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Security researchers identify new malware targeting Linux

#51

Post by BonusPlay »

xorcist wrote: post #27
cookiengineer wrote: post #18

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…

Seems like you assumed none of your tools got backdoored. I'd start bootstrapping from busybox.

Re: Security researchers identify new malware targeting Linux

#52

Post by holowoodman »

usr1106 wrote: post #30
xorcist wrote: post #27

Earlier quoted context omitted.

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

Besides namespaces, if one were malicious, one could also hide loaded libraries from lsof another way: open the library file, memcpy() the contents into RAM somewhere, mprotect(...,PROT_EXEC) that contents and then close the library file. You'll have to do your own linking, but then no open file will appear except for a very brief moment.

Re: Security researchers identify new malware targeting Linux

#53

Post by Y_Y »

internet_points wrote: post #36
xorcist wrote: post #27

Earlier quoted context omitted.

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: (But is there a hard rule that says a loaded library has to be named .so, or show up as .so for lsof? I'm sure there's ways to avoid the above detection.)

> But is there a hard rule that says a loaded library has to be named .so, or show up as .so for lsof?

No, yes(-ish)

Filenames are just a convention and not necessarily enforced.

lsof will really list every file the kernel thinks has a handle held by an active process, but depending on your threat model I think you could get around this. For example you could copy the malicious code into memory and close the file, or use your preload to modify the behaviour of lsof itself (or debsums).

Anyway debsums is a great tool. I'd have used a command similar to yours, though maybe run debsums first, use `file` to filter dynamic libraries and then check which of those have been recently accessed from disk.

Re: Security researchers identify new malware targeting Linux

#54

Post by b3lvedere »

cookiengineer wrote: post #50
b3lvedere wrote: post #21

Earlier quoted context omitted.

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

Yes, if it's not running Tomcat. (Personal opinion: You should never run Tomcat, history of really unsecure development practices)

To my knowledge PiHole uses Ngingx, so that seems ok. Thank you for your response.

Re: Security researchers identify new malware targeting Linux

#55

Post by gorgonical »

saagarjha wrote: post #42
gorgonical wrote: post #38

The 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 packa…

They load a kernel driver so your avoidance of LD_PRELOAD wouldn’t really be able to protect against this anyway.

Unless I misread they don't state exactly how the attack escalates privileges to install the driver. Could there be two versions of the attack with varying levels of severity?

Re: Security researchers identify new malware targeting Linux

#57

Post by lowleveldesign »

c16 wrote: post #31

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?

There is also Sysmon for Linux [1]. I work often with Windows systems that's how I know it (it's a popular choice on Windows to analyze Sysmon logs for suspicious events), but it's probably niche in Linux world.

[1] https://github.com/microsoft/SysmonForLinux

Re: Security researchers identify new malware targeting Linux

#58

Post by tenthirtyam »

internet_points wrote: post #36
xorcist wrote: post #27

Earlier quoted context omitted.

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: (But is there a hard rule that says a loaded library has to be named .so, or show up as .so for lsof? I'm sure there's ways to avoid the above detection.)

This didn't quite work for me - dpkg complained about "no path found matching..." for every library. I replaced the "$path" in the dpkg command with "${path##*/}" to just match the library name. Further inspection showed my package manager installed libraries to /lib (a soft link to /usr/lib/) but lsof returns files in /usr/lib.

Other than that it seems to work - i.e. no alarming output. :-)

Re: Security researchers identify new malware targeting Linux

#59

Post by chuckadams »

INTPenis wrote: post #44
cookiengineer wrote: post #40

Earlier quoted context omitted.

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

So when you say "intended target is KDE and Gnome" you mean target for persistence on the system? Sorry but not all of us have formal education in this field, I'm just trying to understand if you're saying that KDE and Gnome systems are vulnerable, or Tomcat web servers.

KDE and Gnome desktop files are just used as launchers, they're not the actual thing being exploited. Persistent malware pretty much always separates the vector from the payload: the exploit just gets the door open, then downloads the actual malware from the C&C servers. Many vectors, one malware package.

> Although we lack concrete evidence regarding the initial access vector, the presence of multiple webshells (as shown in Table 1 and described in the Webshells section) and the tactics, techniques, and procedures (TTPs) used by the Gelsemium APT group in recent years, we conclude with medium confidence that the attackers exploited an unknown web application vulnerability to gain server access.

Re: Security researchers identify new malware targeting Linux

#60

Post by lyu07282 »

b3lvedere wrote: post #54
cookiengineer wrote: post #50

Earlier quoted context omitted.

Yes, if it's not running Tomcat. (Personal opinion: You should never run Tomcat, history of really unsecure development practices)

To my knowledge PiHole uses Ngingx, so that seems ok. Thank you for your response.

PiHole is not usually exposed to the Internet, that's why it's less likely to be attacked at all. But I wouldn't call their nginx+php spaghetti stack "secure" or any less vulnerable.
Post reply on HN