Hack This Site: Realistic Web Mission – Level 12

Hack This Site: Realistic Web Mission – Level 12 : today we’re looking atHack This SiteRealistic Web Mission 12. This mission requires us to use the built-in functionality of a crudely implemented web application in order to exploit it. The application functionality is driven by a number of Perl scripts that when used in unintended ways have a detrimental impact on the security of the application.

Also read : Hack This Site: Realistic Web Mission – Level 11

Introduction

We’ve received a message from our client OutThere. He explains that their school has been overtaken by a cruel system administrator by the name of Jason Bardus. Furthermore, Jason has implemented a number of restrictions that prevent them from accessing anything on the web other than the school website. He also lets us know that the application is running on a Windows 95 machine and has asked us to free them from their internet prison.

Exploring The Web Application

If we navigate to the application we’re presented with a basic page with a URL input box. Notably, The page has three main links: Teacher Pages, Student Work, and Testing Scores. On the whole, visiting these pages doesn’t provide us with much that can exploit.

Web Browser Protocols

Web Browsers support a number of protocols. For example, when visiting a website, the HTTP or HTTPS protocol is prefixed to the start of the domain. In essence, HTTP and HTTPS are Hypertext Transfer Protocols and are responsible for getting the content you requested. In addition to HTTP and HTTPS, browsers support a number of other protocols such as FTP and the SMB File protocol.

File Exploring

As the Web Application is attempting to mimic Browser functionality by including a URL input box. Perhaps the input box supports other browser protocols too. Through trial and error, we can view the contents of the web server’s local disk. By utilizing the file protocol we can specify a directory that we want to browse. Depending on the permissions of the service running the web server, we may only be able to access certain directories. Unless it’s poorly implemented and gives us access to the entire C:/ drive.

Web Application Structure

The webservers local disk has a directory called WEB and within that directory is another directory called HTML. It is evident that this is the webroot of the application we’re trying to compromise. Notably, the Perl script for the browser functionality ‘internet.pl‘ is in the ‘cgi-bin‘ directory. Regardless, we have found an interesting page named ‘heartlandadminpanel.html‘.

Picking Apart Perl

With this in mind, If we browse to the ‘heartlandadminpanel.html‘ page we are presented with a login form. If we inspect the login form we can see that it is calling another Perl script named'heartlandadminpanel.pl'. The username and password for the admin panel could be hardcoded into the Perl script but we don’t have a way for reading it.

Also read : Hack This Site: Realistic Web Mission – Level 6

Student Web Application

Revisiting the student web applications we find some standard teen cringe from Snezana Antic and Nolan Ethix. We get some wholesome content from Sarah Mathis but Joey frigging Simons is the hero we’ve been looking for. This kid has potential and hopefully, we can turn him to the dark side by using his application for our nefarious purposes. His application appears fairly basic like the rest of the Students but he has a guestbook. I like to believe that Joey Simmons looks like that computer kid meme. You know the one.

Exploiting The Guest Book

The guest book appears fairly basic. It has an input form that allows visitors to submit messages. However, if we inspect the input form we can see it’s calling a Perl script named ‘guest.pl‘. Furthermore, the form has a hidden value called write which is what allows it to write to the guest book. Perhaps, the script also has a read function that we use to our advantage.

So, we know the location of the Perl scripts is in the ‘cgi-bin‘ directory. We also know that there is a Perl script named ‘guest.pl‘ which could allow us to ‘read‘ the contents of another script called ‘heartlandadminpanel.pl‘. If we call the ‘guest.pl‘ script with the read function and point it to ‘heartlandadminpanel.pl‘ we might be able to find the credentials of the admin panel.

http://www.hackthissite.org/missions/realistic/12/cgi-bin/guest.pl?action=read&file=heartlandadminpanel.pl

#!perl
use strict;
print "Content-type: text/html\r\n\r\n";
require "db.cgi";
my $line;
if ($ENV{QUERY_STRING} =~ /^username=jbardus&password=heartlandnetworkadministrator&blocked=/)
{
 clearlist();
}
elsif ($ENV{QUERY_STRING} =~ /^username=jbardus&password=heartlandnetworkadministrator/)
{
 print "

Admin Access Granted

To explain, we have used the'guest.pl'script to read the ‘heartlandadminpanel.pl‘ script. When the page with the script loads, we can view the page source and capture the login credentials for the'heartlandadminpanel.html‘ page. Now, if we head back to the'heartlandadminpanel.html‘ page and use the credentials we just recovered, we should be able to log in. Upon logging in, we’re presented with a page that shows the blacklist. All we need to do is click the clear all button to remove the list and we should complete the mission.

Conclusions

This was a fun challenge that taught me a bit about Perl scripts and how speculating on functionality can lead to unexpected behaviors. It demonstrates that security compromises can occur as the result of using software in ways that it wasn’t intended. We didn’t brute force anything or trick a user into sending us credentials. We used the built-in functionality of the application to use the application in ways that weren’t intended. A great example of something that could be easily overlooked in a production environment.