Hello and 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 path. 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 challenge. 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.
We received a message from an unknown source who wants to expose Yuppers Internet Solutions for selling their user’s data. They 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.
Exploring The 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 on the server.
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.
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.
To exploit this cgi script, we were supposed to append a null byte to the story parameter
story=.%00. The full stop means this 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.
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.
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.
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.
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
URL to read administrator.cgi
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.
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.
Upon logging in, we’re greeted with a moderator panel. The panel offers two options, View Account Info and View Email Traffic.
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.
Web Application – Elevating Privledges
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
Upon logging in and accessing the administrator panel, we should complete the mission.
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 gets fixed.