Hello world and welcome to haxez where today we are solving Basic 11. This the final challenge in the Hack This Site Basic web series. The series as a whole has been fun and I recommend giving it a go. This challenge doesn’t require any form of exploitation. Instead, it relies on the user’s knowledge, whit, and exploration skills. It’s a bit of a cheeky challenge as the last part had me scratching my head for a bit. If you haven’t seen 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.

Navigating to the Basic 11 page shows a sentence that includes a song title. After a bit of research, it turns out that the song was sung by Elton John. Not knowing what to do with that information, I continued exploring the Web Application. The way I solved this challenge was to brute-force the directories. However, that isn’t the intended approach and would probably be frowned upon by the Hack This Site server admins. Sorry guys.

Exploring The Basic 11 Web Application – The Hard Way

The proper way to solve this challenge is to use your whit and deductive skills. We know the song was sung by Elton John so let’s see if there is an E directory.

The ‘e’ directory exists and even better, directory listing is enabled on the server. We can see that the next directory is the ‘l’ directory. I can see where this is going.

Tumbling, tumbling, tumbling further down the rabbit hole we go.

Almost there

One final directory to check and we will have the password.

Or not, after all that, the directory is empty. Or is it? dotfiles are hidden files on a Linux system. One particular dot file used within web environments is the .htaccess. If we navigate to the .htaccess file we can see the following data. Normally, .htaccess files are protected so they can’t be read by everyone. However, it looks like the file permissions are wrong on this one.

The .htaccess file shows some information, the most important part is the DaAnswer directory. We can append DaAnswer to the current URL and it produces the page below.

I must admit that this had me scratching my head for a while. I viewed the source code, I checked other directories, I was stumped at this point but the answer was right in front of me. The sentence literally tells you the password. The answer is available. I can’t believe how long it took me to realize this. I feel that this is cheating slightly. With the password in hand, you can head to the /11/ directory followed by index.php. That should allow you to submit the password and complete the challenge.

Exploring The Application — The Easy Way

Normally once a challenge is complete I wouldn’t explore it further. However, I feel that I need to be honest about how I actually solved this challenge. I cheated. I was stumped on the song titles. As this challenge didn’t require any form of exploitation I didn’t know where to go next. I used a brute force tool to learn the location of the directories. The brute force tool also found the .htaccess file and the DaAnswer directory. I believe doing it this way was quicker than it would have been if I had done it manually.

That’s it from me. I have really enjoyed this series and can’t wait to start the realistic missions.

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.