Category: Hack This Site

Hello world and welcome to haxez, where today, we’re looking at Hack This Site Basic Web Challenges level 10. This challenge requires us to manipulate cookies in order to authenticate against the application. A cookie is a small file that contains data, the data is utilised by the applications to make decisions. For example, if you add an item to your shopping basket then the website could issue a cookie which contains that information. That way, when you revisit the application, the item is still in your basket. If you haven’t see my previous posts in this series then you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, and Part 9.

Testing The Basic 10 Web Application

After logging in to the application, you will be presented with the following page. There aren’t any hints this time, this time it’s just a password submission form. The image for the challenge mentions having to know your way around Javascript. I’ve looked at the source and didn’t find anything interesting.

I then fed the application some test data to see how it would respond. I tested a number of characters associated with various types of attacks but they were all sanitised. Submitting generic strings to the password input box results in an authorisation error.

Exploiting The Web Application

In order to investigate the application further, I used Burp Suite to intercept the request. The image below shows that the request is setting a cookie called “level10_authorized”. The cookie is set to no, but it can be manipulated through Burp Suite.

Burp Suite allows you to intercept the request and modify it before forwarding the data to the application. As we have captured the request, let’s change the value of the “level10_authorized” cookie from no to yes and forward the request. You will also need to forward any subsequent requests too.

Completing The Challenge

After changing the value to yes and forwarding the requests, you should have completed the challenge. This was a fun challenge that shows the importance properly implementing cookies. Using yes/no cookies for authentication is not a good method for authenticating users. Cookies are used for user sessions to keep users logged in. However, those cookies are set after the user has successfully authenticated with a password.

Welcome to haxez, today we’re looking at Hack This Site Basic Web Challenge Level 9. This challenge is similar to level 8 and you have to use the level 8 application in order to complete it. It requires thinking outside the box and using level 8 as the platform to launch the attack. If you haven’t see my previous posts in this series then you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, and Part 8

Testing The Basic 9 Web Application

After logging in and navigating to level 9 you will be greeted with the following page. It looks like Sam has been up to his old tricks. Instead of implementing a strong password system, Sam has decided to continue obscuring the file. The only form on this box is the password form which isn’t injectable.

Exploiting The Web Application

As there is no form to inject on level 9, we should head back to level 8 and inject that form. We use the same injection that we did last time but we modify it to list out the contents of the 9 directory. The script below performs the same Server Side Include Injection but this time it traverses up two directories in to the 9 directory.

<!--#exec cmd="ls ../../9"-->

Retrieving The Password

As with level 8, executing this payload will tell the php script to execute the command and write the output to the shtml file. When clicking view on the following page you will see the listed files including the PHP file containing the password.

Grab the file name and append it to the level 9 url. This should then show you the password which you can copy and paste it in to the level 9 password submission system to complete the challenge.

Hello and welcome to haxez, today we are looking at Hack This Site Basic Web Challenge level 8. This challenge requires you to perform a Server Side Include injection in order to retrieve the password. A server side include is a chunk of code in a separate file that you can include in different pages. For example, if you had a website with a header and a side menu. You could put the header and side menu in separate files and then include them on other pages with a single line such as “<!–#include virtual=”includes/header.shtml” –>“. A Server Side Include Injection attack exploits web forms that accept user input to generate files.

If you haven’t see my previous posts in this series then you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, and Part 7.

Testing The Basic 8 Web Application

Once you’ve logged in and navigated to level 8 you will see the page below. The information reads as follows:

Sam remains confident that an obscured password file is still the best idea, but he screwed up with the calendar program. Sam has saved the unencrypted password file in /var/www/hackthissite.org/html/missions/basic/8/

However, Sam’s young daughter Stephanie has just learned to program in PHP. She’s talented for her age, but she knows nothing about security. She recently learned about saving files, and she wrote a script to demonstrate her ability.

Security Sam

There are two pieces of important information hidden in the text. Firstly, the full file path is mentioned. This suggests to me, that we will need to know the structure of the application in order to exploit it. Secondly, Sam’s daughter has been learning PHP but doesn’t know anything about security. This is likely going to be the part of the application that we need to attack. So first, we are going to submit a basic value to the application and see what happens.

As you can see from the image below, submitting the test string has written it to a shtml file. The script appears to doing same basic arithmetic to calculate the number of letters in the submitted value. However, the thing to notice here is that it’s writing to an shtml file. This suggests, that the application could be vulnerable to a Server Side Include Injection attack. It is also worth nothing that the files are written to the tmp directory but the location of the password is one directory above that.

Exploiting The Web Application

In order to exploit the application, we can submit a basic Server Side Include Injection payload. The payload is going to use the cmd directive to execute the ls Linux command. Additionally, we are going to tell the ls command to list out the files of the directory above it. When we submit the payload, the application will include it in the script that generates the shtml page. It will execute the payload and store the results in the shtml file.

<!--#exec cmd="ls ../"-->

As you can see from the image below, the payload has been executed by the PHP script and the results have been stored in the shtml file. The au12ha39vc.php file appears to be the one we are looking for.

Recovering The Passowrd

Copy the file name of the php file and append it to the URL and you will be able to recover the password.

You can then go and submit the password and you will have solved the challenge.

Hello world, welcome to haxez where today we’re looking at Hack This Site Basic Web Challenge 7. This challenge requires performing command injection to complete it. If you haven’t see my previous posts in this series then you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, and Part 6. Command injection is a type of attack that allows the malicious threat actor to execute arbitrary commands on the host system.

Let’s begin, after navigating to Basic 7 you will be greeted with the following text.

“This time Network Security sam has saved the unencrypted level7 password in an obscurely named file saved in this very directory. In other unrelated news, Sam has set up a script that returns the output from the UNIX cal command. Here is the script. Enter the year you wish to view and hit ‘view’.”
Security Sam — HackThisSite.org

What we can infer from this, is that the script is running the UNIX cal command directly on the host system. Once the user inputs a value, that value is likely being appended to the script as a variable.

Testing Basic 7 Web Application Functionality

While we can’t confirm the exact syntax of the script, we can test the functionality to see what it’s doing. I submitted the value 1 to the submission box to see how the script behaves. After clicking the view button, we are presented with page showing all the months for the year 1. From this, I can assume that the Perl script (identified with the .pl extension in the URL) is running the command cal -y $year. The $year value is the variable that is taking the user input from the web application, and running it on the host operating system.

Exploiting Web Application Functionality

It is essential, that all user input submitted to a web application is treated as untrusted. What this means, is that the web application should check and sanitise the user input before executing it. Otherwise, this could have a detrimental impact on the server. For example, if I was to escape the cal command using a semi-colon and inject the following characters “:(){ :|:& };:” the web-server is going to have a bad time (it’s a fork bomb). However, you should never do that, not even to test. Instead we’re going to use the “ls” command which will list out the current directory.

Stealing the Password

The screenshot below shows the result of escaping the cal command with a semi-colon and running the “ls” command. As you can see, it has listed a number of files including index.php, level7.php, cal.pl and k1kh31b1n55h.php. We already know what the other files do but what is the k1kh31b1n55h.php file for?

If you copy the filename and append it to the URL in your browser, you will be taken to a page containing a string. You guessed it, the string is the password required to complete this challenge.

Hello and welcome to haxez where I try to simplify CyberSecurity. This post is a walkthrough of the Hack This Site Basic 6 web challenge . If this is your first time here you can read the previous posts here: Part 1, Part 2, Part 3, Part 4, and Part 5. This challenge is about reverse-engineering the Basic 6 encryption mechanism that Sam is using to encrypt his password.

After logging in, you will see the following screen which reads. “Network Security Sam has encrypted his password. The encryption system is publically available and can be accessed with this form”. There is also an input box, which lets you test out the encryption mechanism. In order to test the mechanism, we need to feed it some data to see how it transforms it.

Basic 6 Web Encryption Mechanism

As you can see from the output below, the mechanism has converted 11111111 to 12345678. This allows us to deduce, that the encryption mechanism is adding 1 to a base value of 0. It is then incrementing that value and applying it to the submitted value. Essentially, the first character remains the same. The second character is increased by 1. Then, the third character is increased by 2 and so on and so forth.

However, the password contains non-alphanumeric characters such as semicolons and an equals sign. These non-alphanumeric characters, can’t be increased using simple arithmetic. They must be being converted to their ASCII decimal values before being put through the algorithm. We can test this by feeding the mechanism some special characters and seeing what happens.

As you can see from the results below, it is incrementing the non-alphanumerical characters too.

The inputted value of ‘!!!!!!‘ becomes ‘!"#$%&‘(‘. This does appear to confirm my theory, that it is converting the inputted value to the ASCII decimal value. Then, for every character in the string, the value is incremented by its position in the string starting from 0. It then converts it back from ASCII decimal to a human-readable format.

Bash Scripting the Solution

In order to solve this challenge, I wrote a basic bash script that reverses the encryption process. It takes the string and converts each character to its ASCII decimal value. It then subtracts 0 from the first character and loops around increasing the value to be subtracted by 1. Once the subtraction is complete, it converts the ASCII decimal back into a human-readable format, giving you the original password.

#!/bin/bash
# This is a script that will solve the password challenge of Hack This Site basic level 6.
# The password is dynamically generated so please replace the value of MyString with the password.
MyString='62cf4;j=' #replace this value
i=0
base=0
echo "Converting to ascii value"
while (( i++ < ${#MyString} ))
do
   char=$(expr substr "$MyString" $i 1)
    for j in `printf "%d" \'$char` ; do
    	j=$((j+base))
    	printf \\$(printf '%03o' $j)
    	base=$((base-1))
    done;
done;

You can copy the script below and save it as decrypt.sh. You will then need to modify the permissions so that the script is executable. This can be done by running chmod +x decrypt.sh. You can then run the script by typing ./decrypt.sh in your terminal and it will output the correct password as you can see below.

─[joe@parrot]─[~]
└──╼ [★]$ ./decrypt.sh 
Converting to ascii value
61ac06d6

All you now need to do is to take the output string and paste it into the password submission system and you will complete the challenge.

That’s all from me today. I apologise if my explanation of the encryption and decryption mechanism was a bit hard to follow.

Welcome to haxez where today we’re looking at the Hack This Site Basic 5 Web Challenge. If you haven’t read my other posts in the series, you can do so here: Part 1, Part 2, Part 3 and Part 4. This challenge is similar to part 4. As a result, we need to modify the send password to Sam request in order to change his email to our email. However, this time I’m going to use a different method of doing so.

Once logged in, navigate to the Basic 5 challenge and you will see the screen below. This is the same as part 4, there is a password submission box and a Send password to Sam button. You can test the button by clicking it. As a result, the application should tell you that it has sent the password to Sam.

Intercepting The Basic 5 Web Request

However, instead of modifying the request directly in the source code. We are going to use the Burp Suite web proxy. Burp Suite is a web proxy that allows you to intercept and modify requests. Furthermore, It has its own version of Chromium built-in which means you don’t have to change your browser’s proxy settings. Ensure you have intercept set to on, then in the built-in browser click the Send password to Sam button.

Navigate back to the Burp Suite client and you will see that the request has been intercepted by Burp. The request is a POST request that is sending the value of the “to” parameter ([email protected]) to level5.php. In short, This is how the email is sent to Sam.

Modifying The Basic 5 Request

With the request captured, it can now be modified and changed to your own address. The address you use has to be the one associated with the Hack This Site account or it won’t work. Change the address and click forward, then forward any subsequent requests after that.

Once the request is forwarded, the website should notify you that an email has been sent to your email address.

Forwarding The Web Request

If you go and check the mailbox that you used, you should see a new email from [email protected] email will contain the password required to solve the level. Copy the password and head back to the website and paste it into the submission system.

Congratulations, you have now completed level 5.

Hello world and welcome to haxez, in this post we are looking at Hack This Site Basic Web Challenge Level 4. If you haven’t read through my previous posts in this series then you can find them here: Part 1, Part 2 and Part 3. This challenge requires the user to have some knowledge of HTML. The objective of this challenge is to recover the password however sneaky Sam has added an email script to the application.

Viewing The Basic 4 Web App

After logging in to Hack This Site and navigating to the basic web challenge level 4, you will be presented with the screen below. The text reads as follows “This time Sam hardcoded the password into the script. However, the password is long and complex, and Sam is often forgetful. So he wrote a script that would email his password to him automatically in case he forgot. Here is the script:”

Inspecting The Basic 4 Web Page Source

The concept behind this is simple, if Sam needs the password he will press the button and email it to himself. We need to manipulate the script so that the password is sent to us instead of Sam. To do that we need to view the web page source and see what the script is doing. The screenshot below shows that the email address [email protected] is being posted to level4.php when the button is clicked.

Modifying The Basic 4 Page

We can modify the page source directly through developer mode. By double-clicking the current email address, we can replace it with our own. Once we have changed the email address we can click the “Send password to Sam” button and it will send the password to our email address.

Submitting The Web Request

After clicking submit go and check your mailbox to see if the password has arrived. The email will be from [email protected] and will contain the password. If you open the email you should be able to copy the password and paste it into the password submission system.

This was a fun challenge that teaches a valuable lesson about hardcoding passwords or other credentials within applications. If the code is rendered client-side then no sensitive information should be included in the code.

Hello world and welcome to haxez, in this post we will be taking on the Hack This Site basic 3 web challenge. Hack This Site is a great location to learn web application security. In fact, It is the first website where I started my hacking journey. This challenge involves some knowledge of how web applications are structure. Most web applications use a hierarchical layering whereby. As a result, the first page you find will tend to be in the first directory. Then, the sub directories may contain other information. For instance, if I wanted to access the about section of a web application I would visit https://haxez.org/about/ where haxez.org is the root and about is a page.

After logging in to the site and navigating to the basic challenges. Select level 3. It will say the following.

“This time Network Security Sam remembered to upload the password file, but there were deeper problems than that”.

The blurbs of text try to give us a clue about how to solve the challenge. On this particular challenge the word deeper stuck out to me. What could they mean by going deeper? These challenges were out before the movie inception so it can’t be a reference to that.

Solving Basic 3

By going deeper in the directory structure or the file path structure, the user should be able to retrieve the password. By visiting https://www.hackthissite.org/missions/basic/3/password.php and viewing the page source you should be able to retrieve the password.

This is a good example of what to look for in web application tests and how easy things can be overlooked. By mapping out the directory structure you not only get a clearer picture on how the application works, but you also might find something interesting like login pages, sitemaps or robots.txt files with sensitive information.

Thats all for now, see you next time.

Hello world and welcome to haxez. This post is about web hacking and walks through the basic challenge level 1 on Hack This Site. This is a short and sweet article today as I’m going away for the weekend. This challenge is fairly easy even for the less computer literate. The purpose of this challenge is to get the user to view the source code of the application in order to retrieve the poorly hidden password. After creating an account and logging in, head over to the basic challenges and go to basic challenge 1. You should be greeted with a screen like the one below.

Basic 1 Page Source

This challenge is a basic challenge that asks you find the hidden password for the input box on the page. One of the most fundamental skills in web application testing is to view the page source. This can easily be achieved by right clicking on the page and selecting view page source from the context menu. Once you have the page source window open, you should see a lot of code.

You can manually look through the code or you can hit control and F and that should bring up the search box. Once the search box is up, you should be able to search for the word password and the search facility should automatically jump you to the section of code that contains the password.

As you can see from the snippet of code below, you should be able to retrieve the password and submit it to the application. The password is 0c620cce.

Congratulations, you have completed Basic challenge 1. I know this one was very easy but I love Hack This Site and didn’t feel that my blog would be complete without it.