Privilege escalation in Linux

Privilege escalation in Linux: going for the kill

As I am starting today the OSCP, I was realizing the quantity of incomplete privilege escalation guides out there. So I decided to post this article describing all the privesc methods I´ve found so far.

First of all I normally start going to /tmp and downloading two scripts: LinEnum.sh and linux smart enumeration from diego treitos.

Personally I prefer the smart enum script, because of the format question:answer (is very easy to read). There is a lot of information there, and it may directly guide you to the vulnerability you are looking for, but other times you may need to do manual checks.

1. SUDO abuse
2. SUID/GUID abuse
3. Kernel Exploits
4. Credentials
5. Cronjobs/services running as root
6. Capabilities
7. Writeable things
8. NFS shares
9. Services running at localhost
10. Docker, Lxd groups

SUDO abuse

We can know if we are allowed to run anything as SUDO by doing sudo –l. There are various ways to abuse this:

• Escape to /bin/bash. Example: sudo vi, and then :!/bin/sh. For SUDO, SUID, capabilities and other privesc vectors you have GTFOBINS (https://gtfobins.github.io/ ).
• Abuse intended functionality: for example an script that runs ping –c1 on the first argument you could do sudo script localhost; /bin/bash (command injection). For this type of abuse, it is mandatory to try to know the whole execution flow of the program, varying inputs and parameters, trying to be aware of how/when the program is reading/writing to a file, what is executing (may lead to a PATH hijacking vuln), if it is getting input from a file/dir/environment variable we can modify, etc. This can be achieved reading the script using cat, or if it is a binary, using strings and strace and ldd (to view syscalls for PATH hijacking/LD_PRELOAD vulns). It is just a matter of understanding what do we have control over and how that can be exploited to achive root. In essence, knowing what/how/when the program is interacting with anything and how we can interact with the program itself and with the elements the program interacts with (ex: symlink a file the program opens and prints to /etc/shadow). An example of unintended functionality abuse would be being able to sudo pip or npm, and install a malicious package.
• LD_PRELOAD and LD_LIBRARY_PATH: if when you do sudo –l it appears something like: env_keep+=LD_PRELOAD, you just need to follow this steps: https://touhidshaikh.com/blog/?p=827, this is also a good article on this technique: https://www.boiteaklou.fr/Abusing-Shared-Libraries.html
• Write permissions over the file (put reverse shell there). Also, if you can sudo ls (for example) you can hijack the PATH variable (it should specify /bin/ls for that not to occur). Or even if the file is nonexistent, you can place a malicious file there.
• Vulnerable to exploit: maybe you just need to searchsploit or maybe you have to write your own exploit, but consider this option (even more if you can see a version of the installed program ex: whatever v2.4, check directories in the PATH variable for this kind of software).
• Wildcard injection (explain in depth at the Cronjob part).

SUID/GUID Abuse

Programs with the SUID bit set can be abused in the same way than SUDO programs, linux smart enum script finds all SUID files, check everything in the above section.

Kernel exploits

This is normally my last option. When there is no other choice, I use linux-exploit-suggester.py (https://github.com/mzet-/linux-exploit-suggester ).

Credentials

• In memory: if gdb is available, you can try to do gdb –p PID, info proc mappings, dump memory outfile startmemoryregion stopmemoryregion.
• In config files: find / -name "*.conf" -exec grep pass{} \; or similar commands to search for passwords in configuration files such as apache2.conf. By default they are stored under /etc. If you just hacked a CMS, it may be convenient to look for the file that manages the connection with the database to get passwords/hashes.
• In logs /var/log/whatever may be passwords too.
• Check for files under /var/mail or uncommon directories elsewhere.
• In bash_history under /home/user as well as other history files. Maybe you can find previous commands (like Tmux sessions that you can hijack or references to files that you will use for escalating privileges).
• ALWAYS try to reuse credentials (people tend to use the same password for everything).

Cronjobs/services running as root

The box where you are trying to get root may have programs running every x amount of time.

Cronjobs can be seen at /etc/crontab, in /var/spool/cron or with crontab –l, also you can use pspy to see those processes running: https://github.com/DominicBreuker/pspy. Take into account systemd timers too: https://www.prodefence.org/uptux-privilege-escalation-checks-for-linux-systemd/ as well as startup scripts (located at /etc/init.d)

There are several ways to exploit this kind of processes:

• PATH hijack: if when you cat /etc/crontab or watch the process in pspy don´t see a full path in some command you can put a reverse shell file named as the file the cronjob is calling in a writeable directory in PATH (must be before the directory where the original file is placed)
• File overwrite: check if you have write permissions to the file called by the cronjob, if you have, you can just write there your reverse shell
• Symlinking: sometimes you just need to symlink a file used by the process to a useful file like /etc/shadow
• Wildcard injection: if the cronjobs does something like tar –xvf /dir/* that means you can inject parameters into the cronjob. The * character expands to all files in the directory. You can place files named –abusableparameter in the directory, so when the cronjob runs, it will take your file and use it like a parameter. This is the best resource on this topic I´ve found: https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt if the process using a wildcard isn´t there, check its man page and try to figure out which parameters are useful to privesc.

Files with capabilities

Some files have special permissions that let them do things other programs aren´t allowed to. A good example of capability abuse is: https://nxnjz.net/2018/08/an-interesting-privilege-escalation-vector-getcap/

Writeable things

If after running your enumeration scripts, you see writeable files like: /etc/passwd, /etc/shadow, /etc/sudoers, /root/.ssh/authorized_keys or config files like apache2.conf, then you are are almost root, copy your config in your Kali box and paste it there (this work in some cases, google the rest). If you notice write permissions of a script owned by root, there is surely a cronjob running that script.

NFS shares

Maybe you have noticed a share in /etc/exports. If the no_root_squash option is set, you are lucky. Here is a very good article covering this: https://touhidshaikh.com/blog/?p=788

Services listening in localhost

You will find sometimes, that the box you are trying to root is listening to services you can´t access from outside the box. For example, mysql running on (3306), VNC or others. For MySQL you can try to reuse credentials (or get credentials from files like wp-config.php) or use an UDF to get root shell https://infamoussyn.wordpress.com/2014/07/11/gaining-a-root-shell-using-mysql-user-defined-functions-and-setuid-binaries/. If you wanna access those services from your machine I recommend you to have a look at this post: https://ironhackers.es/en/cheatsheet/port-forwarding-cheatsheet/ Then you should enumerate the service as you would do in the initial phase of the pentest.

Docker/lxd group

First of all if you see a .dockerenv file, you are in a docker container. If you are a member of the docker group you can abuse it easily by accessing the filesystem as root (https://root4loot.com/post/docker-privilege-escalation/, a really short video: https://www.youtube.com/watch?v=AtO5TDJnieA). If you are a member of the lxd group: follow the steps here to abuse it https://reboare.github.io/lxd/lxd-escape.html (pretty the same thing than the Docker privesc)

Well that was all I take into account when performing a privilege escalation. Comment if you want me to add anything.

References:

-https://www.hackingarticles.in/privilege-escalation-cheatsheet-vulnhub/

-https://github.com/sagishahar/lpeworkshop

-https://bitvijays.github.io/LFC-VulnerableMachines.html#linux-privilege-escalation

-https://percussiveelbow.github.io/linux-privesc/

-https://guif.re/linuxeop