PVA – Archives

Sưu tầm những bài viết hay trên internet…

10 level at hack this site (basic web)

HTS Basic Web 1: Check the Source

The first mission in the Basic Web category, also known as the idiot test, is certainly not a very realistic mission. It isn’t supposed to, either — It is supposed to teach you the basics needed to solve these missions. In these situations, you should always begin with looking at the source code. If you are using Firefox (which I definitely recommend), right-click and choose View source. In this level, the solution is actually written there:

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

Input the password (in this case it is abcd1234, but you should have another one) in the password field and press enter. Congratulations.

HTS Basic Web 2: A Forgotten File

This is the second mission in the Basic Web category. It is a significant step up from the first mission, where only the knowledge of a very basic technique was required. Here, you need to think logically. Let’s approach the problem in the same way as in the previous mission — check the source code. In the relevant code area, which you can find by searching for a string present in the mission paragraph (for instance “Sam”) with Ctrl+F, you find only this:

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

HTS Basic Web 3: Hidden Fields are Not That Hidden

Ok, so in the third basic web mission, our old friend Network Security Sam remembered to upload the password file. As usually, though, he forgot something essential. Let’s look at the source:

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

HTS Basic Web 4: Alter the Hidden Fields

In the fourth basic web mission, Network Security Sam apparently hasn’t learnt anything from his prior mistake. In the third basic web mission, we extracted information from hidden form fields and thereby found out the name of a password file. The procedure is essentially the same in this mission. As usually, check the source code first. These snipets have been formated for easier reading:

<form action="/missions/basic/4/level4.php" method="post">
    <input type="hidden" name="to"
    <input type="submit" value="Send password to Sam">
<form action="/missions/basic/5/index.php" method="post">
        <input type="password" name="password">
        <br /><br />
        <input type="submit" value="submit">

As you can see, this level contains two forms. The upper one is the “Send password to Sam” button, and the lower one is the password field. You should already have noticed the highly suspicious hidden field in the upper form. Its purpose is obvious: it supplies the email address that the password will be emailed to. From merely knowing this address, you cannot achieve anything (except if you managed to hack the hulla-balloo.com server). Therefore, you should alter the field to contain your email address instead of Sam’s.

In order to enter your own information in to, the hidden field, you can create a local copy of the form. In your modified version, you can either change webmaster@hulla-balloo.com to your own email address, or change the type="hidden" to type="text". The prior changes the email address automatically, while the latter allows you to enter another address.

If you are pedantic and want your local version to validate, use the following code.

    <title>Hack This Site!</title>
    <form action="http://hackthissite.org/missions/basic/4/level4.php"
        <input type="text" name="to"
        <input type="submit" value="Send password to Sam">

HTS Basic Web 5: Javascript Injection

This is the fifth basic web mission, and Network Security Sam apparently “secured” his email script. After a quick look at the source code, we see that the code visible to us is exactly the same as in the last mission. However, if we try the same hack as in the fourth mission, writing a form of our own, we can see that Sam’s new script checks the referer, i.e. the page that you came from. If it is not equal to the page that you are supposed to come from, you get an error.

This leaves an interesting option. Remember that hidden field that we changed?

<input type="hidden" name="to" value="webmaster@hulla-balloo.com">

We can still change the value of to, but it will require a more sophisticated method: Javascript injection. Did you know that you can execute arbitrary Javascript code on any page? Since Javascript is always executed client-side, this does not often create vulnerabilities. It can, however, throw arrogant network administrators such as Sam off. To execute Javascript code on a page, type this in the location bar (the input field where the URL shows):


Replace code with any Javascript code. In this mission, we want to alter the value of an element’s attribute. This is where the HTML DOM comes in handy. By using the document object in Javascript, we can access every single element in the document.

A form is accessed by document.forms[n], where n is the number of the form. If you count the forms in the source code, you can see that the form we want is the second. Number one, that is — remember that you always start counting on zero. We want to access the to element’s attribute value, so we’ll simply write document.forms[0].to.value. Let’s check if it works by putting the value in an alert box. Type:


An alert box with the text “webmaster@hulla-balloo.com” (the value of to) should popup. If not, check so that you haven’t disabled Javascript. Instead of merely reading the value of to, let’s alter it:

javascript:alert( document.forms[0].to.value = "webmaster@example.org" )

The alert() is there to show the new value, in case anything would go wrong. Now the value has been changed, so you can just push the Submit button, and the mission is complete!

HTS Basic Web 6: Decrypt the Password

The fifth basic web mission is very different from the prior missions (except maybe in one way the second mission) in that it requires an extensive use of logic. Actually this mission doesn’t have anything to do with hacking, but it teaches a very valuable lesson, which we will come to later.

By looking at the source code, we can only see the two forms. Nothing interesting. The next step is to try out the password encryption form. Type anything, and you can see that it does work. It shows you the encrypted string. Logically, the task is simply to construct a string that is encrypted to the code you were given. I got dg7847>l. First, try with something simple:

a -> a

a gives a. Seems simple, doesn’t it?

aaaaaaaa -> abcdefgh
bbbbbbbb -> bcdefghi

This is interesting. The same character is converted to different characters depending on what position in the string it has. If we think about it, though, it isn’t complex at all: In place 0 (the first), the letter is moved 0 steps in the alphabet. In place 1, it is moved 1 step, and so on. The password, though, contained a character other than a-z, >. How can we get it? Let’s check what happens if the alphabet isn’t enough:

wwwwwwww -> wxyz{|}~

That gives it all away: everyone should know about the ASCII table. After x, y, z comes — that’s right — {, |, } and ~. Now, we only have to find the correct characters. Every character should be counted backwards a number of steps equal to its position in the encrypted string. Start with the first character. dg7847>l:

d -> d
f -> g
5 -> 7
5 -> 8
0 -> 4
2 -> 7
8 -> >
e -> l

The decrypted string is therefore df55028e. Check it first to check if you have to adjust it, and then use it to continue to the next mission. As I said before, this mission teaches a very valuable lesson: never, ever use a simple encryption algorithm. The best would be to use an irreversible algorithm, such as MD5 or SHA-1. It is even better if you manage to hide the algorithm, although security through obscurity should never be recommended. Of course, the best is to never let the encrybted password leak out.


Remember to change the URL from local to absolute (http://hackthissite.org/missions/basic/4/level4.php instead of /missions/basic/4/level4.php). Save the file as e.g. hackthissite.htm, then open it in your web browser.


Ooh, he’s got a hidden field in there. Those are always exciting, mainly because of a common misconception. Many uneducated (or learning) webmasters seem to believe that hidden fields are impossible to find. This is certainly not the case. They are just that — hidden. Anyone could find them (and possibly change them), if they just took some time. A form’s hidden fields are revealed in the source code. Here is a field that Naive Network Security Sam hoped to remain hidden:

<input type="hidden" name="file" value="password.txt">

Anyone can figure out what this field is for. Yep, that’’s right: the password file. Now we’ll just check the content of the password file, and after that, we’ll have the password. Thus, you must only go to http://www.hackthissite.org/missions/basic/3/password.txt and copy the content. Just enter that password, and you shall be granted access to the fourth mission.

Now you might ask, how could Sam prevent this? There are three simple ways:

  • Hide the content of password.php. Password.php could assign the password to a variable, and then be require()ed from the main password-checking script.
  • Hard-code the filename. This way, the user cannot intervene.
  • Hard-code the password. This is, though less managable, perhaps even better, since there otherwise could be problems if the password file could not be read for some reason.

What we see here is a simple HTML form, containing a password field and a submit button. Nothing interesting, that is. The only way we can continue here is by trying out the form and following wherever it leads: Just input some random password, e.g. “test”. You will, probably to your surprise, not be faced by a page saying “incorrect password”, but a page saying:

“Warning: fopen(password.php) [function.fopen]: failed to open stream: No such file or directory in /var/www/hackthissite.org/html/missions/basic/3/index.php on line 35″

First off, this is apparently an unintentional (from Network Security Sam’s point of view) error. Error messages are probably the by far most common security leak, and are often likely to expose vulnerabilities. This error message reveals first that the file is a PHP file (although this could be faked, it is not very likely), and second, more importantly, that there was a file which could not be opened. The mission designers left us a not-so-subtle hint (“However, he neglected to upload the password file”) which tells us what file was not uploaded: the password file.

Now for the logic thinking: Assuming that the password file existed, what happen? Probably, the password that you inputed would be matched with the one in the password file, and if they matched, you would be granted access to the next page. Now if there is no password file, what would the user input be matched with? Yep, you guessed it — nothing. Try just clicking the submit button without touching the password file. Mission complete.

Note that this is why it is very important — from a security perspective — to always check if every function works. In this case, if our dear Network Security Sam would only have taken a few seconds to check if his call to fopen() (a function that opens a file) really opened a file, his script would have been impenetrable.

HTS Basic Web 7: cal call unrelated?

Level 7 is a very easy level, if you are a Linux user. We don’t even have to check the source. The HackThisSite.org crew is kind enough to tell us where the password is: in an obscurely named file, saved in the current working directory. Now, we only need to come up with a way to get a directory listing. This is when a very useful and frequently used UNIX command should come to mind — ls. From the ls man page:

ls – list directory contents

Sounds good. If only we could perform arbitrary operations remotely. Take a look at that unrelated script that calls cal. Try it out by inputing a random year and submitting. It looks just like the normal output of cal. Remember that, when searching for security vulnerabilities, you should always think like the developer. How could cal.pl look like? This is a simplification:

print `cal $year`;

Where $year is the input. Injections are the bane of all web applications. Here, a Perl injection would come handy. What happens if you do not enter a year? If my guess about what the code looks like was correct, it will be executed as a normal command. Let’s take year 1337 just for the sake of it.

1337 && ls

The command executed now will be cal 1337 && ls /. This will first give you a calendar of the year 1337 AD, after which it will give you what you want: the directory listing. Just look through the directory listing after an obscurely named file, and then read the file in your web browser. Mission accomplished.

If you didn’t like Network Security Sam, you could’ve made things much, much more nasty. 1337 && rm -rf, for instance, would delete everything in the filesystem.

HTS Basic Web 8: Evil SSI

Network Security Sam never seems to learn from his mistakes. In mission 8 of the basic web missions, Sam has done the exact same mistake as in mission 7: he practices security through obscurity. This is never a good idea. This time, he saved an unencrypted password file somewhere in /var/www/hackthissite.org/html/missions/basic/8/. Last time, we used Sam’s insecure cal script. This time, his daughter Stephanie has put up a handy script for us.

Try out Stephanie’s name script. You’ll find out that whatever you input into that box is saved to a random filename with some additional text. This is where you should think about SSI. SSI is a technology that allows execution of server-side commands on the processing of files, a bit like PHP. The by far widest usage of SSI is to include header and footer files. The syntax of an SSI include looks like this:

<!--#command attribute="value"-->

You only need to use one command for this mission, exec. exec is used to execute any UNIX command on the server. Remember from the last mission what the command for listing all the files in a directory was? Try using it. Enter this into the name field:

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

This is the output I got:

Hi, tshngmww.shtml hipykpqu.shtml ztxdhjxn.shtml avpfeoie.shtml fviqpmaw.shtml kqbybdzc.shtml dzrnmzgx.shtml npcsygfl.shtml whqxxojt.shtml ylomcmvu.shtml uhdppswp.shtml gzntiicx.shtml dzwbqiuu.shtml qvzuieng.shtml smcerykh.shtml qjhnmhmq.shtml znodwztr.shtml!

Your name contains 254 characters.

Looks great, except one thing. It’s the wrong directory. If you look at the URL, it will say something like this:


We need to ls one directory down. The path to the parent directory is always .., which means that we can list the files of the parent directory (/missions/basic/8/) with the following SSI code:

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

After you have found the obscure filename in the file list, you can simply access it in your browser and read the password.

HTS Basic Web 9: Directory Transversal

Basic Web mission 9 is so easy, it is barely worth a post of its own. The only thing that might be difficult is realizing that you should find a vulnerability in the eigth mission — however, that problem exists only if you attempt to solve mission 9 without looking or without reading the instructions.

This challenge is essentially identical to mission 8, except that the password file is in another directory. There isn’t much to learn from this, except that vulnerabilities are not always were you expect them to be.In the last mission, you entered the following in the name field:

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

Which, with .., goes down one step from /missions/basic/8/tmp/ to /missions/basic/8/. The directory we want to go to is /missions/basic/9/, which means that we will have to go down another step and up to the directory 9/ from there. This practice is called directory transversal.

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

Your file will be saved, and you can read it in order to find the filename out. Load the file, and you’ve got your password. Remember that the file is in /9, not /8.

HTS Basic Web 10: Cookies!

Basic Web mission 10 is, just like the previous nine missions, easy if you know the technique. I will assume that you use the Firefox extension Add N Edit Cookies, which is a very useful tool for viewing and editing cookies.

Network Security Sam has decided to hardcode the password into the script. He also started to use cookies to detect if the user is authorized to advance to the next level. When you enter the correct password, it sets you to authorized, and if you enter an incorrect password, it sets you to unauthorize

Here, we are even given exactly how Sam’s script works. Enter some random password, and you will see that you are not authorized. Now, open the cookie editor and check what cookies you’ve got from hackthissite.org.

Add N Edit Cookies screenshot

Edit the cookie named “level11_authorized” and change the content from “no” to “yes”. After this, you can access the page /missions/basic/11. Congratulations, you just completed the basic web missions.

google_ad_client = “pub-2303908469917611″;
google_alternate_color = “FFFFFF”;
google_ad_width = 336;
google_ad_height = 280;
google_ad_format = “336x280_as”;
google_ad_type = “text”;
//2007-08-09: timjoh_toppost_lr_default
google_ad_channel = “5939880185”;

About these ads

13 responses to “10 level at hack this site (basic web)

  1. Chad 22/09/2008 at 9:52 AM


    What would that be then? For basic 6.

  2. john brave 04/10/2008 at 3:12 AM

    i want buy cc with fullz infro if any body sale please contact with this email: aliali_mali@yahoo.com

  3. john brave 04/10/2008 at 3:13 AM

    i need good hacker please contact with me

  4. snipeitof 15/02/2010 at 9:10 PM

    I don’t get it…
    I use “edit cookies”, an extension for mozilla firefox, because the other program isn’t working. Only problem is, when I enter a pass, and when it’s wrong, I search in the cookies, but only cookies that are listed for that site are:

    Please help, thank you!

    • nick 15/11/2012 at 9:32 PM

      Use Javascript injection if you cannot edit the cookies. javascript:alert(document.cookie=”level10_authorized=yes”) Javascript injection does not work on the latest firefox however. you will need to use something like chrome.

  5. Smeep 03/03/2010 at 7:52 PM

    Look for the cookies begining www. rather than with ‘h’

  6. jerome 04/07/2011 at 7:31 PM

    where can i go for the decoding of the password

  7. harsha 19/03/2012 at 11:20 AM

    level 7 : “ls” command not work for me and i have tried all this combination of commands
    http://www.hackthissite.org/missions/basic/7/cal.pl && ls/


    http://www.hackthissite.org/missions/basic/7/ls -l/
    and im using firefox 10.0.2 is there any problem with my browser ???

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: