Linux Privilege Escalation and Persistence

Topic: Abuse of SUID Binaries (/bin/bash)

⚠️ Ethical Disclaimer

This tutorial is for educational and authorized testing purposes only. modifying system binaries on a production server without authorization is illegal and can cause system instability. Always perform these labs in a controlled virtual machine environment (e.g., Kali Linux, Ubuntu VM).

1. Introduction

In Penetration Testing, “getting in” is only half the battle. The second half is Persistence—ensuring that if the system administrator patches the original vulnerability or changes passwords, the attacker can still regain access.

This lecture analyzes a classic Linux persistence technique: creating a SUID Backdoor using the system’s own shell, Bash.

2. Theoretical Background

The Shell (/bin/bash)

When you interact with a Linux terminal, you are running a program called a “shell.” The most common is the Bourne Again Shell (Bash). It lives on the file system at /bin/bash. Like any other program (Firefox, Python, Grep), it adheres to Linux file permissions.

SUID (Set User ID)

Linux permissions usually look like this: rwx (Read, Write, Execute). However, there is a special permission bit called SUID.

• Standard Execution: When you run a program, it runs with your permissions.
• SUID Execution: When you run a SUID program, it runs with the permissions of the file owner.

If a file is owned by Root (the superuser) and has the SUID bit set, anyone running that file effectively becomes Root for the duration of that program’s execution.

3. The Attack Vector: Creating the Backdoor

In the video demonstration, the attacker assumes they have temporary Root access and want to leave a “key” under the doormat to get back in later.

Step 1: Modifying Permissions

The attacker locates the system shell and modifies its mode.

Command:

sudo chmod +s /bin/bash

Breakdown:

• sudo: Executes the command with current admin rights.
• chmod: (Change Mode) The utility used to change file attributes.
• +s: This is the critical flag. It adds the SUID bit to the file.
• /bin/bash: The target binary.

The Result:

If you list the file details (ls -la /bin/bash), you will now see an s in the permissions string (e.g., -rwsr-xr-x). This indicates that the binary is now a SUID binary owned by root.

Step 2: Triggering the Exploit

Later, the attacker returns as a low-privileged user (e.g., “kali”). They cannot run administrative commands directly. However, they can execute the modified shell.

Command:

bash -p

Why the -p flag?

This is a specific security feature of Bash. By default, if Bash detects it is running with SUID privileges, it will drop them for safety reasons to prevent accidental misuse.

• The -p flag stands for Privileged Mode.
• It forces Bash to retain the effective user ID (which is now Root because of the SUID bit).

Step 3: Verification

Once the command runs, the command prompt changes (often from $ to #).

Command:

whoami

Output:

root

The user is now the system administrator and has total control over the file system, bypassing all password requirements.

4. Analysis and Defense (Blue Team)

As security students, you must understand how to detect and prevent this.

Why is this dangerous?

This is a Persistence Mechanism. It allows an attacker to bypass authentication (SSH keys, passwords) entirely. As long as that “s” bit remains on Bash, the system is compromised.

Detection

System administrators should regularly audit their file systems for unexpected SUID binaries.

Audit Command:

find / -perm -4000 -type f 2>/dev/null

• This command searches the entire filesystem (/) for files with the SUID bit set (-perm -4000).
• If /bin/bash (or a copy of it like /tmp/bash) appears in this list, it is a massive red flag.

5. Summary