Protecting Linux-Based Systems from Russian Cyber-Espionage Malware, Drovorub
On August 13th, 2020, The National Security Agency and Federal Bureau of Investigations released a cybersecurity advisory that warned anyone deploying or maintaining a Linux system about a new Russian (and now worldwide) cyber espionage threat named Drovorub.
Drovorub, developed (according to this advisory warning) by the Russian General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS) military unit 26165, is described by the NSA and FBI as 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 server. When deployed on a victim machine, Drovorub provides the capability for direct communications with actor-controlled command and control 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."
In other words, if your embedded Linux system is infected with Drovorub, it's pwn’ed - allowing an attacker unmitigated access to your system while hiding itself from discovery and removal.
Of course, this isn't the first time a government-sponsored cyber threat has found its way into the wild. But its newsworthiness lies not in its origin, novelty, or effectiveness, but in the fact that it can be completely prevented to begin with.
Cutting Drovorub (and similar cyber threats) off at the knees
The NSA and FBI suggest updating to Linux Kernel 3.7 or above in order to utilize kernel signing and configure systems to "load only modules with a valid digital signature", but this only scrapes the surface of what can be done to harden a Linux system against malware like Drovorub. In fact, as we've already outlined in our recent blog post, 10 Properties of Secure Embedded Systems, a variety of countermeasures working together can fully protect a Linux-based embedded system from Drovorub and many, many other cyber-threats.
Secure boot
Since none of the Drovorub documentation indicates how the malware is to be installed in a system, many different attack vectors exist that could allow an attacker to install this (and other) malware.
Hundreds (maybe thousands) of vulnerabilities exist in system boot sequences that, if left unprotected, can and will be exploited by a would-be attacker to (in this case) install a Russian cyber-espionage malware payload on a Linux system—Meltdown, Spectre and Blindside to name a few. A well-engineered secure boot sequence prevents an attacker from gaining access and maintaining persistence on the system, and/or subverting other constructs like application whitelisting, or potentially disabling security features like kernel driver signing.
Download our whitepaper >> Securing embedded system boot sequences with TrueBoot.
Operating system hardening
Building on the NSA and FBI's suggestions, securely configuring your kernel to enforce driver signing and authentication can prevent malware like Drovorub from gaining initial access to the system since, without the proper signatures, the kernel will not load Drovorub to begin with. But that's only one kernel configuration option that could help.
Address space layout randomization (ASLR), for example, makes it impossible for a malicious payload to know where critical applications or data are located and therefor unable to exploit them. Direct access to memory is another configuration option along with secure user/kernel copies, and many more.
Star Lab's own Titanium Security Suite for Linux provides a fully-hardened Linux kernel configuration that stops a kernel-level rootkit like Drovorub dead in its tracks.
Enforcing least privilege and mandatory access control
If your system configuration only grants minimal needed privileges to users applications, you can prevent malicious payloads such as Drovorub from taking advantage of the system in unintended ways. Furthermore, by utilizing Mandatory Access Control (MAC) — explicitly specifying file/process/kernel access and restrictions based on system policies that are always enforced at runtime, no user or administrator can bypass or disable security controls within the fielded device.
In short, this means that even if an attacker gains administrative access to the system, they won't be able to install malware, take control, or disable security protections enforced by those policies. With a proper MAC configuration, Drovorub becomes effectively ineffective.
Good cyber-hygiene prevents foreign cyber-espionage
All this is to say, good cyber-hygiene can prevent foreign cyber-espionage threats like Drovorub from ever infiltrating your embedded Linux system. And, since Drovorub isn't the first cyber threat to Linux systems (and won't be the last), any Linux system deployed without following proper cyber-hygiene means an unprotected system will fall easily to cyber threats.
For more information on securely configuring and protecting your system against threats like Drovorub, read 10 Properties of Secure Embedded Systems. For more information on products that can secure boot an embedded system, isolate operating systems and applications with virtual machines, and harden Linux systems with mandatory access control and other countermeasures, check out our TrueBoot, Crucible, and Titanium products respectively or contact us at Star Lab for more information.
Learn more: free White papers on Securing Embedded Systems
