The result? The act grants the hacker a shell with root privileges, which allows them to gain complete remote control over encrypted Linux machine.
The security issue relies due to a vulnerability (CVE-2016-4484) in the implementation of the Cryptsetup utility used for encrypting hard drives via Linux Unified Key Setup (LUKS), which is the standard implementation of disk encryption on a Linux-based operating system.
The flaw actually is in the way the Cryptsetup utility handles password failures for the decryption process when a system boots up, which lets a user retry the password multiple times.
What's even worse? Even if the user has tried up all 93 password attempts, the user is dropped to a shell (Busybox in Ubuntu) that has root privileges.
In other words, if you enter a blank password 93 times – or simply hold down the 'Enter' key for roughly 70 seconds – you will gain access to a root initramfs (initial RAM file system) shell.
Once obtained the root shell on a target Linux machine, you can copy, modify, or destroy the hard disk, or use the network to exfiltrate data.
Vulnerability can also be Exploited Remotely
The flaw, discovered by Spanish security researcher Hector Marco and Ismael Ripoll, affects almost all Linux distributions, including Debian, Ubuntu, Fedora, Red Hat Enterprise Linux (RHEL), and SUSE Linux Enterprise Server (SLES), which potentially puts millions of users at risk.
🔐 Mastering API Security: Understanding Your True Attack Surface
Discover the untapped vulnerabilities in your API ecosystem and take proactive steps towards ironclad security. Join our insightful webinar!Join the Session
Here's what the researchers explain about the vulnerability in their security advisory, which was presented at this year's DeepSec conference in Vienna, Austria:
"This vulnerability allows to obtain a root initramfs shell on affected systems. The vulnerability is very reliable because it does not depend on specific systems or configurations. Attackers can copy, modify or destroy the hard disc as well as set up the network to exfiltrate data. This vulnerability is especially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protected (password in BIOS and GRUB) and we only have a keyboard or/and a mouse."
However, you might be thinking that exploiting this flaw is only possible when you have physical access to the target system. True, but exploiting the flaw remotely is also possible.
If you use cloud-based services that use Linux, you can remotely exploit this vulnerability without having 'physical access.'
Here's How Bad is the Vulnerability
However, it is important to note that this vulnerability does not give an attacker access to the contents of the encrypted drive, though, according to the researchers, this shell allows an attacker perform a series of actions, as described by Marco:
Elevation of privilege: Since the boot partition is typically not encrypted:
- It can be used to store an executable file with the bit SetUID enabled. This can later be employed by a local user to escalate his /her privileges.
- If the boot is not secured, it would then be possible for an attacker to replace the kernel and the initrd image.
Information disclosure: It is possible for an attacker to access all the disks. Although the system partition is encrypted, it can be copied to an external device, where it can later be brute forced. Obviously, it is possible to access to unencrypted information in other devices.
Denial of service (DoS): The attacker has the ability to delete the information on all the disks.
This security weakness has been confirmed to affect Debian, Ubuntu, and Fedora, along with many other Linux distributions. Arch Linux users, as well as Solus users, are not affected by this issue.
Here's How to Fix the Security Issue:
Fortunately, the vulnerability is incredibly easy to fix.
First of all, press the Enter key for about 70 seconds at the LUKS password prompt until a shell appears, just in order to see if your system is vulnerable.
If vulnerable, you will need to check with your Linux distribution support vendor to find out whether or not a patch is available.
If the patch is not available, the issue can be fixed by modifying the cryptroot file to stop the boot sequence when the number of password attempts has been exhausted. For this, you can add the following commands to your boot configuration:
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="panic=5 /' /etc/default/grub grub-installSince a patch is already available, so make sure that you are always using the most recent package versions and up to date operating system.
For more technical details of this vulnerability, you can head on to Hector Marco's website.