All about web server hacking…

Today was an interesting day to learn.  I came across a tutorial which described itself as taking over a linux box.  Low and behold, it turned out to be a web server hosted on an Ubuntu box.  

My go-to web server box is usually a CentOS flavor of Linux.  This is because when I created my very first web server on linux many years ago, i did it on a Fedora Core 3 version of Linux.  Since then, I’ve been fond of a Red Hat environment without the cost of a Red Hat enterprise subscription.  In 99% of the cases where I make a server, I don’t need a graphical user interface (GUI) either, so I shied away from Red Hat proper early, and went to minimal installs of CentOS.  I use Ubuntu when I need a GUI, and therefore recognized that www-data as the user and group meant that it was likely Ubuntu.

So, with all that, I recognized the structure of the server pretty much right away.  There was a guide on how to do all of the hacking, but that tends to be no fun.  I only reference that stuff if I’ve been on a certain problem for way too long, and want to press on.  In the case of this server, I just visited the web site to see what was going on.

The site itself was very plain.  my nmap results showed that it was using a different port than normal, and a directory scan showed that there was an uploads section.  Whenever an upload section is found, it can usually be used as an attack vector.  In this case, I was able to upload a web file with a php reverse shell, and request it in my browser.  Using netcat to wait for a connection, i saw the server react to the uploaded file and grant me a connection right away.

The connection had privileges for only the www-data user, which is the web server.  This makes sense because i was granted access through an upload exectued by the web service.  So with this connection, it was time to look around.

The exporing lead to listed users (/home/user), and some other things, but nothing that was noteworthy.  Instead of snooping around  with the ‘ls -alh’ command everywhere, i took an easier approach.  I simply used the find command to figure out which files on the system were executable.  In the find command, we can search with the SUID bit set for permission of 4000.  When a file called /bin/systemctl showed up as user executable, it was fairly obvious that the box could be pwnd using a service.  that systemctl is what starts and stops services, so now a new bogus service with malicious code can be created and started.  In theory, if we set up another listener through netcat, the service would execute as root, and give me a shell with root privileges.

As www-data user, i could write a new file to the web folders.  So it was time to do just that, and build the services file.  Here’s the funny part, though.  I didn’t have access to vi, or vim, or nano, so it was going to be difficult to just copy and paste from a website.  As a result, I ended up doing an echo command with >> to ammend the file each time I send the echo command.  If I messed up any of those commands, I would need to wipe the file and start over.  Luckily, I was able to do it correctly on the first try.  When it was done, I checked the privileges, and pressed on to the privilege escalation to root.

It was only one easy command… systemctl enable test.service.  After that, I just started the service and waited at my kali terminal for netcat to pick up the connection.  When it did, i had root privileges and the box was pwnd.

Pretty sweet!