Capture the flag: A walkthrough of SunCSR’s Katana

Introduction

Welcome to my write-up for the Katana machine from VulnHub. This is an intermediate-level, intentionally vulnerable virtual machine created for the purposes of testing and strengthening one’s abilities. I hope you enjoy reading this as much as I enjoyed writing it!

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Setup

The download page is here. Always read the description to see if there’s anything the author shared that they think is important. It mentions that this machine was tested with VMware Workstation, so we’ll run it in VMware. DHCP is also enabled, so we will need to discover the host’s address after it boots.

We download the .zip file and import the .vmx into VMware as usual. I then like to go in and ensure the network setting is set to a “host-only” network so that it is not exposed to anyone except my attacking machine. My attacking machine is also in VMware, so we just need to ensure it also has a network interface connected to the host-only network.

With that out of the way, we’re ready to start scanning this machine!

Scanning

I like to start off with an nmap ping scan to find the vulnerable host. (I finally figured out why netdiscover doesn’t work for me. It’s because of the way it interacts with the virtual host-only network! If I left it as bridged, it would likely work.) It’s easy to identify our target in the output of the scan, as its IP address is the only one found besides my attacker’s. VMware’s host-only network doesn’t work the same as VirtualBox’s, where you also see your host machine and the virtual network’s DHCP server addresses.

This machine is located at 172.16.0.130, and with that information, we can scan for some open ports.

Lots to look at here, and of course, this is the abbreviated scan result. With the -A option passed to nmap we learn more, including a guess at the operating system and details on the services running. All guesses of the services listed in the above screenshot are correct except for the three highest ports, all of which are running web services.

I always run nikto and gobuster on ports with web services, and while the former doesn’t find anything interesting, we have found some interesting pages using the latter.

Port 80 has a site that allows you to purchase ebooks, and gobuster finds the “/admin.php” page, among others. I’ll save you the effort and let you know that the ebook website seems to have been a rabbit hole: admin/admin creds let us log into the admin page, then I found an SQLi vulnerability on the “admin_edit.php” page, but it didn’t reveal any useful information and I couldn’t get an OS shell either.

Gobuster found a page called “upload.html” on port 8088 and so we must see if we can upload a reverse shell page and access it. I’m never able to remember the location of my go-to php reverse shell file, so we can run locate php-reverse-shell and find that on my machine it’s located at /usr/share/webshells/php/php-reverse-shell.php.

We’ll copy that file to our working directory so that we don’t edit over our good copy, as we need to set our IP address and listening port in the file before uploading it. We then simply browse for the file and hit “Submit Query” on the page, and we’ll get the result of the upload in the blue screen below.

See the section labeled “Moved:” which tells us what the file was renamed to. Also note the warning “Please wait for 1 minute!. Please relax!”. Before we try to access the file, we must set up our netcat listener to catch the reverse shell.

Attempting to browse to “172.16.0.130/katana_php-reverse-shell.php” fails, but we remember we have multiple web services running on this box, so we will need to check all of them. We find it accessible on port 8715. Navigating to this page lets us receive a shell on our netcat listener!

Exploitation

In the screenshot, you can see we have received our reverse shell as the “www-data” user. The first thing I’ve done here is to run python3 -c ‘import pty;pty.spawn(“/bin/bash”)’, which has python spawn a more-stable tty shell. I then background the shell, run stty raw -echo followed by the fg command (which isn’t shown to the screen) and hit Enter twice. This allows us to get tab-completion and cycling of previous commands with the up and down arrows in our reverse shell (why settle for less?).

Reading “list.txt” here crashes our shell but the “.ssh_passwd” file is more helpful. We can try SSH’ing to this computer with the credentials, but they are not accepted (perhaps this user has not been configured for SSH access). We can, however, switch our user with su - katana in our reverse shell, and the credentials are accepted here.

We now can start looking for ways to escalate our privileges. I manually checked a few easy things (sudo permissions, misconfigured permissions on /root directory) but I ended up running linpeas.sh, as is tradition.

I prefer to redirect the results to a file so I don’t miss anything, and I also prefer to view the results on my own machine. Without a proper shell, it can be difficult to properly read paged output, such as with reading files with the less -r command, which is necessary for viewing the output in color.

Under the “Capabilities” section in the output from linpeas.sh, we see that python2.7 has the “cap_setuid” capability set. This is a kind of “privilege” that can be granted to allow programs to manipulate the UID of their own running process. In other words, we can run /usr/bin/python2.7 and instruct it to set its process UID to 0 (root).

The command got clipped because I was too lazy to set the stty columns properly, but the command was python2.7 -c 'import os;os.setuid(0);os.system("/bin/bash")'. This can be used to get a root shell on the box!

I’ve shown the length of the flag.txt file instead of reading it so as to not spoil all of the fun for you, so go ahead and try this machine out for yourself!

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Lessons learned

I got caught in the rabbit hole on port 80. I should have moved on to the “upload.html” page earlier when I kept getting stuck. Additionally, upload functionality can be very lucrative and could have been prioritized. Sometimes you have to decide between going wide (checking a little bit into many of the surface-level issues) versus going deep (exploring one issue to the fullest).

Did you attempt this machine as well? Did this guide help you if you got stuck? Let me know in the comments — I’d love to hear about it!