Hello world, welcome to haxez where today we’re looking at the last realistic 16 web application mission from Hack This Site. This mission was difficult for all the wrong reasons. It wasn’t because it was designed in a challenging way. No, it was because it uses Adobe Flash which has been dead for a while now. The challenge itself was a lot of fun despite the technical problems encountered along the way. I don’t know why I’m complaining honestly, I learned an additional nugget of information along the way.

Realistic 16 Introduction

We receive a message from someone who neglected to leave their name. The message explains that they suspect that their girlfriend is cheating on them. Furthermore, they have noticed that their girlfriend is using simplemail.com a lot. They suggest that it could be the way his girlfriend is messaging her secret lover. We’ve been asked to hack in to simplemail and read his girlfriends emails. Not trying to be a warrior of virtue or anything but under normal circumstances this would be a pass from me.

Exploring The Realistic 16 Web Application

Upon navigating to the application we’re greeted with a lovely lime green decore that is reminiscent of the old KazaA downloading application. During the Degeneration X days of the internet, Limewire and KazaA were the go to downloading applications. Alas, The application has a number of options that allow you to register, login, search and perform other activities. I genuinely like the look and feel of this application.

Scouring The Source

First things first, lets view what’s under the hood of this beautifully decorated vintage application. It’s mostly just what you would expect. However, there are a few comments that jump out at me. As you can see from the screenshot below, there is a comment that mentions an admin login. Lets head over to the URL and see what’s occurring.

https://www.hackthissite.org/missions/realistic/16/index.php?module=admin_login

Deadend or Detour?

Well that’s not something you see everyday. The login page uses Adobe Flash which hasn’t been supported by browsers since *googles it* December 31’st 2020. Ok, it hasn’t been dead that long but it’s surprising how Adobe Flash already feels like a relic of the ancient internet.

As we know, most browsers don’t support Adobe Flash anymore. I tried to install an older version of Firefox first to get it working but didn’t have much luck. After a bit of googling, I stumbled upon the miracle that is Ruffle. I did try a number of other plugins first but none of them seemed to do the trick. Ruffle however, was amazing and did it’s job perfectly.

Web Browser Meet Ruffle

As Ruffle isn’t on any of the default plugin stores for the popular browsers yet, you need to download it and add it yourself manually. In order to do this in the Firefox web-browser you need to head to about:debugging in the URL. Then click This Firefox, and then select Load Temproary Add-ons and navigate to the file you downloaded. With that file loaded, we should now be able to access the URL.

Realistic 16 Intercepting Web Requests

Before you continue, make sure you have your favorite web application penetration testing tool (Burp Suite) open and configured to intercept traffic. Then populate the Username and Password forms with test data and click submit. Inspec the request as it comes in to Burp and you will notice it is sending a GET request to a config.txt file. This suggest to me that the login form is checking something inside the config.txt before attempting to authenticate us.

Registering For Web Mail

Now we know a little bit about how the admin login works, lets register our own account and see if there is anything interesting there. I registered the user of test with the password of test because who cares about username and password complexity requirements anyway. Upon logging in, I had a look around and noticed that we had the ability to edit our profile. If we view the page source of this application we notice that it links to an edit.php page. If we click the link for edit.php to view the source of that page we notice that our profile configuration is stored in the following location /users/username/config.txt

Registering A Diretory Traversal

We know that our profile is stored in config.txt and that the admin authentication script was checking a config.txt file in the root directory (a directory, or two? above us). Perhaps we can register a user with a directory traversal for the username so that when we edit our profile, we end up editing the admin config.txt. Well, that’s exactly what we need to do. Logout and head to the register page and register a user with the username ‘..‘. You will get an error message saying it was unable to create the email address, but you will get a conflicting messaging saying the registration was a success.

Admin Authenticiation

With our newly created user, we need to head back to the edit profile page. This time we’re going to use the edit profile to edit the config.txt file in the root directory. We need to input the following value in to the ‘auth_page=config.txt&authed=true&‘ which is going to allow us to authenticate.

Admin Access

Ok, now that we have done that. Logout and head back to the admin URL and login with the other account we created. I used username test and password test. We shouldn’t revive an error message this time. Instead we should be redirected to the admin panel. The admin panel has a number of options including one that lets us read users emails. However upon submitting our clients girlfriends email address, we get an error message saying that the feature has been disabled for user privacy.

F**king Flash!

If we view the page source again we can see that this “Check Email” functionality is being provided by another Flash .swf file.

This is the part where we need to switch to our Linux Virtual Machine. We need to run a wget on the file and then disassemble it to see what’s going on. Fire up your linux terminal and run the following wget command. However, if you run in to errors advising you that the HackThisSite SSL certificate has expired (like I did), then you will need to tell wget to skip SSL checks. I will let you google that one.

wget https://www.hackthissite.org/missions/realistic/16/check_email.swf

Realistic 16 Dissasembling Flash

Now we need to disassemble the Flash file, to do this I used the tool swfmill to convert it to an XML file. Once the Flash file is an XML file, we can look through it to find out why it isn’t letting us check users emails. Or better yet, we can find how it would check the users emails and we can use that instead. The command to convert the SWF to XML is as follows:

swfmill swf2xml check_email.swf test.xml

You can then grep the XML for PHP and and you should find the following reference in the file.

/check_email.php?auth=true&id=63a4bf12cd&email=

With some minor adjustments, we can append the link to the Hack This Site URL and solve the challenge.

https://www.hackthissite.org/missions/realistic/16/check_email.php?auth=true&id=63a4bf12cd&[email protected]

And that’s it, you have now completed the final realistic mission of the series, congratulations. On to the next set of missions.

Hello friend, welcome to haxez where today we’re looking at the Hack This Site insane difficulty realistic web mission 15. This mission has a lot of breadcrumbs that we need to follow in order to complete it. It’s much more complex than any other mission and I convinced the person who created just wanted to make people suffer.

First, it requires attacking an encrypted zip file with a known plain text attack. Second, you need to modify your requests to log in to the internal message system as an admin. Third, you need to exploit a PHP authentication script to gain access to a PHP shell. Fourth, you need to perform a buffer overflow on another authentication script to gain access to the patents page.

Realistic 15 Introduction

So, we’ve received a message from HTML that Seculas Ltd has developed a new laser-guided weapon. HTML has sought our elite hacking services to hack in and steal the patent for the new weapon. HTML also explains that their new developer in charge of the website is the type of person to leave the backdoor open.

Exploring The Realistic 15 Web Application

Upon navigating to the web application, we are greeted with a sleek website that advertises its tools of warmongering. There are a number of pages include products, questions, imprint, and jobs. The questions and jobs pages have forms that we can fill out and submit back to the server.

If we view the page source of the index page we immediately see what appears to be a username of 'webadmin‘ with a real name of Susy Slack. We should make note of this as it may come in handy later.

Figuring Out Forms

As mentioned previously, there is a questions page and a jobs page. Both of which have forms that can be filled out and sent back to the server. After filling out and sending off the “questions” form, nothing spectacular happens. However, after filling out the job application form, we notice a difference in the coding.

The .gif file that is being loaded to indicate that the form has been sent, is loading from a different location to the one on the “Questions” form. This gif appears to be loading from a directory called _backups_. The image below shows the page source of the application once the Jobs form has been completed and sent.

If we navigate to the backup directory we get a directory listing with zip file named backup. This is a perfect example of why having directory listing enabled is a bad idea. It provides the threat actor with a wealth of knowledge about the structure of the application. Furthermore, backups should not be saved on the same server being backed up. Nor should they be saved in a directory that’s public. In the event of a drive failure, that backup is completely useless. Also, having the backup archive public means any old Joe could download and view its contents.

Realistic 15 Web Application Backup

If we download and try to open the backup file, we are prompted to input a password. No!, a password-protected zip archive, my only weakness! Honestly, this did actually give me some issues initially. At first, I attempted to use zip2john to capture the password hash and crack it. It appeared to grab the hash but cracking it proved difficult.

The good thing (or bad depending on who you are) about password-protected zip archives, is that we can see the contents. Inside this particular zip, is a file called index.htm. If this is the index.htm of the main site we’re attacking then we have some known plain text. If we have encrypted files but know the contents of one of the files then we can perform a known-plaintext attack. It’s a bit like how Alan Turing and the Bletchley team deciphered the Enigma machine and beat the Nazis during World War 2. If you know a portion of the text of an encoded document. You can use that text to decode the rest of the encoded text.

Cracking The Backup

In order to crack the backup.zip, all we need to do is grab a copy of the index.htm page. Once we have that page, we can compress it using the same method used to compress the encrypted backup.zip. Then we can compare the two zip archives using ‘pkcrack‘ and decrypt the encrypted version. First, grab a copy of the index.htm page by navigating the home page and right-clicking, and choosing save as (make sure you save HTML only). Second, create a new zip archive using WinAce with the following parameters:

Archive type: Zip
Compression: Maximum
Encryption Method: 256-Bit AES Encryption

Third, compare the two archives and make sure that the compressed size of both the index.html files is the same. If the compression and encryption methods used are different from the ones on the encrypted archive, then it won’t work.

Fourth, master Linux, install pk-crack, and crack the zip archive. Ok, going through it step by step is a bit beyond the scope of this walkthrough. However, if you’ve made it to this mission then you should be able to git clone a repository. Follow the instructions on git to build it then run ‘pkcrack‘ to compare the two files. You should receive an unencrypted output zip file that contains the contents of the encrypted zip file.

sudo ./pkcrack -C /media/sf_OneDrive/backup.zip -c "misc (files from different folders)/index.htm" -P /media/sf_OneDrive/index.zip -p index.htm -d decrypted_file -a

Web Application Message System

With the output, we can now look through the files. If we open the PHP files in the internal_messages directory we can see that the ‘msgshow.php‘ file references an ‘internal_messages.php‘ file.

If we navigate to the ‘internal_messages.php‘ page, we can see that there is in fact an internal messages system that requires a password to access it.

This is where things get a bit confusing. If we view the page source of the index page again we can see the code below. The code appears to contain a username of webadmin and a password of ‘Susy Slack,‘. However, this “exploit” requires us to use the user ‘admin' with the same password. Perhaps the developer was intentionally demonstrating password reuse.

<meta name="KeyWords"     content="laser,war,smart bombs,night vision aid">
<meta name="Author"       content="webadmin: Susy Slack,
                                   email [email protected]">

Anyway, if we look at the msgauth.php file we can see that it appears to be an authentication script. It is storing the user-submitted credentials into variables. The username is being stored in a variable named ‘$msg_username‘ and the password is being stored in ‘$msg_password‘. Further down the code, we can see that it is performing the following if statement to check the username and password. The format appears to be the same as the username and password we found in the index page.

if (ereg($msg_username . ": " . $msg_password . "\r*\n*$", $strLine, $regs))

Exploiting The Message System

Things get even more confusing. We can’t just submit the password to the form seen in the picture above. We have to intercept a request and modify it to post to a different PHP page with different parameters. Surely, if we are viewing the backup files of the site then we should just be able to submit the password to the internal messages system. It should be using the same PHP files with the same parameters. I have no idea how the first person to solve this mission did so.

If we capture a request to msgshow.php we can modify the following parameters to gain access to the messages. First, we need to change the POST request so that it posts to ‘msgauth.php‘ rather than ‘msgshow.php‘. Second, we need to change the password parameter to ‘msg_password‘ and the username parameter to 'msg_username‘. Third, we need to populate those parameters with ‘admin‘ for the username and ‘Susy%20Slack,' for the password. Finally, we need to add another parameter of filename and set it to ‘../../index.php‘.

Now if you send the request, you should see the message ‘set admin OK‘. I have no idea why this works or more importantly, why submitting the correct password to the ‘internal messages’ form doesn’t. Furthermore, why is the user listed as ‘webadmin‘ on the index page, but admin on the internal messages page. I admit that I’m not great at coding and perhaps it has been designed this way in order to make it challenging. However, to me, this doesn’t make much sense. Anyway, we can see the message that we’re intended to see in the image below.

Exploiting PHP Authentication

After all that work, we only receive a new directory to go visit. We could have found this directory using directory brute force tools like DIRB and Go-Buster. I’m not sure what I was expecting. Heading to the ‘admin_area‘ directory produces a forbidden message. With nowhere else to go, we need to head back to the backup file that we downloaded and decrypted. There is one file in there that we haven’t looked at, shell.php. If we head to ‘admin_area/shell.php‘ we get a login prompt. The previous credentials don’t work so let’s look at the code. The first thing to notice is that it tells us what the username is. The value of root is being passed to the ‘$shellUser_root‘ variable. Unfortunately, it looks like the password has been stripped out of the backup file but it is being passed to the ‘$shellPswd_root‘ variable.

Additionally, if we look further down the code, we can see how authentication is being performed. I have no idea why this is vulnerable. PHP isn’t my strongest area but it’s something I intend on learning more in the future. What I do understand though is that there is an if statement that checks the value of ‘shellUser_root‘ and the md5 value of ‘shellPswd_root‘ and if they are correct it loads the page. The vulnerability is probably to do with the way that the script is passing the user-submitted values to the variables.

Anyway, if we load the shell.php page and submit ‘shellPswd_root‘ to the login form, we can force the application to return the hash on the proceeding error page. The steps to do this are to input the variable, click submit, then when the login form pops up again, click cancel.

After clicking cancel, you should get an error message saying Access denied. However, at the bottom of the message, there is some data that shouldn’t be there. It is the password hash that was removed from the backup file but remains in the actual shell.php file.

Cracking The Hash

The first thing you should know is that the password has been hashed to an MD5 and then that hash has been hashed again. You could attempt to crack this with John The Ripper or Hashcat. However, the quickest way to do it is by submitting it to Crackstation. Crackstation makes short work of the hash and as you can see from the image below, the password is foobar.

With the hash cracked, we can log in to shell.php. We are greeted with a terminal that allows us to list out the contents of the directory. The output of the ls command shows us two PHP pages associated with patents. Accessing these pages requires credentials and none of the credentials we have obtained so far work. There is also a directory called test.

If we navigate to the test directory in our browser we can see that directory listing is enabled and there is a zip file we can download.

Buffer Overflow

If we download the zip file and open it with a text editor we can see that it is another authentication script. This script appears to be the authentication script for the viewpatents.php page. Furthermore, if we look closely at the script we can see that it is concatenating characters to 200. This means that there is a character limit on the input boxes.

This means we can perform a buffer overflow. By submitting more than 200 characters to the user input box we can escape the allocated memory amount and trick the application into letting us log in.

Once logged in there is another login form. Just kidding! that’s it. We’re done. Thank god.

Conclusions

I have none. I hated it.

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission 14. Unfortunately, the mission currently appears to be broken so I was unable to solve it using the intended method. I would love for somebody to prove me wrong and show me how to complete this correctly. However, after hitting dead end after dead end I gave up and looked at a number of walkthroughs. The first guide I looked at was Aldeid’s. I also watched Chuck Moore’s youtube video and read this post on the official forums. All of these guides use a null byte to complete the mission. If you haven’t seen my other posts on the reality series you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7 and, Part 8.

Realistic 14 Introduction

We received a message from an unknown source who wants to expose Yuppers Internet Solutions for selling their user’s data. The anonymous client used to work as an intern for Yuppers but quit when they learned of their nefarious data selling activities. They weren’t able to escape with proof so they have asked us whether we’re able to hack in and find evidence of their data selling.

Exploring The Realistic 14 Web Application

The website appears to have quite a bit going on. It has a search page, a news page, and a number of other pages. The web application appears to be using CGI scripts. CGI (common gateway interface) scripts are programs that execute as separate processes server-side.

Web Application Exploitation – The Intended Way

As I mentioned, this mission appears to be broken. The intended way to complete this mission is to use a null byte on the news.cgi script. Using the null byte should reveal what files are in the root directory of the web application. With these files, you obtain further knowledge about the application which allows you to proceed to the next step. Unfortunately though, no matter what I tried, I couldn’t get the null byte to work. The news.cgi script has a parameter called story. The story parameter is responsible for calling news stories.

https://www.hackthissite.org/missions/realistic/14/news.cgi?story=1

The screenshot below illustrates an example of the news story parameter being used to load a story. As you can see from the URL, the story parameter is calling the 1st story which is then displayed in the box below the search form.

To exploit this cgi script, we were supposed to append a null byte to the story parameter story=.%00. The full stop means the current directory. Upon inputting the null byte and executing the URL, we were supposed to receive a list of the contents of the current directory. Similar to using an ls OS command injection that we have done in previous missions.

However, this method doesn’t work. I’ve tried it with various different directory traversals and have attempted to use other escape characters. They either produce the message “Failed to load ..news” or they produce an error message saying it received malformed input. I submitted over 100 different payloads using Burp Intruder and had no success.

Realistic 14 Further Investigation

To back this up further, if we capture the request with Burp Suite and send it to the repeater tool we can test payloads quickly. The screenshot below shows that the null byte is failing to escape the CGI script as ..news is being appended to the “Failed to load” message. I tried URL encoding the payload and many other methods of getting the exploit to trigger but all were unsuccessful.

Web Application Exploitation – My Way

In order to progress further, we need to know the contents of the root directory. In order to do this another way, I used the tool DIRB with the -X flag to specify that I want to see all CGI files. Sure enough, DIRB found the administrator.cgi and the moderator.cgi scripts that are needed to move forward.

Unfortunately, there is no way to work around the next part of the mission. This part of the mission requires you to use a null byte to read the contents of the moderator.cgi script. I tried it with the other page parameters but ended up with the same results. The example URLs below should allow you to read the contents of the different scripts. Sadly, they do not work anymore.

URL to read moderator.cgi

http://www.hackthissite.org/missions/realistic/14/news.cgi?story=moderator.cgi%00

URL to read administrator.cgi

http://www.hackthissite.org/missions/realistic/14/news.cgi?story=administrator.cgi%00

Unfortunately, as you can see from the screenshot below, these just result in error messages. Without being able to see the contents of those scripts, there is no way to progress forward in the mission without looking up the answer.

Moving Forward

If the null byte exploit would have worked then we would have been able to see the contents of the CGI script. The CGI script would have contained a username called 'isadmin'. With this username, we can navigate to the moderator.cgi file and login.

Upon logging in, we’re greeted with a moderator panel. The panel offers two options, View Account Info and View Email Traffic.

If we submit an asterisk or wildcard to the Account Info Page then we get a list of all the information for our current user. The first two entries are the username and password.

Web Application – Privledge Escalation

With this information, we can navigate back to the index page of the application and use the Web Permit login form to log in to the application as 'web guy'.

Upon logging in and accessing the administrator panel, we should complete the mission.

Conclusions

It’s a shame that this challenge appears to be broken. If it isn’t then I would like to offer my apologies to the Hack This Site Team for making false claims. However, based on the information I have gathered and demonstrated in this write-up, I believe it is broken. It is one of the only examples I’ve come across of null byte injection so it’s really disappointing that it no longer works. I hope it get’s fixed.

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission 13. This is a fun challenge that requires you to gather information from error messages. After obtaining that information, you need to discover the hidden URL to access the admin area. Ultimately, this mission requires knowledge of web application errors, password hashes, and hash cracking. If you haven’t seen my other posts on the realistic series you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7 and, Part 8.

Realistic 13 Introduction

We’ve received a message from Fr0zenB1t which explains that they are part of Anarchists of Elbonia. The reason for the message is because they would like us to thwart the upcoming election by hacking into their competitor’s web application. Furthermore, they explain that hacking into the application and taking it down, even temporarily could help delay the election.

Exploring The Realistic 13 Web Application

The application is fairly basic. Notably, we have a navigation menu with a number of links. In the center, we have the content of those links. There is a mailing list that allows you to submit your email address but it isn’t vulnerable to any type of injection.

The newsletter page has some interesting information that is worth making note of. It claims that there is a hidden login URL that requires a password. We could brute force the hidden URL using tools like DIRB or Go-Buster. However, that could take a long time depending on the naming of the directory.

Web Application Errors

If we poke around on the pages a bit more and append question marks to the end of the URL, we can generate errors. This is possible because the pages are expecting something after the question mark. The image below shows an error on the Press Releases page. Notably, the error mentions the file path '/speeches/passwords;. However, it also mentions '.md5('Speeches')'. This suggests that there is a directory named with the md5 hash of the word Speeches.

Realistic 13 Hashing The Path

In order to discover what this directory is called, we need to create an md5 hash of the word Speeches (case sensitive). It is important to note that when creating the hash, you need to include the '-n' flag. Otherwise, the hash will be created with a newline resulting in the hash being completely different from the intended one. The code below demonstrates how to create an md5 hash from the word Speeches in bash.

Josephs-MacBook-Pro:~ Joe$ echo -n Speeches | md5
7e40c181f9221f9c613adf8bb8136ea8

After creating the hash, we can append it to the URL after '/speeches/password'. Visting that URL will produce a directory listing showing a 'passwords.fip' as shown in the image below.

Clicking on the link to the file will open it in your browser. The file contains a long string or two strings separated by a colon. The strings appear to be password hashes. We could guess what the hashes are likely to be from the length of them.

7bc35830abab8fced52657d38ea048df:21232f297a57a5a743894a0e4a801fc3

Realistic 13 Hash Identification

Or we could use a hash identification tool. I found such a tool on homebrew called name-that-hash. It’s a simple tool that is easy to install and use. By analyzing the hash we are able to identify that the most likely candidate for the hash is an md5. With this information, we can attempt to crack it to reveal what the unencrypted string is.

name-that-hash -t '7bc35830abab8fced52657d38ea048df'

Cracking The Hash

Hashcat is a popular password cracking tool and can also be found via the homebrew website. By placing the discovered hashes into a text file, we can ask Hashcat to crack the hashes for us. I used the wordlist rockyou.txt to crack the hashes. I have included the syntax and a screenshot of the cracked hashes below.

hashcat –m 0 hash.txt /path/to/wordlists/rockyou.txt

The results are in and we have our two words. They appear to be a username and password combination.

21232f297a57a5a743894a0e4a801fc3:admin           
7bc35830abab8fced52657d38ea048df:moni1

With the hashes cracked, we can head to the admin area and attempt to log in. However, neither combination of the username and password works. We have been bamboozled.

Web Application Complete

Remember back to the press release page where it suggested there was a secret directory? what if they weren’t referring to the md5 Speeches directory. What if the /admin login page that we’re attempting to login to is fake? It turns out that it is fake and that the correct directory is the md5 hash of the word admin. By appending ‘21232f297a57a5a743894a0e4a801fc3’ to the URL, you get the proper login page and with that, you complete the mission.

Conclusions

This was a fun challenge that shows the importance of minimizing information disclosure on web applications. It also shows the importance of using a strong encryption mechanism. Anyway, with that, I’m done. Feel free to check out the video below. Thanks.

Hello world, 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 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7 and, Part 8.

Realistic 12 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 Realistic 12 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

Most 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.

Realistic 12 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.

Realistic 12 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.

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission Level 11. I didn’t enjoy this challenge as much as the others. The reason why is because the mission no longer works as intended. I suspect this may be due to improvements in browser security or changes made to the application. The challenge initially required you to steal cookies through a user agent. However, that no longer appears to be the case. If you haven’t seen my other posts on the realistic series you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7 and, Part 8

Realistic 11 Introduction

We’ve received a message from Space46 who explains that their ISP has suspended their web application because they suspected they hacked another website on the server. He has requested that we recover a backup of his website which is still hosted on the server. The filename of the backup is “src.tar.gz”.

Exploring The Realistic 11 Web Application

Navigating to the web application we can see it looks like a basic hosting provider’s website. There’s a number of navigation options but none of them appear to link to anything interesting. There is a webmail page which we could attempt to brute force if we can’t find anything else.

Realistic 11 OS Command Injection

One thing that caught my eye was the way in which the application was calling pages. There appears to be a Perl script that is calling different files with the page parameter. You can see an example of the Perl script calling the features page below.

https://www.hackthissite.org/missions/realistic/11/page.pl?page=features

We can attempt to exploit this functionality and use it to our advantage by changing the value of the page parameter to a Linux operating system command. In this instance, we are going to use the ls command to list out the contents of the current directory.

https://www.hackthissite.org/missions/realistic/11/page.pl?page=|ls|

As you can see from the screenshot below, the command worked and we can see the contents of the directory. We should take note of all the files listed as they could help us in the future.

Realistic 11 Further Exploration

The results of the OS command injection showed an admin directory. Navigating to that directory reveals a login page. Unfortunately, we don’t have any credentials for it yet so we will have continue exploring the web application.

The next file in the listing is a “bs.dbase” file which appears to be a database file. Needless to say, we can’t access it but we should remember the name for later. The next directory is the “client_http_docs” directory which appears to be the directory that contains all the web applications that are being hosted. Navigating to this directory shows a number of directory listings including space46. Sadly, attempting to access this directory produces an error message informing us that the application has been suspended.

The other directories appear to serve other applications. One of these applications is the Wonder Diet as shown in the image below. Another is about a potato which is still under construction. Browsing these applications didn’t provide much that we could exploit.

The Right Web Application

The rightwayradio directory contains what appears to be a radio web application. It seems to have some basic functionality including a login form. There’s also a message on the landing age from the user “rsmith”. If we click on that user it takes us to the “userinfo” page about that user.

Exploiting Web Application Users

If we look at the URL we can deduce that the user page is being called by the id parameter in the userinfo script. Furthermore, we can see that the user “rsmith” has a user id of -1. If we experiment with the parameter, we can retrieve other users’ information.

client_http_docs/therightwayradio/?page=userinfo&id=-1

By changing the value of the parameter from -1 to 0, we can retrieve the page for the user “aclu_bomber_08290”. As can been seen from the image below, we also have the ability to change that user’s password. Initially, I thought this was absurd as we had not authenticated. However, I have seen a lot of odd application behaviours so this shouldn’t have surprised me that much.

Web Application SQL Functionality

After changing the user’s password, we’re able to log in to their account. Their account appears to have access to a moderation page that has an input box for SQL queries. We also know, from our OS command injection, that there was a database file called bs.dbase.

If we view the page source of the application, we can see that there is a hidden parameter called sql_db which has the value of rwr.dbase. This is not the database we want to query.

However, we can modify the parameter and tell it to query the database that we want to query. We also know the location of the database because our OS command injection was run in the root of the application. By modifying the parameter and telling it to move up three directories, we should be able to query the main database.

Dumping Web Users

As this is an SQL Lite database, we need to query the sqlite_master table to find out what tables are held within the database. We can do this by running the command below. I have included the output which informs us that there is a table called web_hosting.

SELECT name FROM sqlite_master WHERE type ='table';name
web_hosting

Next, we can tell the database to dump the entire contents of the web_hosting table.

SELECT * FROM web_hosting;

As you can see from the screenshot, we were able to get a list of users, passwords, email addresses and their web_package identifiers. We can see from this information that the user wonderdiet appears to be the administrator user. Their web_package id is 1 which suggests their site was the first site created. Additionally, they have admin in their email address.

Accessing Realistic 11 Admin Area

If we head back to the admin area that we discovered earlier. We should now be able to log in with the wonderdiet web user and their password of suckereveryminute. Once logged in to the admin area, we have a number of options including the ability to download a file.

By clicking the download link, we are redirected to a page that shows the full path of the file being downloaded. We know from the directory listing and the filename given to us by the client where the backup file is located.

By modifying the URL to point to the src.tar.gz file that the client specified, we should be able to download their backup file and complete the mission. I have included the full URL path to the file below.

https://www.hackthissite.org/missions/realistic/11/admin/d.pl?file=/var/www/budgetserv/html/client_http_docs/space46/src.tar.gz

Congratulations you should now have completed this mission.

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission 10. In other words, we’re going to demonstrate how not to implement authentication mechanisms. Overall, this mission was a lot of fun. It required creating a wordlist from a list of publicly listed teachers. Then, we used that wordlist to brute force the login page to gain access to the staff control panel. Once logged in, we had to flag ourselves as an admin by modifying our cookies. Then, we modified a post request to change the grades. If you haven’t seen my other posts on the realistic series you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7 and, Part 8

Realistic 10 Introduction

Poor Zach Sanchez is having a difficult time at school. In fact, he may not be able to graduate because his grades are too poor. As a result, he has messaged us to ask whether we could hack into his school’s online grade database and change his grades. Additionally, He has provided us with his username and password to allow us to explore the application.

Exploring The Realistic 10 Web Application

The application is fairly basic, it has three links at the top and one halfway down the page. As can be seen from the image below, there isn’t a lot of functionality. For instance, the home button returns you to the home page, the staff listing takes you to a list of users, and the student access system takes you to a login page.

If we click on the Student Access System we are presented with a login page that requests a username and password. Zach provided us with his login credentials so let’s test them out and see what it gives us access to.

Upon login in as Zach, we don’t get a lot of increased functionality. As seen from the image below, we can view his classes, his grades, and any comments left by the teacher. Not a lot we can do here to change his grades.

If we head back to the homepage and view the page source of the application, there is a reference to a page that isn’t displayed on the home page. Notably, this page is named staff.php which indicates that it could be a page that staff members use to log in. Perhaps we can use this page to access and change Zach’s grades.

Realistic 10 Web Application Brute Force

When visiting the staff.php page we’re presented with a login form. While we have a login page, we don’t have any credentials to use to log in. I’ve explored the application in detail and couldn’t find any additional information.

However, we do have a list of staff members on the teacher listing page. With this in mind, perhaps we could use this list to identify genuine users of the application. First I copied the user’s first and last names into a text file and saved it as usernames.txt.

Next, I cloned the username-anarchy repository from GitHub. As soon as the repository was downloaded I told it to generate a wordlist using the first name and last name, first initial and last name, and a few other combinations. I then saved the results.

Josephs-MacBook-Pro:username-anarchy Joe$ sudo ./username-anarchy --input-file /Users/Joe/Desktop/usernames.txt --select-format first,first.last,f.last,flast
adam
adam.smith
a.smith
asmith
alfred
alfred.johnson
a.johnson
ajohnson
corey
corey.beelke
c.beelke
cbeelke
edward
edward.anderson
e.anderson
eanderson
gordon
gordon.freeman
g.freeman
gfreeman
henry
henry.mathison
h.mathison
hmathison

I then refreshed the login page to capture the log-in request with Burp Suite. Once the request was captured, I sent it to the intruder tool. I then removed the automatically generated payload positions and highlighted the username and password parameter values and added the payload positions.

Launching The Attack

I selected the attack type, then pasted in the values from the wordlist in positions 1 and 2 on the payloads tab. With the attack ready, I clicked the launch attack button.

After waiting around for a while, we found the correct username and password combination. As you can see from the image below, the response length from the application is different when the correct credentials are submitted. When the incorrect credentials are submitted the response lengths are all the same (1876). This is because the response from the server is the same. However, when the correct credentials are submitted, the response length is different because it is loading the page.

Logging In

With the correct credentials, we can now log in to the staff area as Samantha Miller. This area of the application appears to give us some more functionality but unfortunately, our access to it is restricted as we’re not an administrator.

In order to elevate our privileges to that of an administrator, we need to inspect the page and look at our cookies. We could intercept the request with Burp and change them for every request but that would make our life more difficult. The image below illustrates changing the value of the admin cookie from a 0 to a 1.

Realistc 10 Changing Grades

Now that we have administrator privileges we can access the change grades option. Unfortunately, it is too late to change the grades as they are about to be mailed out. However, if we view the source code of the application we can see that there is a POST method that includes a change grades function.

If we copy the POST request and modify it slightly, we can send it to Burp Repeater and use it to change the grades. The snippet of code below shows the post request with the values that need to be modified highlighted in bold. Change the grade value to 5 and then change the rec value to 0 and send the request, then increase the rec value by 1 and send the request again.

staff.php?action=changegrades&changeaction=modrec&rec=1&studentid=1&grade=5

You can keep modifying and sending the request until the response changes from grade submitted to the congratulations message for completing the mission.

And with that, you should have completed the message.