Targeting python for Local Privilege Escalation
__OVERVIEW
Python has the Python standard library, with many modules on board from a standard installation of Python. These modules provide many solutions that would otherwise have to be laboriously worked out by writing our programs. There are many ways in which we can abuse a Python library to PrivEsc. Much depends on the script and its contents itself. However, there are three basic vulnerabilities where hijacking can be used to PrivEsc.
Importing Modules
#!/usr/bin/env python3 |
There are many ways in which we can abuse a Python library to PrivEsc. Much depends on the script and its contents itself. However, there are three basic vulnerabilities where hijacking can be used:
- Wrong write permissions
- Library Path
- PYTHONPATH environment variable
Wrong Write Permissions
If a Python module has world-writable permissions, any user can modify it. When a privileged Python script (especially one with SUID/SGID permissions) imports that module, the attacker’s injected code inside the writable module will automatically execute with those elevated privileges. This creates a serious privilege-escalation risk because the module becomes a vector to run arbitrary commands as the higher-privileged user.
If we look at the set permissions of the mem_status.py script, we can see that it has a SUID bit set. This means that we can execute the script with elevated permissions.
Checking our sudo privileges reveals the same python script can be executed with elevated permissions by our current user:
sudo -l |
Let’s view the content of the script.
$ cat mem_status.py |
We can see in the second line that this script imports the module psutil and uses the method virtual_memory(). the default path for python modules is at /usr/local/lib/python3.8/dist-packages/.
When this package is imported, the code inside __init__.py file is executed first.
This means that if a script imports a package like psutil and your user account has write permissions over that package’s directory, you could modify the def virtual_memory(): method to include arbitrary code.
When the script runs and imports that package, your code will execute automatically because Python executes the top-level code in the module during import.
start by looking for the method virtual_memory in the psutil directory:
grep -r "def virtual_memory" /usr/local/lib/python3.8/dist-packages/psutil/* |
confirm write permission:
ls -l /usr/local/lib/python3.8/dist-packages/psutil/ |grep `rw` |
Insert reverse shell code to hijack the method before it loads:
...SNIP... |
now when we run the script with sudo, it will execute the reverse shell code and a shell will be opened as root:
sudo -u root /usr/bin/python3 /home/htb-student/mem_status.py |
Library Path Abuse
In Python, each version has a specified order in which libraries (modules) are searched and imported from. The order in which Python imports modules from are based on a priority system, meaning that paths higher on the list take priority over ones lower on the list. We can see this by issuing the following command:
uming all contain a file named mymodule.py.
example_project/ |
Path Listing
$ python3 -c 'import sys; print("\n".join(sys.path))' |
Notice how the sys module is located under one of the lower priority paths listed via the PYTHONPATH variable.
Therefore, if the imported module is located in a path lower on the list and a higher priority path is editable by our user, we can create a module ourselves with the same name and include our own desired functions.
Since the higher priority path is read earlier and examined for the module in question, Python accesses the first hit it finds and imports it before reaching the original and intended module.
In order to exploit this We must have write permissions to one of the paths having a higher priority on the list.
let us continue with the previous example and show how this can be exploited. Previously, the psutil module was imported into the mem_status.py script. We can see psutil‘s default installation location by issuing the following command:
crytix@lpenix:~$ pip3 show psutil |
we can see that psutil is installed in the following path: /usr/local/lib/python3.8/dist-packages. From our previous listing of the PYTHONPATH variable, we have a reasonable amount of directories to choose from to see if there might be any misconfigurations in the environment to allow us write access to any of them. Let us check.
ls -la /usr/lib/python3.8 |
it appears that /usr/lib/python3.8 path is misconfigured in a way to allow any user to write to it. Cross-checking with values from the PYTHONPATH variable, we can see that this path is higher on the list than the path in which psutil is installed in.
Now lets create our module that will get executed before the original and place it
under /dist-packages, we’ll have to name it psutil.py so python recognizes the name
#!/usr/bin/env python3 |
copy our fake module to dist-packages
cp psutil.py /usr/local/lib/python3.8/dist-packages |
test
$ sudo /usr/bin/python3 mem_status.py |
As we can see from the output, we have successfully gained execution as root through hijacking the module’s path via a misconfiguration in the permissions of the /usr/lib/python3.8 directory.
PYTHONPATH Environment Variable
PYTHONPATH is an environment variable that indicates what directory (or directories) Python can search for modules to import. This is important as if a user is allowed to manipulate and set this variable while running the python binary, they can effectively redirect Python’s search functionality to a user-defined location when it comes time to import modules. We can see if we have the permissions to set environment variables for the python binary by checking our sudo permissions:
sudo -l |
As we can see from the example, we are allowed to run /usr/bin/python3 under the trusted permissions of sudo and are therefore allowed to set environment variables for use with this binary by the SETENV: flag being set. It is important to note, that due to the trusted nature of sudo, any environment variables defined prior to calling the binary are not subject to any restrictions regarding being able to set environment variables on the system. This means that using the /usr/bin/python3 binary, we can effectively set any environment variables under the context of our running program. Let’s try to do so now using the psutil.py script from the last section.
crytix@lpenix:~$ sudo PYTHONPATH=/tmp/ /usr/bin/python3 ./mem_status.py |
In this example, we moved the previous python script from the /usr/lib/python3.8 directory to /tmp. From here we once again call /usr/bin/python3 to run mem_stats.py, however, we specify that the PYTHONPATH variable contain the /tmp directory so that it forces Python to search that directory looking for the psutil module to import. As we can see, we once again have successfully run our script under the context of root.