Security News You Can Bypass Linux Disk Encryption Authentication by Pressing the Enter Key for 70 Seconds

[Venustus]

An error in the implementation of the Cryptsetup utility used for encrypting hard drives allows an attacker to bypass the authentication procedures on some Linux systems just by pressing the Enter key for around 70 seconds. This results in the attacked system opening a shell with root privileges.

The issue, tracked as CVE-2016-4484, was discovered by Spanish security researcher Hector Marco, who also found last year that you could bypass GRUB2 authentication on Linux systems just by pressing Backspace in the username field 28 times.

This time, Marco was studying Cryptsetup, a utility that allows users to encrypt their hard drives via LUKS (Linux Unified Key Setup).

Cryptsetup allows users to retry passwords over and over again
The researcher discovered problems in how Cryptsetup scripts handle the boot process when the user is asked for the encryption password. This password is needed to decrypt information on protected hard drives, boot the system, and grant the authenticated user access to his data.

"The fault is caused by an incorrect handling of the password check in the script file /scripts/local-top/crypt rot," Marco explains. "When the user exceeds the maximum number of password tries (by default 3), then boot sequence continues normally."

Marco says that Cryptsetup interprets this error as a "slow device" that needs more time to warm-up. Because of this design error on the developer's part, Cryptsetup allows the user to retry his encryption password by reloading the authentication procedure.

This procedure is reloaded up to 30 times on an x86 system (93 total password tries), and 150 times on a PowerPC machine (452 total password retries).

Cryptsetup opens a shell with root privileges
While the password retries aren't enough to carry out a brute-force attack, Marco says that the bigger problem appears when the user has exhausted all authentication attempts.

As you can see from the image above, instead of blocking access to the user's system, Cryptsetup starts an Initrd shell with root privileges, most likely for debugging purposes.

An attacker could use this shell to 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. Which can later be used to escalate privileges by a local user.
  • If the boot is not secured, then it would be possible to replace the kernel and the initrd image.
• Information disclosure: It is possible to access all the disks. Although the system partition is encrypted it can be copied to an external device, where it can be later be brute forced. Obviously, it is possible to access to non-encrypted information in other devices.
• Denial of service: The attacker can delete the information on all the disks.

All in all, an attacker wanting to skirt all the repeated password prompts and just access the shell, needs to hold down the Enter key for approximately 70 seconds or more.

Some Linux systems affected, including cloud servers
LUKS is one of the standard methods for encrypting hard drives on Linux. The issue Marco discovered affects only Linux distros based on the Debian distribution, such as Ubuntu.

"The initrd script is a Debian-specific patch only affecting the distributions derived from Debian (such as Ubuntu)," Lubomir Rintel tells Bleeping Computer. "It does *not* affect other distributions that use Linux, LUKS or cryptsetup. E.g. Fedora utilizes unmodified cryptsetup along with systemd to deal with the device unlocking and is not affected by the problem."

UPDATE [10:45 EST]: A few hours after this article went live, Marco announced on his site that after further tests, Fedora distros are vulnerable as well. "We have found that systems that use Dracut instead of initramfs are also vulnerables (tested on Fedora 24 x86_64)," Maroc wrote.
Furthermore, exploiting the flaw requires physical access to the affected device, in order to trigger the boot procedure and access the terminal. For cloud-based services, where Linux systems are used en-masse, the attacker can exploit this flaw remotely.

Marco blames the presence of this shell at the end of a failed authentication system on the Linux community itself.

"In general, the GNU/Linux ecosystem (kernel, system apps, distros, ...) has been designed by developers for developers. Therefore, in the case of a fault, the recovery action is very 'developer friendly', which is very convenient while developing or in controlled environments," Marco says. "But then Linux is used in more hostile environments, this helpful (but naive) recovery services shall not be the default option."

For his part, Marco says he proposed a fix that halts the boot execution and prevents the repeated password guesses. He also recommends that Cryptsetup developers remove the problematic functionality, for the sake of security.

A fix for CVE-2016-4484 was added to Cryptosetup version 2:1.7.3-2, albeit not in the stable branch. The fix was incorporated in Debian distributions on November 7, while Canonical has delayed the patch.

UPDATE [06:15 EST]: Article was updated with information about Cryptosetup, Debian, and Ubuntu patch status, along with a quote from Mr. Rintel that clarifies the vulnerable attack surface. Title was also updated to reflect that the flaw allows bypassing disk encryption authentication procedures, not the actual encryption. Encrypted data is safe, but attackers can get root privileges on targeted systems.

 

[Fritz]

How great is that. There you got hackers sitting in dark basements night and day dreaming up insane hacks using quantum mechanics while all they really needed was a pinky and a good minute of their time. Priceless.

 

[askmark]

It could have been worse, at least the disk encryption remains intact. That being said, providing the user with a shell with root priveleges is something best avoided!
Thanks for sharing this illuminating article.

 

[DardiM]

Thanks for the share

Why searching for hard bypassing methods ? (because also hackers need some rest time too, what else ?).

Windows, Linux, etc : always some news that prove nothing is really secure.

But the fact that hackers have to interact with the physical device (in most cases) makes this method has certainly been very few (if never) used to really bypass the tool.

 

[Jake Miguel]

Is this for real?

 

[tim one]

Thanks for the info @venustus
By reading this article perhaps it is not particularly necessary to be expert to do damage.

 

[jamescv7]

Those vulnerabilities lately for Linux are so simple [although fixed from numerous release] which people could not even notice that it can manage.

One of the prime example is way back on 6 to 7 years ago perhaps; where you can bypass certain operation by clicking backspace key numerous times.

 

[Vipersd]

Main reason for this vulnerabilities is short release time between OS versions. With longer period of testing much of this would be already solved.

 

[SKG2016]

This is such hilarious/

 

[Myriad]

Hardly a week goes by without one of these " Linux is broken " shock horror stories.
My reactions vary between a laugh and a yawn.

Many require that a would-be attacker has free physical access to a machine .
Would you leave your wallet unattended in a public bar ? .... I think not .

No disrespect to Sr. Hector Marco , but I really have to wonder how many keystrokes were tried before hitting on
the magical "Backspace" 28 times , or "Enter" for 70 seconds .

He must either have vast amounts of spare time or be exceedingly lucky.

And if it is the latter , he should head for the nearest casino or lottery seller asap , and forget about computer security .