Daemons are processes that run in the background and are automatically started at boot time. Daemons are generally started up with higher privileges, then after start up is complete, privileges are dropped. Some common daemons are sshd, nfsd, apache2, and exim4.
How do you list out daemons and services on the target system that could potentially be vulnerable? Below is a handful of commands I run to list out services running on the machine. Also, it’s smart to list out services running as root and see if any of these services have a known vulnerability. If there’s an exploit for a service running as root, that will lead to root privileges on the machine.
ps auxcat /etc/servicesps aux | grep rootls -alh /usr/bin/ls -alh /sbin/dpkg -lrpm -qals -alh /var/cache/apt/archivesOls -alh /var/cache/yum/
All these outputs provide quite a bit of information. So how do we make use of all this information? Let’s first analyze the output of the ps aux command. The ps aux command will provide information such as the user the process is being run as, the process ID, the time it was started, and the command used to start the process. An example can be seen below:
This will provide a general idea of what is currently running on the machine. In the example screenshot above, you will notice something that says sshd: root@pts/0. Even if you knew nothing about services, just by looking at this you could probably make a guess that there is someone else ssh’d into the machine as the root user. One thing to keep in mind, is the output of ps aux only provides the status of processes that are running. We will come back to this output, but it’s first good to understand what exactly is going on with this particular output.
I’m going to skip around a bit, but the next command I’d like to focus on is the dpkg -l command and the rpm -qa command. These are both similar, but they are for 2 different distributions of Linux. The first one is for Debian based machines (which means it will also work for Ubuntu), and the second is for Red Hat based machines (CentOS, Red Hat, Fedora). They both provide the output of the packages installed, along with their respective version number. The version number is going to be a critical piece of information when we attempt privilege escalation against a service. How can we make this information useful?
Putting it All Together
Remember the first command we ran ps aux? That gave us a list of running processes. So, let’s run that command in one terminal, and then let’s run dpkg -l in another terminal and put them side by side like below so we can see the outputs:
So, what do we do now that we have both of these terminals up with all this data? Remember, the first command will show us all the processes that are currently running on the machine. The ones we are mostly interested in are the ones running as root because if exploited successfully, we will inherit the privileges of the service we exploited, but this is not always the case. To refine the results, we can instead run ps aux | grep root to list only services running as root. In our example, I am not going to filter by root so we don’t limit ourselves.
The terminal on the right-hand side lists out ALL the packages and programs installed on this current build of Linux. There is far more output on the right-hand side than the left. So, we will use the left terminal to narrow down our results. Now this next part is going to sound tedious, because it is. There are ways to automated what I’m about to go over (which we will discuss later in the section), but I want you to go through it yourself so you fully understand the importance of enumerating.
We will start from the bottom of the list on the left-hand terminal, and check the version number of that service in the right-hand terminal, then do this for every service running. To do this, you can either scroll to the service number and make note of it, or you can run dpkg -l | grep <service name> to get a quick output of the version of the service you are searching for. At this point, you can either jump straight to your favorite exploit searching method (Google, Exploit DB) and look for an exploit, or you can add it to a spreadsheet or note taking application for later analysis.
I know, this part takes a while, but the little details are what matter in privilege escalation. You need to enumerate all possible data to increase your chances of a successful privilege escalation.
In our example, let’s say we are going up the list and we are at the service called exim.
In the right hand terminal we have up, we search for exim by running dpkg -l | grep exim.
We see that the version number listed for exim is 4.72–6. With this knowledge, we decide to search for an exploit on our favorite search engine. I type in exim 4.72 site:exploit-db.com and see what results we get.
The second result looks promising. The title mentions this exploit is applicable to versions lower than 4.86.2, which is the case for our version of exim. We open up the link and see what we’re dealing with. Reading through the exploit, it looks exim is a message transfer agent, and when compiled with Perl support, can be exploited to gain root privileges on the machine. Below is how I would attempt to exploit this service:
The proof of concept exploit tells us to first check if
exim has been compiled with Perl support. We do this by running the following command:
user@debian:/root$ exim -bV -v | grep i Perl
The next step tells us to try to run this command:
PERL5OPT="-d/dev/null" /usr/sbin/sendmail.exim -ps victim@localhost
After running our new command, we get an error:
Hmmm… it seems like this exploit isn’t doing exactly what we want it to do. I look in the /usr/sbin directory and sendmail.exim isn’t there. Let’s put this exploit on the back burner and look for something else.
I try searching Google again for another exploit. It seems there are a lot of twitter posts about this exploit, so I decide to filter out those results, and search for exploits listed on Github.com.
I open up the first link and see what we’re working with. The proof of concept on Github shows us how to run the exploit:
I the commands exactly as listed and we get root on the machine!
What did we learn from the exploitation of this service? Sometimes it’s not going to work on the first exploit we find for one reason or another. Don’t give up when you fail on the first attempt. Keep searching. Privilege escalation is usually not easy, it takes time, patience, and an eagle eye. It can be tedious, but it can be extremely rewarding.