RussianGRU NSA Debrief: Kernel Level Protection strategies on Linux servers

The NSA and FBI had an excellent joint write up on Russian Drovorub Malware on 8/13.

URL:https://media.defense.gov/2020/Aug/13/2002476465/-1/-1/0/CSA_DROVORUB_RUSSIAN_GRU_MALWARE_AUG_2020.PDF

So for defenders what should you be doing with your internet facing Linux servers?

The NSA offers the following mitigation strategies:

  1. Apply Linux Updates
  2. Prevent Untrusted Kernel Modules (Ex. Activate UEFI/Secure boot)

Lets take a further in depth look at some popular linux server distros on protection strategies in regards to mitigation tactics with untrusted Kernel Modules.

Attached is how to enable UEFI in VMware Vsphere 6.7 If your linux distro supports:

CentOS 7

UEFI/Secure Boot is supported in CentOS7

So what can you do if your gear is not on UEFI?

These should be some effective strategies at securing the bootloader involved in the boot process if you are running BIOS instead of UEFI on CentOS 7 or newer.

Lets take a look at our bootloader configuration permissions in CentOS7. By default we have 0644 access permissions. This means root has read/write and all users have read permissions. Non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them. So we really need to change this from 644 to 600. The root account should be the only account with read and write capability. Regular users of the system should never have rights to look at access permissions on the grub config file.

To Remediate:

Next we need to set the boot loader password. Requiring a boot loader password will prevent unauthorized users from entering boot parameters or changing the boot partition such as turning off SELinux at boot.

Next we need to ensure the following line is present in both files:

/usr/lib/systemd/system/rescue.service

/usr/lib/systemd/system/emergency.service

Line for ExecStart:

ExecStart=-/bin/sh -c “/sbin/sulogin; /usr/bin/systemctl — fail — no-block default”

This will require authentication in rescue mode and will prevent a unauthorized user from rebooting the system into recue mode to gain root privileges without credentials.

Next we need to check on the SELinux configuration. First we are going to check and make sure SELinux is not disabled in the bootloader configuration.

Make sure there are no instances of selinux=0 or enforcing=0 in the /etc/default/grub file. If there is that means SELinux is not enabled on the bootloader which could be an indicator of compromise. By default it should be enabled on a Cent OS Server:

Next lets make sure SELinux is enabled at boot time. This will ensure that the controls are in effect at all times from initial boot. By default it should be enabled and enforced but you can check with the following commands:

If the mode is not enabled and enforcing this could be a key indicator of compromise.

Next we will make sure SELinux policy is configured. The SELinux type should be targeted in the config file as shown below:

We will also need to check and make sure the loaded policy name is targeted in the sestatus:

Lets also check and make sure mandatory access controls are installed with libselinux. We want to ensure SELinux is running from my above notes and AppArmor is installed.

Ubuntu 18.04

Here is wiki around UEFI secure boot for Ubuntu.

BIOS process of protecting boot settings:

Lets look at the same type of process on Ubuntu Server.

The grub file has default read permissions on root, groups, and others. We really don’t need those permissions in the second two categories.

Here is how to remediate this issue where root is the only account that has read rights to the file:

Next lets ensure we have a bootloader password set. By default Ubuntu server installations do not have this set. First make an encrypted password. It will dump a full hash that you will want to copy to a text file.

Next edit the /etc/grub.d/40_custom config file:

(Note: some places will tell you to modify the 00_header file. Don’t do this. Sometimes when grub is updated this file can be overwritten)

Before you run update-grub. Large enterprises may not want multiple linux boxes to have people authenticate prior to booting. If this is the case please add the following line to /etc/grub.d/10_linux

CLASS=” — class gnu-linux — class gnu — class os — unrestricted”

At this point you can issue sudo update-grub

We need to make sure authentication is required for recovery mode (single user mode). We grep etc shadow to determine if a password has set for the root account. We should see no results. Since we do we will need to set a password on the root account. The process is shown below.

If no password is set at the root account you could reboot the system into single user to gain root privileges without credentials.

Next lets look at Mandatory Access control restrictions:

By default in ubuntu server App Armor is installed

But App armor utils is not installed:

So we will go ahead and install:

No that we have app armor installed we will want to use app armor to protect the grub bootloader. Edit the following file:

/etc/default/grub

Add the following to the command line:

GRUB_CMDLINE_LINUX=”apparmor=1 security=apparmor”

Once finished issue the command to update grub:

sudo update-grub

Next check and make sure all apparmor profiles are in enforce or compain mode. By default you should be good here but you can grep that status on the profiles to check:

I highly suggest all app armor profiles are set to enforcing mode if possible.

Conclusion:

These should be effective strategies to secure the bootloader at all costs on these two distros. I choose these two distro’s because they are what I encounter the most in a enterprise organization.

We also shouldn’t forget to look at SSH configurations of these systems. While its out of scope for both the NSA report and my article I think its important to mention as a insecure SSH configuration can lead to compromise, especially if you are allowing SSH on a internet facing servers. On any given day my SSH honey pot has a little over 10k probing attempts from various IP sources as well as the same amount in username/pass attempts. Don’t re-use passwords or make weak passwords on SSH servers and definitely review any vendor documentation to change default passwords.

If you are looking at further hardening guidance on Linux server distributions I would suggest looking at CIS controls to do so:

It's 2016 and all I found was Toilets running Telnet...using shodan