In the next lines, we will see together several real examples of privilege escalation. We will use labs that are currently hosted at Vulnhub. Of course, we are not going to review the whole exploitation procedure of each lab. Instead, we will suppose that we have already gained access to the machine and, together, we will move from an unprivileged user into the root. We will perform all the privilege escalation techniques manually. This means that no automatic tools will be used to escalate the privileges. Of course, though, tools and papers will be given as reference at the end of the article. Before you begin reading the next lines, I suggest you have a look at my personal Privilege Escalation Bible: G0tmi1k: Basic Linux Privilege Escalation written by the very talented g0tmi1k. The purpose of the article is to give you an idea of how privilege escalation looks and works on real machines. We will not attempt to explain all the available techniques as this would require several articles and at the same time, g0tmi1k and other people have done this before, perfectly.

Lab 1: VulnOS 2

VulnOS version 2 is a very common boot to root lab available at Vulnhub. Once someone manages to exploit the vulnerability and gain a shell, we will probably see something like the following:

The things that we should do first are:

Check the OS Release of the vulnerable system View its Kernel Version Check the available users and the current user privileges List the SUID files. Read more here: Common Linux Misconfigurations – InfoSec Resources – InfoSec Institute View the installed packages, programs and running services. Outdated versions might be vulnerable.

Of course, each time we will be looking for other information but for now, the above will do the job. Let’s try to view the OS Release of the lab machine. By executing: $ lsb_release -a We can see something like the following:

Moreover, by running: $ uname -a We can also see the Kernel Version:

During privilege escalation, we will find ourselves testing again and again. We will be searching for possible techniques to escalate and each time one comes to our mind; we will attempt to apply it. We will be testing exploits against the system, exploits against services, we will brute force credentials and in general, we will be testing all the time. Now that we know the OS Release Information, Ubuntu 14.04.4 LTS, and the Kernel Version, 3.13.0-24-generic, the first thing we can try is the popular exploit called: overlayfs. This exploit is supposed to work on Ubuntu 12.04/14.04/14.10/15.04 and Linux Kernel after 3.13.0 and before 3.19. So, it should work fine. Let’s test it. We first move to the tmp directory which we will be able to create a file, paste the exploit code and then compile it. The commands we should run are: $ cd /tmp $ touch exploit.c $ vim exploit.c Then, we should paste the exploit code inside the file, save and exit. Now, we have to compile the exploit. To do this we run: $ gcc exploit.c -o exploit And now we only have to execute the exploit file to see if our exploit works. By running: $ ./exploit We can see something like the following:

As you can see, the exploit has been executed successfully, and we have root access. The python command you can see was used to get a proper shell. The command used: $ python -c ‘import pty; pty.spawn(“/bin/bash”)’ Even if this wasn’t a difficult lab to perform privilege escalation, the method used is one of the most common techniques, and it applies to several systems. I personally suggest you to always check if the overlayfs exploit works. Keep in mind that there are several versions of this exploit which apply even to newer kernel versions. Have a look here:

Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) – ‘overlayfs’ Local Root Shell Linux Kernel 4.3.3 (Ubuntu 14.04/15.10) – ‘overlayfs’ Local Root Exploit Linux Kernel 4.3.3 – ‘overlayfs’ Local Privilege Escalation

Make sure you use the proper one according to the kernel version!

Lab 2: Mr. robot

Mr.Robot is another boot to root challenge and one of the author’s most favorite. I decided to show its privilege escalation part because it will help you understand the importance of the SUID files. If you don’t know what SUID files are, please have a look here. Once we manage to access the shell, we can see something like this:

Here, we have accessed an account with username “daemon“. Let’s see how we will manage to escalate from daemon to root. This box is an Ubuntu 14.04 trusty with Linux Kernel version: 3.13.0-55-generic. All the exploits against the OS and the Linux Kernel have failed.

Thus, we should come up with a new idea. As mentioned previously, we should always be checking the SUID files available in the system. By running: $ find / -perm -u=s -type f 2>/dev/null We can see something like the following:

Here, we have listed all the SUID files. Can you notice something strange? Why would Nmap have the SUID flags? Let’s see. First, we should run the following command to learn Nmap’s version: $ /usr/local/bin/nmap –version And the output is:

An outdated version of nmap is installed! But how can this help us escalate to a privileged user? Back in the day, Nmap supported an option called “interactive.” With this option, users were able to execute shell commands by using a nmap “shell” (interactive shell). Many times, security researchers were using this option to avoid logging their nmap commands in the bash history log file. Here is how nmap interactive looks like:

As we can see, we can execute shell commands by typing “!” followed by the command we would like to execute. Thus, the: “!sh” command should normally pop a shell. And as nmap has the SUID flags, we should normally get a root shell.

And, we are in! We can now execute commands as root. It is true that during your tests you will -probably- never find Nmap 3.48 with SUID flags set. This example was demonstrated to make you understand how important is to check for SUID in Linux. There are several labs at Vulnhub based on this technique. Every time, different programs have been assigned with the SUID flags so that you can experiment with them. Feel free to try them.

Lab 3: Pwn-Lab-Init

Pwnlab is another lab hosted by Vulnhub. Again, one of the author’s favorite challenges. Once the attacker manages to get a shell (for several accounts but not root), he can see something like this:

Currently, we are logged in as user “kane“. Unfortunately for us, the OS Release wasn’t vulnerable to any documented attack. At the same time, none of the kernel exploits helped. Moreover, the SUID files were looking fine except a file located under Kane’s home directory named “msgmike.”

So, let’s attempt to list the files under the home directory to see what we have.

From what we can see, we have an ELF 32-bit LSB executable. When executing the file, we get the following error:

This let us know that the program is trying to call the cat command to view the contents of a file called msg.txt available under the home directory of a user called mike. Moreover, let’s recall the the file is SUID. What should we do now? There is a popular technique where attackers manage to manipulate the $PATH bash environmental to escalate their privileges. Imagine what would happen if we edit the $PATH variable and instead of the default value we put a new one, a simple dot (.). Whenever a program (executable) is called, bash will look at the “.” directory for the program instead of /usr/local/bin, /usr/bin and more. Let’s see what this mean. A normal PATH variable looks like this:

Whenever I call a program – like cat – bash will look for the above directories for it. Let’s make a file called cat with the following contents inside:

Of course, we must make it executable with the following command: $ chmod +x cat Now, let’s change our PATH variable to “.”. This will make bash look at the “.” (current) directory every time it needs to run a program.

Can you imagine what would happen if we execute the msgmike program again? As you can recall, msgmike executes the cat command to view the contents of a file (/home/mike/msg.txt). Now that we have changed the PATH variable, though, it will look for the cat program inside the current directory. As we have created an executable file called cat – which pops a shell – our cat file will be executed, and we should normally get a shell as mike. Let’s see!

As you can see, we have successfully logged in as mike! The real challenge doesn’t stop here, though. The next steps to log in as root are not hard, but we will not cover them as they deal with Command Injection attacks something that is out of the scope of this article. The reason we examined this lab-example is to understand that several times we should think of non-common techniques to perform privilege escalation. It goes without saying that we should first check for common ways to perform privilege escalation but several times you will deal with machines like the previous one. I hope you enjoyed this article as much as I did. If you have any questions, please, do not hesitate to comment!