SQL Injection Lab // Exploiting Vulnerable Web Server with Kali Linux

---

After playing around in TryHackMe rooms for a few months, and inhaling content from John Hammond, Network Chuck, & David Bombal, I decided I wanted to try something a little more involved by setting up my own hacking lab to try and attack a vulnerable machine from Vulnhub.

Did a quick google search and found a really well-written blog post by Gavin Loughridge that walked through exploiting the NullByte box from Vulnhub with SQL Injection. I figured this would be a good place to start and downloaded the ova file.

Setting Up

The first daunting task I had to tackle was actually setting up the lab; getting both VMs into Virtual Box, putting them both on an internal network, and set up DHCP on the internal network to auto assign them IPs.

Loading both VMs into Virtual box was straight-forward, and going into each of them and putting them on an internal network was also simple. My first snag came with setting up DHCP, and if I’m completely honest it was probably the hardest part of this entire process.

I’ve used Virtual Box for quite a while, but I’ve never had to use VBoxManage to configure anything. I found the documentation really helpful as well as this article on how to enable DHCP in Virtual Box.

After some trial and error, I did eventually get everything set up correctly and can finally move on with the project. I started with a ping check to make sure my attack machine (Kali) can reach the vulnerable machine (NullByte).

Port Scanning

Started an nmap scan to check for open ports on the machine and output to a file so I could refer back to it later if needed. The scan shows ports 80, 111, & 777 open.

Since it is a tutorial about SQL Injection, port 80 is probably the one to investigate first, so I opened up a browser to check it out.

Hidden Paths

I’ll admit that I would be pretty lost at this point if it wasn’t for the tutorial and some extra googling. If you download the image on this page and run the strings command on it you are rewarded with a random string of characters that represents a hidden directory path on the website: ‘/kzMb5nVYJw’

The new page presents you with a prompt for a Key, and an incorrect entry will result in the text ‘invalid key’ displaying on the page.

If you open the developer’s console on this page you get a hint in the inspector:

Now I know that this input isn’t connected to the database and that the password isn’t complex. So I can try to brute force the password with Hydra. I just need a couple of things first.

Password Cracking

I switched over the the network tab to see the Request and Response from the server when a password is submitted.

The Request tab shows that the only data sent in the form is the variable KEY.

The Response tab shows that the page will display ‘invalid key’ when an incorrect KEY is submitted.

With all of that info we can now run hydra with the rockyou.txt password list to try and brute force our way past this page.

This line says there are no usernames and to use the rockyou.txt wordlist for possible passwords, I supply the IP, the form type, the directory path with the variable ‘key’ and the text ‘invalid key’ to denote an incorrect password and let hydra do its thing.

The password is found very quickly; ‘elite’

When I type the found password into the website I’m greeted with a new page:

SQLMap

With just some manual poking and prodding I noticed that just pressing Enter on the site brings up two entries:

Next I needed to try some basic SQL Injection to see if the server may be vulnerable. I started with the ‘ character, but it handled it just fine.

Next I tried ” and this caused it to throw an error in response.

Knowing it could be vulnerable, it’s time to rely on sqlmap with the url used after a search is made.

sqlmap confirms that the ‘usrtosearch’ variable is vulnerable to SQL Injection.

Now I can poke around and see what databases I have access to with the -dbs flag.

The most interesting database seems like it’s going to be ‘seth’ so I checked which tables were in the seth database.

There’s only one table named ‘users’ so I can see what columns are in this table.

The user and pass columns are what I want so I dump those out.

Now I have a username ‘ramses’ and a password that’s a hash.

Cracking Hashes

Not really sure what to do with hashes and the article I was following didn’t explain it to me in depth enough so I wanted to see what the process for cracking a hash once I discovered one. For this I turned to Google.

After reading through some very… difficult-to-read websites I finally was able to transform the 64 bit hash version to MD5 and then to the plain-text password; ‘omega’

With the initial nmap scan I do remember that there was ssh on port 777 so I opened up a terminal connected to the target machine over ssh with the username ‘ramses’ and password ‘omega’

… I’m in 🧑‍💻

Privilege Escalation

I don’t have a ton of experience or practice with privilege escalation so I just went with the article on this one to go through the motions and research the why’s as I go.

To start, I printed out the history of the user ramses with the cat command.

After messing around and trying some of the same commands ramses did, you find out that ramses is not a part of the sudoers group and can not access certain files and directories, like /root, and you also come across the ‘procwatch’ file which, when run, runs the ps command to show processes.

If I can link a different command to ps and re-run the procwatch file I may be able to perform commands that I normally wouldn’t have the proper permissions for.

I start with trying to link the ls command to the ps command.

I ran procwatch and…

… I get a list of the current directory. Success.

I change the link from ls to sh to launch a shell (which when launched is given the permissions of the file that launches it)

and the procwatch file just happens to have root permissions.

Now I can navigate to the /root folder that I wasn’t able to access before and can cat out the proof.txt file located there as the final flag. 🚩

Conclusion

I had a lot of fun with this lab, and I certainly learned a lot, most importantly I learned that I have a lot more learning to go.

The things I’m most excited about learning are how to set up an internal network isolated from the internet and other hosts on the network to play with vulnerable machines. I also learned a little bit about linking commands with others in Linux, and I’ll definitely want to research more of that in the future.