Hacking and Gaining Unauthorized access through Running Processes and Path Misconfigurations:

Arnav Tripathy
7 min readMay 5, 2020

Some time ago , this used to be my most dreaded topic to deal with in privilege escalation, but after preparing for my OSCP and after quite a lot of CTFs, it has become my favourite and proabably one of the most interesting ways to escalate privileges. What makes it more interesting is that it is dangerously realastic as well . Over the few months while talking to a few CTF’ers , I have come to realise that many people find it hard to spot and how to escalate it. Even those who do successfully escalate, they do not fully understand the mechanism. This blog aims to clear those gaps with three real examples I have faced in three machines . Two of them will be successful exploitations and one will be a rabbit hole which can save you lots of time. While all three machines will be linux machines ,through research and observation the concept is pretty much similar to any operating system because processes and paths work exactly the same way in any system . I’ll be explaining certain things through the examples so let’s get started.
Note:- I have not exactly discovered anything new here. I am simply trying to explain what I’ve learnt in the few months through my own research and understanding. I want to post this because I myself was searching for a blog similar to this many months ago and hope it helps others.

First example : -Hack the Box Writeup

Hack The Box Writeup

Writeup is a retired machine, back in the day it was my second active machine I had rooted . While there is a publicly available writeup for rooting it , after reading a few blogs , I realised that I had rooted it in a slightly different way . Note though its not like completely different, but I thought it might interest you that there was another way to root it besides the “run-parts” method. For saving time , I’ll skip to the part where I have shell access to the machine . If you want to know more about the exploitation , check out this blog by a friend of mine.

https://theblocksec.com/2019/10/12/hack-the-box-writeup-box-walkthrough/

Lets ssh into the machine with the creds found and upload pspy , a process monitoring tool.

Now lets run pspy tool . A clue was given to try and ssh into the machine to enumerate processes . Let us do that.

Let us focus on the processes having PID 2179 and 2181 for now.
Process PID 2179 is setting the path variable for running crons. Meaning if any binary is executed, it will be searched in that order of path. We can’t overwrite the path environment variable here meaning we can’t add our own path here. Let us try to enumerate the paths one by one. We discover that /usr/local/sbin is writable by us as meaning we can put our malicious binary in it.

Excellent, now let is inspect PID 2181 . So it seems to run a script in a particular path. Let us check out that script.

So the script is trying to run the uname command . Basically its trying to run the uname command here . So we get the idea to put a malicious binary by the same name “uname” in the writable path /usr/local/sbin . Then the cron will execute our “uname” because our path is at the top priority meaning it will be searched first for the binary. Let us do that.

This is just a little technique I picked up during my OSCP preparation. Here the bash binary is copied and made a suid binary so that when we execute it, we will execute it under root permissions. I’ve found this much better than a reverse shell because it is much easier to execute and its persistent.
Now we ssh into the box from a different tab and find our “rootbash” in the /tmp folder. We come root here therefore.

The original method involved overwriting the “run-parts” binary of the cron. If you compare , both are extremely similar. The lesson learnt is to not only check the binaries execute in the pspy , but also the scripts executed too. You never know they can be useful too.

Second Example :- Vulnhub Typo 1 Machine

Vulnhub

In this machine, we don’t hijack a running cron, rather we monitor the process occuring in the background when we execute the binary and overwrite the path variable. This time though a different path variable will be targeted as you’ll see. Let us as usual skip to accessing the box. I have posted a complete writeup for this machine , below is the link:

So let us start enumerating suid binaries, we find a binary standing out by the name “apache2-restart”

We had never heard of this binary before . We can assume that this might be a script which executes shell commands. So let us try to find out what exactly happens once you execute it through pspy64.
Open a new session and execute the binary. Don’t forget to run pspy64 in your current session and monitor any new changes.

So we were correct, it does execute shell commands, it executes two command using binaries service and systemctl under root privileges. So here we have the option to exploit either of the binaries as we can see absolute path is not given.
Wait a minute, what did you just say? What’s absolute path?
So here’s the deal, whenever a command is executed , the binary is searched in a fixed path. Take a look at the screenshot below:

We have made a malicious binary by the name service . We tried looking at the path variable in the system and we see all the paths in accordance of path.
By now, if you’ve understood a little bit of what I am trying to achieve, you should get an idea on how to exploit this. Yes , youv’e guessed it right , we can check if any of the directory is writable and upload our binary in it. So we enumerated it, this time , we were not so lucky .
So what can we do here? Now we can add our own custom path and set the priority highest . That way “service” will be searched in our given path first which will execute the binary. We did exactly that and got root!

I think some of you might be confused and you are desperately trying to make sense of what happened here and the difference between the two. Now for this , the third example will clear it up.

Third Example:- Hack The Box Traceback(active)

Hack The Box Traceback

As of writing , traceback is an active machine in htb and I obviously can’t post solutions. But I will show how some lack of basic understanding can lead to rabbit hole.
You know the drill: upload pspy64 and check running processes . You might find something like this:

We see the sleep command being run in the background. We try the method in typo and try to export path and create our malicious binary. Try it. But it won’t work , why?
Here’s the thing, in typo we manually ran a binary whereas this is a cron (or scheduled task in windows) . The difference is that in a cron ,the paths are different. To find out the path of a cron in linux , we can see it in the /etc/crontab file as shown below:

The “PATH=” section contains the paths used by crons. This is the default for every cron. If we were able to write in any of the above mentioned paths , then we would be able to exploit the “sleep” binary. So the next time you come across something similar, be sure to cross-check it.
I hope it helps people confused about crons and paths. That’s all for now. have a great day:)

--

--

Arnav Tripathy

Feline powered security engineer . Follow me for a wide variety of topics in the field of cyber security and dev(sec)ops. Travelling and Tennis❤️🎾🐈‍⬛.