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, requiring the same maintenance as any modern operating system. Linux offers a robust, secure computing platform which can meet many needs. As in most cases, proper configuration is key to the security of the platform.
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 kernel parameter 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 if not in use, ignoring network broadcast packets, enabling ASLR, and activating DEP/NX. (https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/)
Enable SELinux or AppArmor
Modern Linux systems include the security enhancement systems of AppArmor or SELinux depending on the distribution. These allow for granular access control with security policies. SElinux is installed and enabled by default on CentOS and RedHat Enterprise Linux operating systems, while AppArmor is installed and enabled by default on Ubuntu and SuSE Linux Enterprise systems.
- https://wiki.ubuntu.com/AppArmor
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index
What we often observe is that people will decide to disable these security enhancement systems as soon as they run into an issue since they is easy to disable with root privileges. But taking the time to learn how to allow services and fix issues is very important to provide an additional layer of security on a Linux system.
AppArmor is a Linux kernel security module that provides capabilities similar to SELinux. While SELinux operates on files (specifically inodes) and requires filesystem support, AppArmor works on paths, while being file system agnostic. Considered by many to be easier to use, it is mostly transparent to regular users. While SELinux can be (potentially) more secure, the complexity of the system has many users preferring AppArmor.
Among the mainline Enterprise-level Linux distributions, RedHat embraces SELinux, while SuSE Enterprise embraces (and owns the trademark to) AppArmor. Canonical is a significant contributor to AppArmor as well, and supports it by default in Ubuntu.
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 (or nearly any modern operating system), 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 may prove to hold a learning curve for organizations and administrators more familiar with the configuration and use of Windows 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 Drovorub please visit the dedicated Drovorub KB article here.
The post On Drovorub: Linux Kernel Security Best Practices appeared first on McAfee Blogs.