I gave some thought into how I wanted to approach these next few weeks after finishing the Hands on Introduction to Hacking book. My main toss up ended up being between attempting beginner boxes and gaining some practical experience or reading another book for more theoretical knowledge. Ultimately, I decided to just give some boxes a try to see how much I’ve learned so far and how much more I still need to learn.
With that said, I managed to root the Kioptrix series of boxes this week. These 4 boxes are designed for the beginner whilst maintaining a sense of realism, and can be found on Vulnhub here:
Before I start this blog post though, I want to stress that these are not intended to be in depth walkthroughs of each box. This post is mainly a recount of my learning, with key learning points highlighted as notes. For anyone reading this, I apologize if this isn’t the most useful post but I do hope you find my commentary interesting.
I figured I would start with an nmap ping scan, to see what IP addresses are on my home network. This was done so that I could identify the IP address of the target Kioptrix machine, and a ping scan is a quick and easy way to do this.
Looking through the list of IP addresses, it was pretty obvious that the IP address I was looking for was 192.168.1.104. I used a process of elimination based purely on the descriptions, and that this particular IP address had VMWare listed after the MAC address.
Note: I’m still not sure that this is the correct way to identify IP addresses, but it worked in this particular instance and hasn’t let me down so far.
I used nmap again on the IP address itself, using –sV and –O to identify what sevice versions and OS the machine is running.
After looking at the output, I then used enum4linux to find more information about the Samba smbd, and found out it was using version 2.2.8
At this point I needed to find a relevant exploit. Although I could have used the searchsploit command within Kali Linux, I was more comfortable searching the Exploit Database manually and evaluating the results on a more…graphical interface.
Note: It was hard to determine what exploit would be the best to use here, and I’ll admit that I referred to a walkthrough at this stage. All the exploits seemed similar and I was a bit nervous to simply try something out, something I’ll need to work on in future exercises for sure.
After downloading the exploit with wget, renaming it with mv, compiling it with gcc and executing it with ./a.out the bruteforce exploit worked!
Typing whoami satisfyingly returned root, and even better when cat /var/mail/root returned the flag for this box! A fairly straightforward box to start off with.
Note: I didn’t know about this cat /var/mail/root command, if not for the aforementioned walkthrough. I now know that it is the place where messages are stored if sendmail is installed, and is a common flag location on linux machines.
I ran the same nmap scan after determining the target IP address as I did on Kioptrix 1. This time I had more issues finding any relevant vulnerabilities, so I tried browsing to 192.168.1.147 directly after seeing Apache was running on ports 80 and 443.
Perhaps unsurprisingly, this login page was vulnerable to SQL injection attacks. Using ‘ ‘ OR ‘1=1’ as the password for admin got me to the Basic Administrative Web Console page, where I was able to run a remote code execution attack. An example of this is the basic whoami command I ran after the IP address to ping, which in turn returned apache. Using google, I found a way to attach a payload and after submitting it in a similar fashion along with a netcat open on my kali linux machine I was dropped into a bash shell.
Note: I googled a little too specifically here, and ended up finding the exact code string required in another bloggers walkthrough. Nevertheless I was still on the right track, and probably ended up saving myself some time.
I had a little dig around, and found index.php contained a username john and password hiroshima for the MySQL web app. Seems promising.
Unfortunately, this didn’t work. Damn.
Note: I spent more time than I should have here, thinking I was onto something. Lesson learned for next time: don’t tunnel too hard on rabbit holes.
Going back to enumeration, using shell privileges I was able to obtain more information about the operating system. Interestingly, this was one of the commands I used at the TrendMicro CTF workshop I attended a few weeks ago.
Finding another exploit on exploit-db that seemed promising, I tried to use wget again, but received an SSL error even after using –no-check-certificate. Double damn.
Note: At this point, I’ll admit that I was completely stuck. I had no idea why I was getting the SSL error and spent a significant amount of time trying to resolve it to use wget from within the bash shell session. Finally, I turned to walkthroughs and found users had started their own Apache service on the host machine, then used wget from the target machine to transfer the file across the network. Clever, and something I would never have been able to do on my own. However, I managed to replicate this workaround and obtained another root!
Following the same process, I discovered that there were 2 ports open on this machine, SSH and HTTP. Similar to the last box, I decided to open the web application first.
Note: In my head I was already starting to map out how this machine would be solved. I would first connect to the web application and obtain user credential information to connect via SSH. This would be done either as root directly or with privilege escalation to obtain root afterward. It’s hard to say if this process of “mind mapping” is useful, or if it can quickly lead to tunnel vision if/when it doesn’t work as intended. Although it proved to be correct this time around, I think it would be more beneficial to keep an open mind at the start of each machine and slowly work toward any leads I may find.
I spent quite a lot of time just snooping around on what the web application contained. I was able to find that the site is powered by something called LotusCMS, contains a suspected username loneferret along with a gallery containing photos that could be filtered on a range of parameters.
I started with a brute force attempt on the username loneferret, but quickly gave up after waiting for about 10 minutes.
Note: This honestly would have worked had I been patient enough. The password “starwars” was contained in the wordlist I was using, but I decided that other methods would be faster and present better learning opportunities.
I noticed that the URL had signs that SQL injection might work, replacing id=1 with id=’ sure enough returned an error confirming this. I then ran SQLMap on the site to see what it could find, and this time I was successful in obtaining the password!
Note: I could have tried to do this manually, but honestly didn’t know how. My SQL is still not that great. Thankfully, the SQLMap tool is easy to use and very effective.
Browsing around after making the SSH connection, I opened CompanyPolicy.README and found the instructions to use the sudo ht command. Seemed like it was worth a try so I decided to give it a shot.
This opened the sudo file in the HT editor. Navigating to /etc/sudoers I was able to see and edit the User privilege specification. Changing the privileges of user loneferret to be the same as root is an example of privilege escalation, effectively making loneferret a root user.
Note: So I didn’t really know what to do here, and spent some time learning about ht editor and the sudo file in general. Eventually, I decided to turn to a walkthrough as I didn’t want to risk breaking the machine and having to start over from scratch. It seems like this may be a fairly common method of privilege escalation though, so it is worthwhile understanding how to do these and gaining the experience and confidence to do so.
Now that loneferret has root privileges, I could access the root directory and open Congrats.txt for the third flag!
I ran the usual enumeration tools and found this machine had another web application, so I also went and ran another nmap scan to enumerate user information. This returned a number of users and would be useful when exploiting the web application itself.
Note: This script to enumerate user information is going to become part of my enumeration toolkit whenever the initial scan determines a web application is running. It is very useful and didn’t require any extra time to run.
I tried logging in as John, given that I already knew that would be a valid username. Entering ‘ OR 1=1 # as the password was enough to login, and the users credentials were displayed.
Note: Personally I found this to be a little easy, given that the SQL injection required for the last machine was more complicated than this one. In saying that, I did have a bit of trouble getting the correct ‘ OR 1=1 # syntax to work.
logging into SSH using the aforementiond credentials dropped us into a limited shell. This could be escaped using echo os.system(“/bin/bash”)
Note: Found out about this echo command via google, although I think it was a deliberate move on the creators part to leave the echo command executable in the limited shell to begin with, considering it was such an easy command to find.
I searched for the processes running and found that MySQL was running as root. Navigating to /var/www and opening the checklogin php file I found that there was no password to access MySQL, when using the username root.
Note: I spent a long time sifting through the various processes, and had to google the location of mysql on the linux machine. My lack of Linux knowledge started to show here, and I was a little overwhelmed with the amount of processes running on the machine.
There is a blog post that can be found here that details how to escalate privileges by exploiting a mySQL service with root privileges. Luckily, the required lib_mysqludf_sys.so file already existed on the system, so following the instructions here was relatively easy. Again, I think this was by design and the creator of the machine put this in on purpose.
After gaining root privileges on the user John, I was able to search the root directory, open the Congrats.txt file and obtain the flag!
Note: although I followed the guide on this particular privilege escalation exploit, I honestly didn’t really know what I was doing. I managed to make it work but couldn’t really explain why or how it worked. I might need to do some more learning around mySQL, as it appeared a number of times throughout these Kioptrix machines.
Overall I am very happy I decided to attack these beginner machines. They were a good learning experience, and I understand the entire penetration testing process better now, gaining some specific commands and processes to use in the future along the way. It’s clear that I’m still not quite there, as on multiple occasions I had to make use of walkthroughs or extensive google searches but I was able to get complete these machines the end which I am very happy about.
Ultimately, I feel that completing these exercises gave me a bit of much needed confidence. Learning penetration testing has been extremely daunting at times, and knowing now that I have at least some level of workable ability gives me hope that I can improve moving forward. Progress has been slow, but steady and I am excited to learn more.
One thought on “OSCP Prep: Episode 12 – Kioptrix 1-4 Vulnerable Machines”