Capture the flag: A walkthrough of SunCSR’s Geisha

Introduction

Welcome to my write-up for the Geisha machine from VulnHub. This is a beginner- to 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 rooting and writing!

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. In this case, it mentions that this machine was tested with VMware Workstation, and this time I took the author’s advice and ran 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, and we just need to ensure it also has a network interface connected to the host-only network.

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

Scanning

I like to start off with an nmap ping scan to find the vulnerable host. If that doesn’t work, I’ll try netdiscover. It’s easy to identify our target as its IP address is the only one found besides my attacker’s (seems VMware’s host-only network doesn’t work the same as VirtualBox’s, where I also see my host machine and the virtual network’s DHCP server addresses). This machine is located at 192.168.237.128, and with that information, we can scan for some open ports.

Here I have only shown a port scan without OS detection or having scripts run, but that is so the screenshot is not too long. After ports 21 and 22, the others are all web servers. Since I don’t love webapp testing, I was hoping to find exploits for FTP or SSH but that was fruitless. Looks like we have five web services to look into. Yay.

Let’s make this as painless as possible by scripting away some of the work. Whenever I am attacking a web server, I have a few favorite tools I like to run, like gobuster and nikto. Since we have five web services to check, we can write a for loop in our terminal to run a command for each service, like so:

• for PORT in {80,7080,7125,8088,9198}; do gobuster dir -x .txt,.html,.php -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -u http://192.168.237.128:$PORT -o $PORT.txt; done

Let’s break this down. This for loop runs gobuster against each port we specify, scanning for names of files based on the configured wordlist to determine if they exist on the web server. The “for PORT in {80,7080,7125,8088,9198};” section declares a variable called PORT that on the first run of the loop will hold the first value in the list of numbers (80 in this example). Anywhere we reference the variable with $PORT in the rest of the loop, the current value of the variable will be substituted in. This results in us running gobuster against port 80 of the machine and saving the output to a file called “80.txt”. 

After the first run of the loop, $PORT will contain the next number in the loop (7080) and run our commands with that value filled in where necessary. This will continue until every port in our list has been used, and this saves us time over having to re-issue the commands with each different port ourselves.

We can then check the output on the screen or in the output files we created. Our scans have revealed an interesting file called “passwd” under the root directory of the web server on port 7125. After downloading, it turns out to be a copy of an /etc/passwd file (presumably the one for this machine).

It shows there is a user called “geisha,” which we can try brute-forcing the login for.

Exploitation

I will attempt to get geisha’s account password using hydra against the machine’s SSH service.

We’ve discovered the password “letmein” for the geisha user, and we can log in and look for ways to escalate our privileges. Running linpeas.sh shows us the SUID root files on the box, and we find the base32 command listed in the results. Searching GTFOBins for base32 shows we can use the binary to read files, and since it’s SUID root, we can read files as root. We can use this to read the /root/flag.txt file directly or the /root/.ssh/id_rsa file, which we can use to get a root shell on the box!

While not shown above, you can copy this file to your attacker machine, grant only read and write permissions to the owner (chmod 600 id_rsa) and log in with ssh -i id_rsa root@192.168.237.128. 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!

Lessons learned

As previously mentioned, I don’t usually enjoy webapp challenges. I find them tedious, and so I spent extra time searching for exploits and ways to get in that weren’t based on the web services. I now know to set up these scans to run in the background while I do manual testing and research. I will be working more on automation and scripting to improve my methodology.

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

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!