Russian Drovorub Malware Targeting Linux

frankbell · 08-15-2020, 09:30 AM

Per Bruce Schneier, here's the press release.

An excerpt:

Quote:

Drovorub is a Linux malware toolset consisting of an implant coupled with a kernel module rootkit, a file transfer and port forwarding tool, and a command and control (C2) server. When deployed on a victim machine, Drovorub provides the capability for direct communications with actor-controlled C2 infrastructure; file download and upload capabilities; execution of arbitrary commands; port forwarding of network traffic to other hosts on the network; and implements hiding techniques to evade detection.

sgosnell · 08-15-2020, 02:16 PM

It says implementing secure boot will prevent it from being installed.

Quote:

Implementing SecureBoot in “full” or “thorough” mode should reliably prevent malicious kernel modules, such as the Drovorub kernel module, from loading. This will prevent Drovorub from being able to hide itself on a system.

frankbell · 08-15-2020, 07:59 PM

Nice catch.

timl · 08-15-2020, 08:59 PM

I suppose my question is...how to enable secure boot? From a trawl around the net (articles from 2015-2017) it is enabled by default is that right? I have to disable it if I don't need/want it?

I am using Fedora 32 but I guess this is a BIOS tweak.

teckk · 08-15-2020, 09:25 PM

Quote:

I suppose my question is...how to enable secure boot?

Info:
https://docs.fedoraproject.org/en-US...ide/index.html
https://wiki.archlinux.org/index.php...ce/Secure_Boot

frankbell · 08-15-2020, 10:13 PM

Just to be clear, one of the reasons I posted this was to combat the myth the Linux is more secure because malware targeting Linux is not in the wild.

Malware targeting Linux is indeed rare, but it is in the wild and precautions must needs be taken.

ondoho · 08-16-2020, 04:29 AM

^ Absolutely.
And it isn't the first time either, but the last time this happened I quickly realised that my browser & OS usage habits would never allow for this malware to become active.

Quote:

Originally Posted by frankbell

Per Bruce Schneier

I did not know Mr Schneier stooped to simple "aggregation" type articles.
Since he does, the juice is in the comments.
Two things:

1.

Quote:

I personally tune out NSA/FBI announcments because I know there's a meta game going on here. It's about "authority" and marketing and the Russians, quite frankly, are an easy target with their Saint Petersburg crime ecosystem.
(...)

2.

Quote:

The most important piece of information is missing. How does the exploit get loaded into the machine in the first place?

I didn't see very far, but AFAICS it - again - comes down to aquiring superuser privileges - no loading of kernel modules without that.
Prove me wrong.

business_kid · 08-16-2020, 04:36 AM

I didn't read much, but I did read that a recent kernel mitigated it - 3.7.x was the magic number IIRC.

That doesn't save RHEL on kernels like 2.6.x, but it's ok for distros with 4.x.x or 5.x.x, or is it?

ondoho · 08-16-2020, 05:10 AM

Quote:

Originally Posted by business_kid

I didn't read much, but I did read that a recent kernel mitigated it - 3.7.x was the magic number IIRC.

Yes, but that would be too easy, wouldn't it. That was ages ago. Even fbi.gov must realise that that would hardly be newsworthy.
Is this the comment:

Quote:

The TL;DR takeaway from the DOD Executive Summary would be :

Quote:

To prevent a system from being susceptible to Drovorub’s hiding and persistence, system administrators should update to Linux Kernel 3.7 or later in order to take full advantage of kernel signing enforcement.

The current Kernel level is 5.8.

Version 3.7 came out back in 2012 or thereabouts, and according to Wikipedia, was the last one to support i386.

So this advice is in practice slightly superfluous.

Quote:

Additionally, system owners are advised to configure systems to load only modules with a valid digital signature making it more difficult for an actor to introduce a malicious kernel module into the system.

Arch Linux lets you do this. But if you're a typical out-of-the-box distro user (e.g., Debian and descendants), this bit is harder to figure out. In any case, I think the typical default use case is to install the distro with UEFI disabled. This is alas the case here, at least on some of the older hardware.

How can you trust kernel developers? And who vetted Torvalds? And what about the long run? Nobody is eternal.

In the "Detection Methodologies" section on p. 36/45, I gather from the statement "Disadvantages: Subject to evasion via TLS or if the format of messages changes." that communication with the C&C server is in plain HTTP. The little five-eyed barnacles on oceanic cables are in a position to feed on any interesting stuff...

From a quick scan of the various links, I didn't see anything about practical infection scenarios, or the nature of the targets.

That last sentence reflects my own impressions.

I am not trying to downplay this, but I want clear information. I won't give in to FUD.

business_kid · 08-16-2020, 08:30 AM

Quote:

Originally Posted by ondoho

From a quick scan of the various links, I didn't see anything about practical infection scenarios, or the nature of the targets.

Me neither. From what I know, the Russian cracking outfit seems to be very hot, so this may be the payload rather than the exploit(s) to get in.

sgosnell · 08-16-2020, 03:16 PM

I would really like to see how the malicious kernel modules would get loaded. The administrator would presumably have to be persuaded to do it, but I don't know enough to make informed guesses.

business_kid · 08-17-2020, 04:53 AM

The kernel autoloads modules for hardware, network stuff, etc. I presume there's an exploit there.

sgosnell · 08-17-2020, 11:37 AM

Yes, of course, but the trick is getting the hacked module onto the drive in the proper location, and the kernel to load it. I would be interested in knowing how that's done. Most exploits rely on humans doing the job, knowingly or unknowingly through bypassing basic security practices.

ondoho · 08-17-2020, 02:59 PM

Fair enough:

Quote:

"The most important piece of information is missing. How does the exploit get loaded into the machine in the first place?"

You forget it's nature and purpose. It is not a network worm.
This is rootkit. Those are planted, manually, after compromising
the system. Even the advisory itself emphasizes on the page 37:

"NOTE:The mitigations that follow are not meant to protect against the initial access vector."

There's a million ways to hack a Linux and getting the root. (*)

and, more succinct:

Quote:

It starts with phishing.

All in all, nothing is eaten as hot as it is cooked.
Yes, Drovorub is real Linux malware, but the argument of GNU/Linux being inherently safer than, say, Windows still applies.

On a more constructive note, I wonder if e.g. Clamav would even find this? Or rkhunter?

(*)Unfortunately that same poster later continues:
You should start the question like this -
How Do I Know That's My Home Ubuntu Is Not Yet Hacked (Owned)?
Are you sure it's not hacked already? How can you be sure?
Today there's no unhackable system and if THEY want to get in,
and THEY have time, resources, knowledge, money etc, THEY
get in. Period.
So actually your first task is to assume that THEY are already IN.
Next step would be find the evidence. That's why this report was
published.
(and worse)
So, FUD after all, with a generous dash of conspiration myth.

sgosnell · 08-17-2020, 03:29 PM

The amount of money and time it would take to get into my personal system is so much larger than the worth of the information that could be gained leads me to believe that THEY don't give a rat's a$$ about my computer. THEY can get everything they need simply by watching my tracks on the internet. But that too is worth less than the time and money it would take. I have no doubt that THEY are logging everything they can about everybody, but as just one ant in the farm I'm not too worried. I do use reasonable care about what I download onto my machine, though.