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

61–70 of 70 posts

Re: Security researchers identify new malware targeting Linux

#61

Post by lyu07282 »

INTPenis wrote: post #35
ajsnigrutin wrote: post #9

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.

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.

Sophisticated would be fileless with persistence through flashing of some firmware code, but those aren't gonna be uploaded randomly on virustotal lmao

Re: Security researchers identify new malware targeting Linux

#62

Post by usr1106 »

BonusPlay wrote: post #51
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…

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

Not even that is enough if the malware has loaded a kernel module.

Re: Security researchers identify new malware targeting Linux

#63

Post by red-iron-pine »

INTPenis wrote: post #33
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…

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.

I think it's less about targeting KDE or GNOME specifically, but instead hitting linux desktop, and those using those systems.

as a target demographic, the folks using linux on the desktop are almost certainly more technical than most, and are likely developers, engineers, admins, or otherwise STEM types. probably high overlap with domains like SRE and security.

also probably, as a whole, better paid, and more likely to have cryptocurrency.

Re: Security researchers identify new malware targeting Linux

#64

Post by cookiengineer »

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…

I hope you know that there was a reason I wrote that challenge.

Your solution failed because you installed the rootkit that was aliased via the lsof command in the .bashrc.

Additionally, lsof like so many other tools rely on procfs, which allows processes to rewrite their own process names (comm) and arguments (cmdline).

Even if the malware of the article would run only in userspace (as non-root and "only a wheel user"), you certainly would have executed it.

My point being that you also forgot to check any processes against environment variables like LD_PRELOAD that the malware uses before executing any command (meaning even syntax programs like "if" as a program can be hijacked).

Again, this is a conceptual problem because there is a lot of programs in $PATH that can be executed by the same user, meaning only a kernel hook or ebpf module can audit/grant access to these kind of things to prevent that.

There is no trusted execution in Linux because of so many things down the line. Glibc, the $PATH mess, aliases, .local overrides etc.

Re: Security researchers identify new malware targeting Linux

#65

Post by remram »

aulin wrote: post #19
remram wrote: post #12

Earlier quoted context omitted.

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.

Neither Wikipedia nor GP said something about intentions. My understanding of GGP's complaint is that they'd refer to the package containing the security issue as "backdoor", rather than the malware itself, and I disagree. This driver thing is a backdoor, the package is backdoored, this fits usual definitions.

Re: Security researchers identify new malware targeting Linux

#66

Post by xorcist »

cookiengineer wrote: post #64
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…

I hope you know that there was a reason I wrote that challenge. Your solution failed because you installed the rootkit that was aliased via the lsof command in the .bashrc. Additionally, lsof like so many other tools rely on procfs, which allows processes to rewrite their own process names (comm) and arguments (cmdline). Even if the malware of the article would run only in userspace (as non-root and "only a wheel use…

Obviously you can't check for the presence of a rootkit while under a rootkit, in the general case.

Checking environment variables wasn't part of the challenge. The challenge was likely not intended to check for rootkits, because there are a thousands of other ways to place a rootkit apart from already loaded libraries. (Why check only open files? Closed files can also contain unwanted things.)

If the purpose is to check system integrity, just check all packages. That is much easier and faster.

If there is even the slightest possibility that the system is already compromised, do it from rescue media.

Re: Security researchers identify new malware targeting Linux

#67

Post by xorcist »

BonusPlay wrote: post #51
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…

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

If the system is backdoored, do none of these things. Boot from rescue media. Save only non-executable files and wipe the rest.

Do not trust key material, sensitive data or remote logins that the backdoored system have had control over. Repeat the same operation for them.

To check for backdoors, again boot from rescue media and do a full integrity check. Do not limit the check to open files.

Re: Security researchers identify new malware targeting Linux

#68

Post by cookiengineer »

xorcist wrote: post #66
cookiengineer wrote: post #64

Earlier quoted context omitted.

I hope you know that there was a reason I wrote that challenge. Your solution failed because you installed the rootkit that was aliased via the lsof command in the .bashrc. Additionally, lsof like so many other tools rely on procfs, which allows processes to rewrite their own process names (comm) and arguments (cmdline). Even if the malware of the article would run only in userspace (as non-root and "only a wheel use…

Obviously you can't check for the presence of a rootkit while under a rootkit, in the general case. Checking environment variables wasn't part of the challenge. The challenge was likely not intended to check for rootkits, because there are a thousands of other ways to place a rootkit apart from already loaded libraries. (Why check only open files? Closed files can also contain unwanted things.) If the purpose is to c…

Why so?

Couldn't we have a nice overview of what kind of signed modules are valid in their integrity and authenticity based on cryptography?

(Also I wanted to point out that LD_PRELOAD was specifically mentioned in my comment, but it doesn't really matter, it's the lack of integrity checks across the /usr folders that are part of the problem. Glibc, $PATH, sideloaded .so files, kernel hooks...it's such a vast problem space of insecure development practices that by now we need a better OS architecture because all (old) tools down the stack rely on 100% trustable programs being installed, which after the invention of the internet is not a reality anymore.)

Re: Security researchers identify new malware targeting Linux

#69

Post by taneliv »

internet_points wrote: post #45
taneliv wrote: post #32

Earlier quoted context omitted.

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…

what is this /var/*/*maps ?

Oopsie do,

    /proc/*/maps
But it's way too late to edit.

Re: Security researchers identify new malware targeting Linux

#70

Post by b3lvedere »

lyu07282 wrote: post #60
b3lvedere wrote: post #54

Earlier quoted context omitted.

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.

It isn't exposed indeed, but i'd like to have it as safe as normally possible. Are there items you might suggest in making it more secure?
Post reply on HN