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.