Lab 9.2 Exploiting Gloin - JimKnee-Champ/Ethical-Hacking-Journal GitHub Wiki
Target IP Address
The gloin server can be seen within vsphere, and the IP address is available to anyone with the ability to see it. Because in the real world, its unlikely to have access to a setup such as this where we have such information available on hand, we will attempt to divine that information in other ways. We can do an NSlookup command to find the ip address of gloin.shire.local, given that we know it is on the 10.0.5.0 network, with the dns server almost certainly being 10.0.5.22 from previous activities.
Open Ports
Next, we can determine what ports and services the target is running. An nmap version scan will reveal open ports to us. nmap -sV 10.0.5.31
This reveals that ports 22, 443, and 3389 are open with services OpenSSH, Apache HTTP/SSL, and Microsoft Terminal Services respectively. The OS is also guessed to be windows, which seems especially likely given the microsoft services running on the server.
using the -A option for NMAP provides more information about the services available on the server.
Discovered Vulnerability
No exploits could be found for that version of openSSH, with all of the ones on exploitDB referring to prior editions of the service.
Similarly, no exploits were found correlating to the apache httpd version (2.4.51) or the ms-wbt-webserver.
The ip address was then visited using a web browser.
Using SQL injection, it was possible to test various inputs to see how the server responded. The server passed an error after receiving "' or 1=1#" as input. Next, using the input "admin' or '1'='1" the server logged us into the John D Smith user account. This shows that the server does not use prepared statements and is vulnerable to SQL Injection.
This portion of the website did not seem to offer any vulnerabilities, but after researching the website and sql injection it turned out that the website and SQL content it contained was based off of a default or template SQL practice thing. Several guides and exploits pointed to the ability to use SQL injection again to acquire the contents of databases within the server, namely those containing the Admin's account information.
The url used to acquire the admins information is below:
This engages the "view_enrolee.php" document, which contains values relating to users account information. The injection supplies an SQL request that acquires multiple values from the table relating to the admin account. The command also uses UNION, which joins different columns of data together to become more readable. the "%27" is URL encoding, which translates to "'", or the apostrophe character, which is used to enable sql injection in many cases without prepared statements. One odd thing is that the username and password values dont appear to be located where the URL would seem to place them, instead being swapped, with "admin" corresponding to the password request and "email" (or the password hash in actuality) corresponding to the username request.
The value inside the email row is likely the hash of the admin's password, so we can use a tool like hashcat to crack it. An online tool analyzed the value and found it to be an md5 hash.
Due to the simplicity of the hash, and the lack of a corresponding salt to make it more difficult to decrypt, it was possible to use an online tool to decrypt the value, located at www.crackstation.net.
This reveals the password to be dr@g0nf0rce (dragonforce with the A replaced with @ and the O's replaced with 0)
The password works and allows us access to the administrator account on the server. Within the browser this doesnt allow us to do much, just interact with the basic content of the webserver, such as the user accounts and tests.
How you achieved a foothold/Root Compromise
Using ssh, it was possible to log in to the "administrator" account using the provided password. The account name was notably not admin, and so produced an error prior to the successful attempt. Once inside, this gives us the ability to navigate the windows file system with impunity.
User Flag
Root Flag
How might the vulnerabilities be mitigated by the systems administrator and developer?
The website could have prepared statements set up, so that its input fields and URLs cant be used for SQL injection attacks. Disabling ssh access would also prevent the exploit from providing access to anything other than the web servers content, meaning the machine the server is hosted on would largely be safe. The lack of secure passwords is also terrible. the required password length should be increased drastically, and the hash should have a salt to go along with it to make it harder to crack. Im not certain on this front, but if possible it should also be the case that the admin account for the web server's content should not share a password with a User account on the same machine.