Intro
In a U.S. government cyber security advisory released today, the National Security Agency and Federal Bureau of Investigation warn of a previously undisclosed piece of Linux rootkit malware called Drovorub and attribute the threat to malicious actor APT28. The report is incredibly detailed and proposes several complementary detection techniques to effectively identify Drovorub malware activity. A multitude of investigative methods are suggested given that the common issue with rootkits is that large scale detection on a host can be a real challenge. The NSA and FBI have been explicit in their report that systems with a kernel version of 3.7 or lower are most susceptible to Drovorub malware due to the absence of adequate kernel signing enforcement.
Keeping a system updated and fully protected isn’t specific to Windows-based environments. Linux-based systems are widespread within many enterprise organizations, often operating outside the direct visibility of system administrators. Partly because of this low visibility, threat actors embrace the Linux Stack as an ideal hiding place and launch point for lateral movement. This makes keeping these environments updated and secure a high priority.
For specific McAfee technology protections against Drovorub please visit the dedicated Drovorub KB article here.
In addition to the guidance provided in the U.S. government report and our product specific knowledge base article, McAfee encourages organizations to take note of and apply the following best practices (where possible) for rootkit detection and kernel security.
Scanning for Rootkits
Just like a malware scanner, a rootkit scanner can scan low level processes to determine if any malicious code is loaded at bootup. For example, below are examples of software that can be used for general rootkit detection:
- Chrootkit – A rootkit scanner for Linux to discover hard to find rootkits
- Rkhunter – A rootkit scanner for Linux to discover backdoors and possible local exploits.
In this specific Drovorub case the advice is given to forensically analyze a machine’s memory with tools like Volatility. Using the Volatility plugin “Linux_Psxview” presence of the Drovorub client can be detected even though it doesn’t show up in the normal PSlist.
Linux Kernel hardening
Today’s advisory suggests that organizations enable UEFI Secure Boot in “full” or “thorough” mode on x86-64 systems. UEFI Secure Boot requires cryptographically signed firmware and kernels. Because no unsigned drivers can be loaded for hardware, this action will decrease the attack surface by making it more difficult for an attacker to insert a malicious kernel module into the system and for unsigned rootkits to remain persistent after reboot.
Organizations should take note, however, that Secure Boot is not integrated in all Linux distros. There are also some challenges with enabling Secure Boot. Often it requires manual intervention any time a kernel or module is upgraded or may prevent some products from loading. This knowledge base article from VMWare discusses ways to address these Secure Boot issues
Securing the kernel
There are several steps organizations can take to secure the Linux kernel and take advantage of the features that are provided. We will highlight some of the best-practices that can be used and applied. Please apply these within a test-environment before applying them in production.
Kernel module signing
Since Linux 3.7, the kernel has supported digital signatures on loadable kernel modules. This facility can be enabled in the kernel with settings in CONFIG_MODULE_SIG. These options can require valid signatures; enable automatic module signing during the kernel build phase; and specify which hash algorithm to use. Additionally, local or remote keys can be used. By requiring valid digital signatures, only known valid modules can be loaded, decreasing your system’s attack surface.
Module loading rules
Only known modules should be loadable. Limited module support can be enabled by default, disallowing kernel module loading and specifying which modules are exempt from the ban. The following command can be used to disable the loading:
sysctl kernel.modules_disabled=1
Some modules required for system operation may normally be loaded during system operation and not at boot. To ensure these modules are available, they must be loaded at startup prior to when loading is disabled. To load these modules, list them in a file located in /etc/modules-load.d.
Disabling modules completely
Depending on the system in question, disabling all non-necessary hardware in the kernel configuration and building all required driver code directly into the kernel rather than using modules could allow for completely disabling loadable kernel module support. For special use systems, this may be a viable option. By disallowing modules entirely, your system’s attack surface can be drastically reduced.
Fully disabling kernel module support might only be possible for special purpose systems with a known usage pattern. General purpose, user-facing machines will likely need module support to support user access patterns.
Using Linux kernel Lockdown
The lockdown patches have been merged into the kernel since version 5.4. Even if Secure Boot is enabled, if not prevented, the root could still modify the kernel and, for example, apply a hot-patch and create a persistent process. Lockdown was developed to provide a policy to prevent the root from modifying the kernel code. Lockdown has two modes: “integrity” and “confidentiality”. The community generally advises organizations to consider the “integrity” mode and use “confidentiality” mode for special systems.
Harden sysctl.conf
The sysctl.conf file is the main configuration point for a Linux system. By using secure defaults, the whole system will benefit from a more secure foundation. Example options include disabling IPv6, ignoring network broadcast packets, enabling ASLR, and activating DEP/NX. (https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/)
Enable SELinux
SELinux is a security enhancement to the Linux Kernel that allows granular access control with security policies. SELinux is installed and enabled by default on Centos / Red Hat distros and can be easily enabled on Ubuntu and other distros.
- https://www.linode.com/docs/quick-answers/linux/how-to-install-selinux-on-ubuntu-18-04/
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/index
What we often observe is that people will decide to disable SELinux as soon as they run into an issue since it is easy to disable with admin privileges. But taking the time to learn how to allow services and fix issues is very important in keeping a Linux system secure.
Additional Linux System hardening
In light of today’s advisory, we have focused mostly on securing the Linux Kernel in this article. However, there are many best practices to secure Linux, including:
- Removal of unused software
- Disabling unused services
- Enabling auditing
- Controlling API access
- Limiting root account usage
- Incorporating a least-privilege policy as much as possible
- Backing up your system
- Increasing ASLR entropy via sysctl to make reliable exploitation more difficult, by increasing the number of locations libraries that could be stored in memory.
Detailed hardening and securing guides for Linux distributions can be downloaded from:
https://www.cisecurity.org/cybersecurity-best-practices/
Conclusion
Linux Kernel and System hardening often prove to be a challenge for organizations and isn’t as straightforward as securing other operating systems. However, given the information provided in the NSA-FBI publication and the adaptation of Linux-based malware by threat actors overall, we advise organizations remain vigilant, harden Linux systems as much as possible, and deploy adequate security products.
For specific McAfee technology protections against DrovorubDrovorub please visit the dedicated DrovorubDrovorub KB article here.
The post On Drovorub: Linux Kernel Security Best Practices appeared first on McAfee Blogs.
Article Link: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/on-drovorub-linux-kernel-security-best-practices/