Privileges Escalation Techniques (Basic to Advanced) in Linux
Part-4
Check the previous parts of this series HERE
In this part of this series, I’m going to cover 3 more techniques.
10. Privilege Escalation: Cron Jobs (Script full/Absolute Path Not Defined)
Theory
Cron (daemon/service) is used to schedule a Process or task to execute automatically at a specific time or action (same as task scheduler in windows). By default, they run with the privilege of their owners. (Means who set up that particular job). 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 has their crontab file and can run specific tasks whether they are logged in or not.
The Cron Jobs (Full path not defined) methodology is simple;
- Identify the active jobs.
- Check if any cronjob’s script is not defined via its full path location.
- If found then create a forged file with the same name as the script & cronjob will refer to the PATH to search for that cronjob’s script & in time of searching it’ll trigger our forged instead of the original file.
If the full path of the script is not defined then cron will refer to the paths listed under the PATH variable in the /etc/crontab.
Directories listed in PATH (of cron daemon) are very important. Find at least one that is writable & in high precedence as compare to the location of original job’s script.
Practical
Also, we’ve found one writable directory in the PATH variable of Cron daemon & it’s at top of precedence (/home/user) as compared to the original script location.
Next step, go to that “user” user directory & create a script with the name cronjob’s script.
Wait for the cronjob to run. First, it’ll search for overwrite.sh in PATH & find our payload (forged) script at /home/user in the first traverse so it’ll ignore the original script location at /usr/bin & run the payload one.
After one minute we’ve got a Root SUID set binary. Just run it with -p (to preserve the privileges) to get the root shell.
11. Privilege Escalation: Sudo (version)
Theory
Sudo program for Unix-like computer operating systems that enables users to run programs with the security privileges of another user, by default the superuser.
- The sudo (version) methodology is simple;
1. Check the version of the Sudo program
2. Search & find an exploit code for that program.
3. Run the exploit to gain root privileges.
Sudo program in Linux has tons of vulnerabilities so very easy & common way to gain root access.
Practical
Check the version
So, it’s confirmed it is vulnerable to CVE-2019–18634.
To Learn about this CVE check this
Download the CVE-2019–18634 exploit code & compile it.
Check this tool to Automatically Perform SUDO Program Vulnerabity Assessments & Testing
12. Privilege Escalation: Library hijacking (Python) via Higher Priority Python Library Path with Broken Privileges.
Theory
Python is a high-level, general-purpose programming language.
PYTHONPATH is an environment variable which you can set to add additional directories where python will look for its modules and packages.
The library hijack methodology is simple; (Not work if a full/absolute path of library use in python script is defined)
1. Check for libraries use in the python script.
2. Check the PYTHONPATH variable.
3. Check all the path's permission & If any of these search paths are world-writable, it will impose a risk of privilege escalation.
If the full path of the python module/library is not defined then python will refer to the PYTHONPATH.
Directories listed in PYTHONPATH are very important. Find at least one that is writable & in high precedence as compare to the location of original job’s script.
Practical
We’ve got a python script that can be run via ROOT privileges.
In this script, 2 libraries are being called but not with the full path so we can exploit it.
Now, let's check the PYTHONPATH env variable to check all the paths configured.
So it’s clear that we’ve got the write privilege in the Top/highest (the directory from where the script is being executed) Precedence Path of the PYTHONPATH variable.
here /usr/lib/python3.5/zipfile.py (original library path) precedence less than a directory of the script being executed.
Create a forge library in the path where our python script is.
zipfile.py (Our payload which we’ll create on the directory where the script is available/executed).
Behind the scene: Python searches for a library named zipfile & it’ll find it first in the current directory from where we call our script (bak.py) so it take that one library (Our Payload) & ignore the original library (which is at /usr/lib/python3.5/zipfile.py all because of precedence order of Paths.
If you want to support us then you can via the “buy me a Coffee” link given below.
