At JCore, we follow a three year program to become senior developers. After following this program successfully, you will be promoted to the JDriven company. In the final year, we have a specialization in a topic of our choice. I chose to specialize myself further into security. I have been studying this topic for some time now, even contributing to the fast track courses as a security teacher. Until now, most of my time I spent on the defending side and now I want to take a look on "the other side". So my specialization is all about attack, also described as joining "The Red Team".
In the first half year of my specialization I’m stepping into the shoes of a hacker. I will try and penetrate boxes in the labs of HackTheBox to gain root access. The end-goal for me is to get the prestigious Offensive Security Certified Professional (OSCP) certificate.
In the upcoming period I will post a blog in a few separate posts describing my journey on How To Hack A Box, but first I wanted to share a learning moment that I had today.
One of the steps in getting root access on a box is getting a Reverse Shell.
A Reverse Shell is where your target machine creates a connection to your machine, after which you get a shell on the target machine in which you can execute system commands.
You can use the Netcat command
nc -lnvp 4444 to create a listening port on your local machine to receive a Reverse Shell from your target machine after it connects to you.
To trick your target machine to create a Reverse Shell, you can exploit a Remote Code Execution vulnerability.
So I was trying to get my way into an application which listens to a TCP port in the higher range of TCP, but didn’t know what application it was. After some Google-Fu, I found an exploit for AChat. Some modification had to be done in order to successfully execute it. Yay, I got a Reverse Shell!
To get all the juicy information about the system which I can use to gain root access, I used a script called LinEnum.sh. After downloading the script on the target machine, I executed the script.
It was taking too long, so I pressed
CTRL-C to close it because I thought it was stuck.
My Reverse Shell closed because in fact I was sending the
SIGINT signal to my own shell, instead of my Reverse Shell.
After trying to use the exploit again, I couldn’t get access to the machine anymore.
Apparently, the application was handling requests in a single thread and by exploiting the vulnerability, that single thread was now busy with my Reverse Shell which I closed.
However, the thread was still busy.
By doing this, I effectively DoS’ed (Denial of Service) the system…
Fortunately, you can simply press a button in HackTheBox to reset a machine. One annoying thing with this particular box in HackTheBox though, is that it doesn’t like to be reset. Because I couldn’t get it to reset, I stopped for the day, since it was already 20:00 anyways. Next day I finally got the box to reset, but it took me way too much precious time I could’ve otherwise spent on my specialization. So I thought, how can I prevent this from ever happening again?
Today I learned
The problem I encountered wasn’t the script took too long to run, nor that I was exploiting a single-threaded application.
Both should just be possible.
In fact, the problem was that I didn’t upgrade the Reverse Shell to an interactive one, where you can actually use
CTRL-C to close the process that you just started and have tab-completion.
If you have no TTY shell, first execute
python -c 'import pty; pty.spawn("/bin/bash")'(or any other from this list at GTFOBins)
CTRL-Zto background the shell
stty raw -echoto set the STTY to raw and input characters, don’t mind the strange magic that’s happening on your screen right now. You won’t see what you’re typing.
fgto foreground the shell again
entera few times until you see your shell again
That should be it!