So you’ve got command execution on a CTF box and you want to get from a low privilege user like www-data to root? Your first step should really be to get yourself a proper TTY shell, from there I normally run down this list:
ARE YOU ON THE SUDOers List?
Check this first every time. Are you allowed to use sudo to execute certain commands? If you are, then perhaps there is a way to abuse those commands to get more privileges. Some CTFs PrivEsc challenges are as simple as sudo su.
SUID Binaries are a good source of interesting challenges for PrivEsc exercises allowing us to learn about abusing system() calls and pathing issues, symbolic links and timing issues, and in some cases even allowing us to stretch our exploit development legs with stack smashing opportunities!
The first step is finding unusual binaries with the SUID bit set – using the find utility
find / -user root -perm -4000 -print 2>/dev/null
find / Invoking find from the file system root -user root We can change the name of the file's owner here if we want -perm -4000 This is the bitmask for the SET USER ID (SUID) flag -print Prints the full file path of each matching file 2>/dev/null Omits error messages by forcing stderr output to a black hole, you can omit this if you want to see permission denied errors
Don’t bother looking at the standard utilities you’d expect to see in /usr/bin (mount, passwd, su, sudo, etc), but keep a close eye out for anything in the /home directory, or things you wouldn’t expect to see with the SUID flag set (nmap for example).
The next port of call is to start enumerating what you can see in the current user’s home directory, and any other users home directories that you might have access to. Remember to look in hidden directories, stuff like .bash_history, .ssh or .backup files are all very interesting to us, they might contain passwords or other hints we can use.
Weak permissions sometimes results in files which can be written to by any user, but that might be executed with root permissions.
find / -perm -0003 -user root 2>/dev/null | grep \.py$
find / Find, starting at the file system root -perm -0002 Write permission granted to all users -user root Files owned by root 2>/dev/null Redirect errors to a black hole | grep \.py$ Pipe the output to grep, looking for .py files
Good things to look for here are .py, .sh or .pl files, you can also easily tweak the grep expression to look for these, or omit it entirely if you’re willing to dig through the pile of output.
Interesting Processes or Network Services
With a shell on the target system you can probably see more than you could from the outside. Have a good look around at process listings and for services running on loopback addresses or previously undiscovered high numbered ports
This can give quite a verbose output, but is a good way to get a complete picture on the state of the machine. Good opportunities and information can be found in the command lines used to start programs, as well as in identifying potentially vulnerable processes.
This gives a listing of listening processes (switch the l option to a for all), which can reveal some interesting things listening on otherwise uninteresting ports or interfaces.
ls /etc/cron.daily/ tail /var/log/syslog
Services and processes which can be used to elevate privileges can sometimes be found running as the result of a cron task, its also worth checking the syslog for any errors that these may spit out.
Vulnerable Kernel Version
Typically in a CTF type wargame you’re not going to be looking for a memory corruption bug in a kernel, it’s a bit dull and most writers want to give you a bit of a challenge. You’ve also got to bear in mind the age of the CTF you’re doing. If its a 3 year old challenge then there might well be a more recently discovered kernel bug included with it by accident. It’s not the intended solution (not that there’s anything fundamentally wrong with that) and there’s probably a much more interesting solution to the problem which might teach you some stuff. Get your kernel version with uname
Once you’ve got your kernel version you can drop it into a script like the linux exploit suggester for some suggestions about what it may well be vulnerable to. If you want to play fair, limit yourself to exploits released before the CTF.
Most of these checks are bundled into a variety of scripts which check for privilege escalation vulnerabilities which you’re free to use. But you need to be able to spot the misconfigurations in the output, and these tools tend to spit out a long output file for you to comb through.