Questions regarding chkrootkit and Syslogk LKM rootkit

Lars Skogstad

Lars Skogstad

Hi

Did a random scan today with chkrootkit and rkhunter, chkrootkit gave me a warning:

"Searching for Syslogk LKM rootkit... INFECTED: Possible Malicious Syslogk LKM rootkit installed"

Anyone know anything about if this is normal error and can be ignored or if it can be something else?
I find just an empty file in /proc which says syslogk , haven't noticed anything earlier on incoming/outgoing traffic either but
haven't ran chkrootkit for a long while, have just run rkhunter.

Read a .pdf paper on it somewhere that it's difficult to discover since it hides very well etc.
 
It's probably a false positive, syslogk LKM is a Linux kernel module. While it's certainly nefarious I highly doubt it will load, let alone function, on FreeBSD.
 
Thanks SirDice, any idea what can trigger it or how? I checked the source and it really just looks if proc/syslogk is in the folder it seems.
 
Lars Skogstad said:
Thanks SirDice, any idea what can trigger it or how?
Click to expand...
Probably the presence of that file in /proc that just happens to have the same name. Don't know where it comes from though, I have a couple of systems with procfs(5) enabled and I don't seem to have it.
 
To be absolutely sure turn off Linux Emulation if not needed.

Start looking for the roots of the program manually.
ps -ax
 
Ah. I think that /proc/syslogk file is due to the test. Apparently if you write a '1' to /proc/syslogk the rootkit kernel module shows up. So the file is probably the result of that write action.

Fortunately, the rootkit has a functionality implemented in the proc_write function that exposes an interface in the /proc file system which reveals the rootkit when the value 1 is written into the file /proc/syslogk.
Click to expand...
decoded.avast.io

Linux Threat Hunting: 'Syslogk' a kernel rootkit found under development in the wild - Avast Threat Labs

Introduction Rootkits are dangerous pieces of malware. Once in place, they are usually really hard to detect. Their code is typically more challenging to write than other malware, so developers resort to code reuse from open source projects. As rootkits are very interesting to analyze, we are...
decoded.avast.io decoded.avast.io
 
Phishfry said:
To be absolutely sure turn off Linux Emulation if not needed.
Click to expand...
Still though, it's a kernel module. The linux emulation only works for userspace applications, it won't allow or make it possible to load Linux kernel modules.
 
Phishfry said:
Can you have a hidden process in FreeBSD? Something running that will not show up in ps ?
Click to expand...
It's certainly possible to create a rootkit kernel module specific for FreeBSD to achieve the same functionality.
 
Hopefully we have people countering this:

The malicious processes are hidden via hk_getpr – a mix of Adore-Ng functions for hiding processes.
 
This sounds scary for a little novice like myself.
Not sure how I can counter this in the future if it happens or isn't picked up by some scanners.
 
Loading a kernel module requires root access. So they've already managed to get in deep. In order to get root access they're going to need to get in first. Then, usually, it also requires another exploitable vulnerability to elevate their privileges. Lots of detectable things would happen before they get this far. To combat these issues you need to be diligent when it comes to security patches and issues. Patch! Keep your stuff updated. That alone will keep most of the riff-raff out. And be vigilant when making services accessible from the internet. Anything you open has the potential to get attacked.
 
I feel like I'm pretty safe, I dont have lots of users and I update stuff all the time, basic security applied etc.
So I guess it should be safe since I'm not a high priority target.

Thanks for the help btw
 
eternal_noob said:
There are UEFI rootkits which survive an OS reinstallation.
arstechnica.com

Discovery of new UEFI rootkit exposes an ugly truth: The attacks are invisible to us

Turns out they're not all that rare. We just don't know how to find them.
arstechnica.com arstechnica.com
Click to expand...
Seems that this threatens Windows only (today). But of-course it is possible to develop something similar for FreeBSD also. However, the FreeBSD "market" is probably too small for this to spread. Another question is how can someone write to UEFI from a running system?
 
Argentum said:
Another question is how can someone write to UEFI from a running system?
Click to expand...
It's FAT32, don't need a lot of permissions because it doesn't have any. But it would require being able to mount it (usermount?).
 
SirDice said:
It's FAT32, don't need a lot of permissions because it doesn't have any. But it would require being able to mount it (usermount?).
Click to expand...
I understand that the loader is on the FAT partition on the disk, but how can I mount the BIOS flash on the MB? There should be a device node for that?
 
Argentum said:
but how can I mount the BIOS flash on the MB? There should be a device node for that?
Click to expand...
Oh, you meant the actual UEFI firmware. That's a little trickier. It seems every manufacturer has their own way for updating that. I don't think it's been standardized.
 
SirDice said:
Oh, you meant the actual UEFI firmware. That's a little trickier. It seems every manufacturer has their own way for updating that. I don't think it's been standardized.
Click to expand...
Yes, the article was about infecting the actual firmware. It looks difficult doing it from the working machine. The idea was the backdoor to survive the system reinstall. Any such backdoor is probably OS specific.
 
Argentum said:
It looks difficult doing it from the working machine.
Click to expand...
I have done BIOS/UEFI upgrades from a running Windows host using manufacturer supplied tools, so it's not impossible to do. But you would have to reverse engineer their tool, and even then it would probably only work for that specific mainboard make and model.

Argentum said:
Any such backdoor is probably OS specific.
Click to expand...
Sure. But you could put different solutions in the malware package to be able to infect multiple different operating systems. Windows is the obvious choice here, it still has the biggest market share for desktop systems.
 
SirDice said:
I have done BIOS/UEFI upgrades from a running Windows host using manufacturer supplied tools, so it's not impossible to do. But you would have to reverse engineer their tool, and even then it would probably only work for that specific mainboard make and model.

Sure. But you could put different solutions in the malware package to be able to infect multiple different operating systems. Windows is the obvious choice here, it still has the biggest market share for desktop systems.
Click to expand...
I have done this by booting up a DOS stick. Windows probably has also capability to run a program in a real mode. However, in case of FreeBSD, the malicious code infecting the BIOS should be in kernel (or some driver). Do not see any way to do it from user space (correct me if I am wrong).
 
Argentum said:
I have done this by booting up a DOS stick.
Click to expand...
Yeah, that was the 'old school' way. I'm sure there are a lot of boards that still can be updated this way. Other systems could be updated from the BIOS/UEFI firmware itself. Nowadays there are also UEFI update tools you can load from the UEFI shell.
Argentum said:
Windows probably has also capability to run a program in a real mode.
Click to expand...
I don't think it requires the CPU to be in real mode, real mode is just a consequence of booting good ol' DOS. I do assume it would need to have ring 0 access. But I've never taken such an update tool apart so I honestly don't know.
 
SirDice said:
I don't think it requires the CPU to be in real mode. I do assume it would need to have ring 0 access. But I've never taken such an update tool apart so I honestly don't know.
Click to expand...
Yes, that is what I had in mind. In case of FreeBSD, Ring 0 means kernel. One should insert that malicious code, infecting the BIOS, into the kernel.
 
You must log in or register to reply here.
Back
Top