Linux Privilege Escalation – Writable passwd file

Introduction

The /etc/passwd file is used in Linux operating systems to store user information such as user hashes, groups, home directory and more.

If improper file permissions are used for this file, this could allow attackers to escalate privileges to root.

Passwd File & Format

The passwd file used to store user hashes although it no longer does, as these are now stored in the /etc/shadow file. The reason why this was changed is that some of the information stored in the passwd file has to be world-readable for the operating system to operate correctly, so hashes were moved to the shadow file which is normally only accessible by root.

The file uses the following format to store information:

Each line of the passwd file is made of the following elements:

1. Username: Used for authentication
2. Password: This is where the hash used to be, it has now been replaced with an “x” to indicate it is stored in the /etc/shadow file.
3. User ID (UID): Every user has a unique user ID used to identify them.
4. Group ID (GID): Every group has a unique user ID used to identify them.
5. User ID Info: This is used to add comments or additional information about the user .
6. Home directory: The directory used when the user logs in.
7. Shell: The shell or binary used by the user(sh, bash, ash, csh etc.)

How does the attack work?

This file is normally editable by the root user, but if for whatever reason this was changed to allow normal users to edit it, this could result in a full system compromise.

In order to retain compatibility with legacy Linux systems, if a user hash is inserted in place of the “x” character, this will still be taken into consideration when a user logs in. Therefore, an attack can performed by generating a new user hash and either adding a new line to the file, using 0 as a user and group ID, effectively adding a new user to the system, or simply modifying the existing root user’s hash to login as root.

Generating a new User Hash

In order for this attack to work, a new user hash needs to be generated. This can be done through various tools.

OpenSSL

The “passwd” command of the OpenSSL utility, which comes installed with most Linux distribution, can be used to generate a new password.

The syntax is as follows:

openssl passwd -1 -salt [hash salt] [password to be used]

Example below:

mkpasswd

mkpasswd encrypts the given password with the crypt(3) libc function using the given salt.

The syntax is as follows:

mkpasswd -m [encryption algorithm] -S [hash salt]

Example below:

Python

The Python crypt module can be used to generate user hashes.

The syntax is as follows:

python3 -c 'import crypt; print(crypt.crypt([password to be used], "$6$[hash salt]"))'

Example below:

PHP

The PHPpassword_hash function can be used to generate password hashes.

The syntax is as follows:

php -r "echo password_hash('sha256', PASSWORD_BCRYPT, array("salt" => [hash salt])). \"\n\";"

Perl

The Perl crypt function encrypts strings using the system crypt( ) function.

The syntax is as follows:

perl -le 'print crypt([password to be used], [hash salt])'

Example below:

Exploiting writable passwd file

Once a user hash has been generated, this can be added to the passwd file. The new line should look like the following:

hacked:$1$stef$ZYhbekI8UymZof5o8aY3A/:0:0:test:/root:/bin/bash

The easiest way to add a new line is using a text editor, like vi, vim or nano:

If text editors can’t be used, the new line can be added using tools like echo:

Alternatively, the root hash can be changed by replacing the “x” in the passwd file. This can be done by using text editors or text processing tools like awk or sed:

To switch to the new user, if using an interactive shell the su command can be used, otherwise remote authentication tools such as SSH could be used

As seen in the screenshot, after changing to the hacked user, root privileges are obtained.

Conclusion

This attack demonstrates how improper file permissions can allow for a very trivial privilege escalation, and although this isn’t that common as it isn’t a default setting, it’s something that should always be checked when performing privilege escalation checks.