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

31–40 of 56 posts

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

#31

Post by shaded-enmity »

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

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

Aye, I think what you're describing is "security by obscurity" - i.e. the capability is still there, I'm just counting on the attacker not knowing that it is because I've hidden it so well. It can work really well in combination with actual security practices, but it absolutely shouldn't be considered one.

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

#32

Post by capableweb »

Jedd wrote: post #19
scns wrote: post #11

Earlier quoted context omitted.

There are paying customers. It might not be shiny/fun, but there is a reason Red Hat became the first one-billion dollar open-source company in 2012.

Wouldn't IBM be the title holders there?

"open-source company" is kind of an subjective term at this point I guess, so hard to say.

But what can be said, is that even though IBM contributes a lot to open source, not many would claim IBM is a "open-source company" I think, at least when compared to Red Hat.

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

#33

Post by Thaxll »

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

I'm not sure I understand, how OpenBSD load drivers then?

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

#34

Post by sillystuff »

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

You can disable module loading at any time by writing to a /proc file: echo 1 > /proc/sys/kernel/modules_disabled

(you must reboot to re-enable module loading)

Useful on servers where specifying all modules to load is practical (netfilter modules are usually the only new modules unless hardware changes). But, on a workstation, doing so will be very frustrating unless you never plug in any new usb devices etc.

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

#35

Post by yjftsjthsd-h »

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

My impression is that Darwin did it by moving more drivers directly into user space. But yes, you can absolutely run Linux with everything statically compiled into the kernel as long as you're not using some handful of things that resist it (below comment mentions nvidia, ZFS). You can even run without an initial ramdisk if you're not doing RAID or ZFS or encrypted disks or something like that.

Edit: I should mention, this will either result in a massive kernel that consumes a lot of memory, or in very little driver support and your machine will not tend to just work when you plug new devices in. Linux has a lot of drivers; there's a reason why it uses modules.

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

#36

Post by LinuxBender »

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…

I am too familiar with this dilemma. A work-around that comes with some caveats is to disable loading of modules. [1] There are more caveats than the article mentions including rebuilding initrd/initramfs can break unless you first reboot. Do not set the settings they mention in a persistent file like sysctl.conf.

[1] - https://linux-audit.com/increase-kernel-integrity-with-disab...

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

#37

Post by yjftsjthsd-h »

sillystuff wrote: post #34
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

You can disable module loading at any time by writing to a /proc file: echo 1 > /proc/sys/kernel/modules_disabled (you must reboot to re-enable module loading) Useful on servers where specifying all modules to load is practical (netfilter modules are usually the only new modules unless hardware changes). But, on a workstation, doing so will be very frustrating unless you never plug in any new usb devices etc.

> But, on a workstation, doing so will be very frustrating unless you never plug in any new usb devices etc.

If you know what the devices you are likely to plug in, you could just modprobe them all before disabling it.

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

#38

Post by yjftsjthsd-h »

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

I don't know the exact rules, but note that this is targeting RHEL6 and Red Hat makes a deliberate effort to preserve kernel ABI compatibility so it is probably a lot easier than on most Linux distributions.

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

#39

Post by ChuckNorris89 »

jacquesm wrote: post #17
perryh2 wrote: post #8

Earlier quoted context omitted.

Are you sure you want to disclose your employer's security risks and tech debts on a public forum?

They could well be talking about any company that has multiple legacy products from two decades ago still running, which is quite a few of them...

Yeah, let's not underestimate how common this is. Narrowing it down would be neatly impossible. And that's even considering parent was fully truthful which he might not have been to preserve anonymity.

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

#40

Post by quags »

Xylakant wrote: post #3
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...

RHEL 6 is in Extended Lifecycle Support until June 2024 (that is: customers with suitable subscriptions still get critical patches). It’s a zombie, but it’s not quite dead yet. I’d bet that there are still enough (+) people out there running it. (+) or rather too many.

For centos6 there is cloudlinux also providing extended release support (paid) for those who don't have a RHEL subscription until 2024.
Post reply on HN