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

Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

decoded.avast.io

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#21

Post by lapsis_beeftech »

rollcat wrote: post #18

OpenBSD has removed loadable kernel modules back in 2014; macOS is aggressively moving in the same direction. Meanwhile - is running a Linux system without module support even viable these days? $ du -sh /lib/modules/$(uname -r) 294M /lib/modules/5.10.0-15-amd64

Certainly viable but your non-modular system might not support all the features you want. The Linux system I am using to post this comment is running without CONFIG_MODULES and have been so for years, but I am not using ZFS nor anything from NVIDIA.

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#22

Post by shaded-enmity »

rollcat wrote: post #18

OpenBSD has removed loadable kernel modules back in 2014; macOS is aggressively moving in the same direction. Meanwhile - is running a Linux system without module support even viable these days? $ du -sh /lib/modules/$(uname -r) 294M /lib/modules/5.10.0-15-amd64

How is the vector of persistence of any significance here? At some point the attackers got root access on your system, game over.

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#23

Post by cb321 »

shaded-enmity wrote: post #22
rollcat wrote: post #18

OpenBSD has removed loadable kernel modules back in 2014; macOS is aggressively moving in the same direction. Meanwhile - is running a Linux system without module support even viable these days? $ du -sh /lib/modules/$(uname -r) 294M /lib/modules/5.10.0-15-amd64

How is the vector of persistence of any significance here? At some point the attackers got root access on your system, game over.

I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B.

https://github.com/c-blake/kslog has maybe a little more color on this topic, though I'm sure there are whole volumes written about it elsewhere. :)

EDIT: But maybe your "game over" point is just that it is kind of a pipe dream to hope to block all concealment tactics? That may be fair, but I think a lot of security folks cling to that dream. :)

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#24

Post by shaded-enmity »

cb321 wrote: post #23
shaded-enmity wrote: post #22

Earlier quoted context omitted.

How is the vector of persistence of any significance here? At some point the attackers got root access on your system, game over.

I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B. https://github.com/c-blake/kslog has maybe a little more color on this topic, though I'm sure there are whole volumes written about it elsewhere. :) EDIT: But maybe your "game over" point is just that it is kind of a pipe dream to hope to block all…

> I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B.

That's generally called pivoting and has nothing to do with method of persistence of the malicious code.

OP makes a point that certain systems move or have moved away from giving root user the ability to extend/modify kernel code at runtime via kernel modules, my argument is that none of that matters since root user can still extend/modify kernel code at runtime via binary patching.

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#25

Post by xyzzy123 »

chr15p wrote: post #15
wazari972 wrote: post #6

> To load the rootkit into kernel space, it is necessary to approximately match the kernel version used for compiling; it does not have to be strictly the same. >> vermagic=2.6.32-696.23.1.el6.x86_64 SMP mod_unload modversions do you know why they say "approximately match"? I thought it had to match exactly so that the kernel accepts to load the module

A kernel module doesn't have to match the kernel version, it has to be able to resolve all the symbols (function calls, variables etc) it uses into valid symbols supplied by the kernel you are loading on. The greater the difference between the kernel version you compiled for, and the kernel version you are trying to load it on, the greater the chance something you are relying on changed and the module loader cant res…

Perhaps also worth noting that rootkits don't have to follow the usual rules; you don't have to rely on the kernel linker if you don't want to.

(Tradeoff of runtime DIY symbol resolution / code grovelling being it's more work, and more likely to be crashy).

As a rootkit author you have considerably more flexibility than most module authors who are constrained by "sanity", maintainability, accepted practice and licensing terms.

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#26

Post by cb321 »

shaded-enmity wrote: post #24
cb321 wrote: post #23

Earlier quoted context omitted.

I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B. https://github.com/c-blake/kslog has maybe a little more color on this topic, though I'm sure there are whole volumes written about it elsewhere. :) EDIT: But maybe your "game over" point is just that it is kind of a pipe dream to hope to block all…

> I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B. That's generally called pivoting and has nothing to do with method of persistence of the malicious code. OP makes a point that certain systems move or have moved away from giving root user the ability to extend/modify kernel code at runtime via ke…

Ah. I misunderstood your "persistence" to mean "persistence of logs" not "of code/illicit powers". Sorry - I read too quickly.

I do think the defense mentality, as evidenced by many comments in this thread, remains a bit too much about "how challenging to make things" rather than the "in theory possibility". Besides binary patching a static kernel as you say, for example, you could have remote hashes of all relevant files a la tripwire, and remote access and programs to check said hashes. If the attacker can detect and adapt to a hash checking pattern then they can "provide the old file" for some purposes/etc. to hide their presence. To do so they have to also write the code to detect/conditionalize. The rationale of this defense mentality seems to hope for a "distribution of attacker laziness" that may at least "help", but sure - it is just a higher, finite bar. And once the work has been done..game over. But I do not mean to belabor the obvious. Anyway, thanks for clarifying your argument.

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#27

Post by kibwen »

28304283409234 wrote: post #2

Seems to only relate to RHEL 6, or derivatives of, such as CentOS 6. Yes: 6. Which is as EOL as enterprise software gets: https://access.redhat.com/support/policy/updates/errata#Life...

Despite that, RHEL 6 appears to be entrenched. Rust has been proposing to update its baseline Linux and glibc versions to circa-2012 vintage, which would exclude RHEL 6, and has been receiving pushback from people whose customers still use RHEL 6.

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#29

Post by josephcsible »

sheepdestroyer wrote: post #4
28304283409234 wrote: post #2

Seems to only relate to RHEL 6, or derivatives of, such as CentOS 6. Yes: 6. Which is as EOL as enterprise software gets: https://access.redhat.com/support/policy/updates/errata#Life...

Comparatively, RHEL 6 is still kind of fine, at least it is still officially supported as virtualized OS in oVirt... We run a lot of CentOS 5 virtual machines (and some physical ones! ; and some RHEL4! , and a few Fedora core 8 and 4 !!!), with no end in sight... :( It is a huge concern for the Infra team, a source of many headaches, and we need to go through oops to keep them running, but: - Clients don't want to mo…

> at least it is still officially supported as virtualized OS in oVirt...

If they're not providing security fixes for RHEL 6's packages, then why does this matter?

Re: Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found in the wild

#30

Post by capableweb »

KronisLV wrote: post #12
sheepdestroyer wrote: post #4

Earlier quoted context omitted.

Comparatively, RHEL 6 is still kind of fine, at least it is still officially supported as virtualized OS in oVirt... We run a lot of CentOS 5 virtual machines (and some physical ones! ; and some RHEL4! , and a few Fedora core 8 and 4 !!!), with no end in sight... :( It is a huge concern for the Infra team, a source of many headaches, and we need to go through oops to keep them running, but: - Clients don't want to mo…

> Dev team is not interested in migrating OLDPRODUCT to a modern platform, or even try to put it in a container. Surely this wouldn't take more than 2 weeks: just figure out the install instructions for the old piece of software, rewrite them as a part of a Dockerfile (or similar set of instructions to build an OCI image, there are other options out there, too), setup some basic CI/CD which will execute Docker/Podman…

> Surely this wouldn't take more than 2 weeks

Which, based on what previous commentator said, is just about 2 more weeks than anyone want to spend on it.

If no one wants to do it, it doesn't matter if it takes 2 days or 2 months, it won't get done.

Post reply on HN