Overview

The goal of this lab is to locate a series of information about the target:

1. Target IP Address
2. Open Ports
3. Discovered Vulnerability
4. How you achieved a foothold
5. How you achieved root/Administrative level compromise
6. User Flag
7. Root Flag
8. How might the vulnerabilities be mitigated by the systems administrator and developer?

Useful Commands and Instructions

Reconnaissance

I began with a nslookup of the target: gloin.shire.org

With this information, I then ran nmap against the IP to see what services were running:

Ports 22, 443, and 3389 were open, based off the nmap scan.

From here, my goal was to determine more about the target system. I now had the target IP address and open ports.

Since port 443 was running on the target system, I attempted to browse to the target at that port. I input "https://10.0.5.31:443" and was provided with the following window:

With this input window, my first though was to see if I could get anything using SQLi. Inputting a true statement (1' OR 1=1 --+) and a comment granted me access to a user account (John D Smith):

Since this worked, I was brash and attempted to see if I could find anything more useful. Sadly, there was indeed an "admin" directory in "index.php". I was prompted with a username and password field--I ended up inputting the same true statements from above for the John Smith user... it worked:

Since I had this access, it was time to do some more snooping around. I changed to the "Enrollees" tab to grab user names and enrollee codes:

From this page, I could find additional information about the administrator:

I also attempted to change the password, using 1' OR 1=1 --+ as the old password. Despite the SQLi approach allowing me to access the Administrator page, this didn't work, so I needed to consider alternative strategies.

Since I'd already accessed John Smith's account, I accessed Gloin's exam system using valid credentials. This didn't provide me with any additional information, but now I've been able to login as both enrollees and the one (admin) user. I may need to consider exploiting through another avenue if the Apache approach doesn't pan out.

I found a list of common directories to check for through a browser, and "db" was successful. I was able to download the exam database, and I'm going to try and leverage this information to collect information on account passwords. If I can grab plaintext or even hashes, I might be able to crack user accounts:

Here's the resource I used with some common directory names.

From this downloaded copy of the database, I now know what the table and column names are that could be valuable. The "admin_list" table has columns such as "admin_id", "username" and "password". If I can find a way to utilize my SQLi to output results, I might be able to use this.

In the "Browse Data" label, I found information on the web user (admin)--there was a 32 character hash in the "password" field:

Some quick research returned that there are a small number of common 32-bit hashes, and the most likely is MD5. Since we have a known username, and (assumed) MD5 hash, we should be able to crack the password.

Here's the output of my hashcat session (that was surprisingly short):

The command I used:

hashcat -m 0 -a 0 -o cracked.txt /home/champuser/week11/adminHash.txt /home/champuser/rockyou.txt

Bear in mind that I saved the hash from the database to the adminHash.txt file to then be referenced by hashcat. I have a copy of the rockyou wordlist saved on this device that I used for the wordlist input. The mode was set to 0 (MD5 algorithm), and I set the output file to cracked.txt.

With this cracked password, I'll attempt to login to 10.0.5.31 as admin using valid credentials. If this works, I could theoretically change the password.

Login as admin was successful using the valid credentials. I also tried reusing the password as SSH credentials, however, that wasn't successful.

The other service that was running on the target was port 3389 (RDP). I tried using the credentials I got from hashcat via Remmina (Linux remote desktop application) and they didn't work at first--since I realized this was a Windows box, I changed the username from "admin" to "Administrator". This was successful, and I found the root and user flags in the file explorer:

Issues and Troubleshooting

I faced a few bumps in the road during this lab, but after some patience and troubleshooting/research I found most of the resources I needed to be successful. There were multiple instances of trial and error, referencing content from previous labs (and classes) and a few instances where I needed to confirm I was heading in the right direction. I outlined most of my thought process in the useful commands and instructions above.

Questions/Reflections

How might the vulnerabilities be mitigated by the systems administrator and developer?

The first things the systems administrators should consider changing are the viewing permissions–I was able to navigate to the admin and db directories, and from the db directory I was able to download a copy of the db that contained a password hash for the admin (quickly cracked since it was the MD5 algorithm). Another key consideration is the password input boxes–I was able to utilize SQL injection to trick the system into letting me login without valid credentials (both as an enrollee directly from the homepage AND the admin account, once I’d found the admin directory. I highly recommend that you redevelop the backend to mitigate the risk of SQL injection through means such as “1’ OR 1=1 --+”. I was also able to move laterally from the web page to the box directly via RDP. This would be more difficult if you disabled the “Administrator” account and used a different user account.

Overview:

• Go beyond hiding directories and change the viewer permissions
• Consider stronger encryption (MD5 is no longer sufficient)
• Strengthen your backend to mitigate SQL injection attacks that allow login without a username or password
• Change user accounts to less obvious names (instead of admin and Administrator, consider a codename)
• If RDP isn’t necessary, disable the protocol