Stealthy Linux rootkit found in the wild after going undetected for 2 years

The typical attack vector for any system would be compromising the inbound software. This is really easy to do when people are downloading and installing random programs from websites. This used to be less common, but popular cutting edge tools have popularized it recently "distro packaging is too slow, etc, curl|bash to install"

On linux, most base software comes from the distro repositories. The question there is how hard it would be to compromise these systems (including one of the mirrors). This includes ancillary packaging systems (pip, cpan, gems, conda, etc)

Also, X11 has really poor separation between processes. Any desktop application running in Xorg can keylog all user inputs.

It is possible to build a secure Linux installation but it requires a lot of careful OS knowledge and the discipline to only use a small set of software with established provenance. And probably disabling Javascript.

In macOS/Windows, there are runtime permissions these days which allow you to control which folders can be given to which application.

Linux needs to mainstream a solution like this. One of the most popular way Linux users can handle this today is by associating a user with a application and granting various permissions to that user. However this is a far cry from safe by default, and it requires deep system knowledge.

I don't trust that an AV vendor can _add_ security to a system with a _new_ and obscure binary looking over the kernels shoulder. I don't think the properties of the universe allow for this to ever be true.

- There is no real concept of base system because distros are usually a patchwork of software from diverse sources. This means stuff like proper secure boot is not really feasible on any distro (although AFAIK the systemd/Fedora people are working on it with signed UKIs and immutable OS images).

- Some features that could live in userland for improved security are instead implemented in the kernel, while both Windows and macOS generally keep moving exploitable features like font rendering to userland.

- Distros often disable or disregard security features such as SELinux or mitigations like CFI.

Here [2] is a more detailed article examining the lack of security of Linux desktops in case you're interested.

[1] https://news.ycombinator.com/item?id=37502088

[2] https://madaidans-insecurities.github.io/linux.html

On Linux, the attack surface may not be non-existent, but by default it is smaller than some other operating systems. Any halfway competent Linux sysadmin can configure iptables or some other firewall to block all network traffic except what is specifically permitted. Even when something is exposed, it usually only allows access to specific user accounts (including system service accounts.) Once access is granted to an account, you are then constrained by discretionary access controls (DAC) (i.e. POSIX users + groups + file permission modes), and, for the paranoid, by mandatory access control (MAC) (eg AppArmor or SELinux) as well.

As others have said, such access could theoretically allow bootstrapping to greater privilege escalation, especially if you only have DAC and no MAC, but in practice it's harder than it sounds.

I have seen plenty of publicly-exposed Linux VMs compromized over the years. They were always compromized via one of two methods: the admin user explicitly enabled password authentication to ssh instead of adhering to keypairs (which we enforce by default); or, they opened up a vulnerable service such as a database to the public internet. It was never via some virus.

You hear people saying dumb stuff like, oh no one uses Linux and that's why there are no viruses. To that, I say our Linux server farms have a vast amount of highly valuable compute power and research data. If it were possible to infect these machines with a virus, any halfway competent nation state, ransomware group or bitcoin mining conglomerate would very much consider it a worthwhile investment to develop such a virus.

Additionally, a lot of Linix users run most attack vectors (like browsers or email clients) inside a sandbox using Snap or FlatPak).

None of these things make it impossible to get through to the system, but they are additional barriers that an attacker needs to deal with.

I'm playing around with IP address level detecting and blocking using incoming ports as indicators. I'm going to set aside some time to think more about restrictions on outgoing ports as a result of this and your comment.

Do some logging of frequently used remote ports over a couple of weeks and create a baseline set of allowed ports, block everything else and see what breaks.

I already use the limited Feodo Tracker[0] lists to flag in my firewall logs whether any device on the network has attempted to contact a known C&C IP address.

Thanks for push.

[0]:https://feodotracker.abuse.ch

It seems so. This traffic likely will not even traverse a firewall -- the article lists the IP addresses used with port 52699, which are all RFC1918 space (172.16.0.0/12).

EDIT: from the article:

    The researchers have so far been unable
    to determine precisely how Krasue gets 
    installed. Possible infection vectors 
    include through vulnerability 
    exploitation, credential-stealing or 
    -guessing attacks, or by unwittingly 
    being installed as trojan stashed in an 
    installation file or update 
    masquerading as legitimate software

Behind that are attacks on Linux web servers where exploits in the web application (e.g. WordPress) or the web framework (e.g. Rails) are the attack vector.

Now that it's at least 2 years after the initial intrusion, it could be pretty tough to determine how that happened and what path the attacker took.

The email attachment may come from your friend/business partner which themselves got infected and the malware is now attaching itself to their legit emails. (AFAIK not very common)

Binary replacement (replacing top, ps, netstat, etc with patched versions) is the oldest trick.

Syscall hooking kernel root kits largely only vary in how exactly they hook the syscalls - there’s a few methods, but the underlying principle is the same.

And then you have userland hooks which usually use LD_PRELOAD to intercept system calls/libc calls to get the job done.

Honestly most of the time a full blown root kit is overkill, just name your binary something innocuous and have it not do anything too fucking obvious and nobody will notice.