Why a Linux CTF CheatSheet?
Recently while looking through some #infosec tags on twitter I came across a cheat sheet for Linux Ethical hacking. While reading the sheet I noticed that a lot of the cheats were also a list of common footholds used in Linux Capture the Flag Challenges. So here I will list them and expand on them a bit with a “Linux CTF Cheatsheet”.
I know something line LINpeas.sh will pick most of this up but running scripts does not allow us to learn anything. I will show you where to spot them and some suggestions on exploiting them.
As always, I use my custom build BlackArch install, but you can use any Linux flavor.
Common Linux CTF SUID vulnerabilities.
Simply put when the “suid“bit is set on an executable file, this means that the file will be executed with the same permissions as the owner of the executable file.
An “suid” exploit is a common in Linux CTF Challenges. Usually after you get a “reverse shell“, or “ssh” it’s one of the first things to check for. You can find them on a Linux system by using the below command.
find / -perm /4000 2>/dev/null
Typically this will output a list commands we expect to find with an “suid” bit, but what if something like “base64” shows up, how do we handle that? If “base64” has an “suid” bit then you can read any file on the system. The below command is from the wonderful site gtfobins
./base64 /etc/shadow | ./base64 -d
Also on gtfobins you can find a lot of other commands and instructing on how to spawn a shell or run some other privileged command that allows you to read a file or flag from another user. If you find a “suid” bit on a binary be sure to check gtfobins out.
Common Linux CTF Sudo Vulnerabilities
Sudo stands for either “substitute user do” or “super user do”. sudo allows a user to run a program as another user most often the root user but not always.
Looking for binaries with “sudo” access is another one that should be high on your list when you get access to a system via “ssh” or a “reverse shell“. Like with “suid” the misuse of “sudo” on binaries are often found on gtfobins . Linux Based CTF Challenges more often than not have a command wrapped up in sudo, which can be exploited.
Common Linux CTF Cron Vulnerabilities
The cron command-line utility, also known as cron job, is a job scheduler on Unix-like operating systems. Typically within Linux based CTF Challenges where you find a cron-job you will find a badly configured cron-job that can be misused.
These jobs are usually found listed in the file “/etc/crontab“. See the screen shot below for an example where there is a “cron” job running every two minutes for root but the permissions on that file are awful. This can be used to spawn a “reverse root” shell.
A Linux container is a set of 1 or more processes that are isolated from the rest of the system. All the files necessary to run them are provided from a distinct OS image like Ubuntu, Centos, etc. From an application point of view the container looks like a dedicated OS, but this is not the case. Head on over to docker.com to find out more about containers.
Common Linux CTF Docker Vulnerabilities
Docker is usually combined with one of the other ones like “sudo“. If you only have “sudo” access to the “docker” command you can do something like the below to get root access to the “/” file system.
sudo docker run -it --rm --name alp -v /:/mnt alpine /bin/ash
How does this work?
Being allowed to run “docker” in “sudo” as root allows any file system to be mounted inside a container. Here we are mounting the real “/” inside the container as “/mnt”. When the container is spawned we are automatically logged into as root so we have full access to the root file system.
Common Linux CTF runc Vulnerability
Like the above we can mount the real “/” inside a container for access. Although the steps are slightly different.
First we have to create a directory structure for “runc”.
mkdir -p ~/mycontainer/rootfs
Then as a regular user we have to create the spec file.
This creates a config file called config.json. Then edit this spec file to add the rouge “/” file system. Add the below to the mount section of the config file.
"options": [ "rbind", "rw", "rprivate" ]
Now just start the container with “sudo” and you get a root shell which has the real “/” mounted as “/” in the container. Effectively giving you root access.
sudo /usr/local/bin/runc run mycont
Linux Bad File Permissions
Its always worth checking permissions on files such as “/etc/passwd“, “/etc/shadow” if you have access to both of these you can run “john the ripper” against them to crack the hashes and giving the the passwords for users.
Common Linux CTF Bad Services
Sometimes those sneaky CTF Challenge authors put in a vulnerable service that has a well know exploit. After running nmap and we see a server running we tend to focus on logging in to that service. However if we take a closer look at the version of the software we might find something useful.
An common example that that pops up in Linux CTF Challenges is VFSPD version 2.3.4. If that is shown in “nmap” results, then alarm bells should start ringing. This version has a hidden backdoor that was added by some “bad folk” into the main github repository in 2011. The developers found the issue quickly and patched it. Unfortunately not before some of the CTF Authors seem to have got a copy.
Top Security bugs in Linux CTF Challenges.
Many Linux CTF challenges have exploits because the systems are not patched. Below you will 3 of the most common ones I have come across in 2022.
In January 2021, Qualys released a blog post detailing a new vulnerability in the Linux “sudo” program. this was a heap buffer overflow allowing any user to escalate privileges to root. CVE-2021-3156 only needs access to the Linux system as a regular user and if the system is not patched, it can be easily exploited. Searching for this CVE over in the marvelous exploit-db.com you can find 3 exploits that can be used in Linux CTF Challenges to get a foot hold.
CVE-2021-4034 (“pwnkit”) was discovered by researchers at Qualys and announced in January 2022. You read the security advisory for this vulnerability here. It quite a bad one as most systems were effected going back years. Like the “sudo” one it needs a local user in order to exploit. The exploit is easily available on exploit-db.
One of the worse Linux security bugs ever, is a rare find in the real world these days but can crop up on some Linux CTF Challenges. Given the impact of this, CVE-2014-6271 it worth familiarizing yourself with how bad bugs can really get. Usually you would use C2 (command and control) framework such as metasploit to take advantage of shellshock.
Hope this was useful. If so or if not leave a comment as I am always interested to hear from my readers.