Hack This Site: Realistic Web Mission – Level 12

Hack This Site: Realistic Web Mission – Level 12

Welcome to HaXeZ where today we’re looking at Hack This Site Realistic 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. If you haven’t seen my other posts on the realistic series you can do so here: Part 1Part 2Part 3Part 4Part 5Part 6Part 7 and, Part 8.

Heartland School District
Heartland School District


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.

Message From OutThere
Message From OutThere

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.

Heartland School District Web Application
Heartland School District Web Application

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 - Contents of C Drive
Web Application – Contents of 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. However, there is no cgi-bin directory listed. Regardless, we have found an interesting page named ‘heartlandadminpanel.html‘.

Web Application Directory Listing
Web Application Directory Listing

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.

Web Application Admin Panel
Web Application Admin Panel

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.

Joey frigging Simons
Joey Simmons - Web Application
Joey Simmons – Web Application

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.

guest.pl Hidden Write Function
guest.pl Hidden Write Function

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.

Web Application - heartlandadminpanel.pl
Web Application – heartlandadminpanel.pl
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=/)
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.

Web Application - Removing Restrictions
Web Application – Removing Restrictions


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.