Sun, Jun 27, 21
Welcome back to my walkthrough of hackthissite.org’s CTF missions. I will be going through my thought process of how I solved these missions, and therefore also giving away the solutions. If you came across this to give you hints, watch out for spoilers! Good luck, have fun.
Our next realistic mission asks us to find evidence that Yuppers Internet Solutions is selling user data and usage habits over to advertisers.
As always, we begin with an evaluation of the website, trying to note anything interesting that could be useful for us at a later time. We start with the homepage - index.cgi - , with which we can already being gathering information about their server directory layout. From the navbar, we can see that it links to the following pages: {search.cgi, news.cgi, finance/, mail/, yweb/, people.html}. We can see a form that makes a GET request to search.cgi that sends a search field. Below that, we can see an ad - which doesn’t work for me - that relies on a script marked as include/ad.js to swap out the shown add on an interval of 5000 ms. In order to to so, it makes a request to adserver.cgi with a query string of the form ad=[x] where 0 <= x <= 6, and switches the src attribute of the img tag as per the result of the call. Lastly, we can see in the footer one more link to an about.html page.
Trying out the functionality of the ‘search’ form on the homepage with ‘test’ returns 4 search results that shows a partners/[int]/ endpoint. Furthermore it shows the query string for the news.cgi endpoint, which is, story=[int].
Going to news.cgi, we can see that there are only 4 articles listed. Testing news.cgi?story=5 results with a message stating: ‘Failed to load 5.news’.
Moving onto ‘Finance’, we find 2 forms that make the same request to finance/index.cgi with the query string symbol. Trying the symbol ‘nvda’ results with the message ‘Company Not Found’. This implies that when the query string is not found, Otherwise, there is also the query string quote that seems to return any matching string to their listed symbol name.
Moving onto ‘Mail’, it says that we must be loged in in order to use that functionality. It links to the login page - login.html - which was also present on the homepage.
Checking out ‘YWeb’, it also says that we must be logged in to use that functionality. It also links to the login page.
Finally, the ‘People’ page has two forms that make a GET request to people.cgi. The first one has the query string room. The second one has the query string search. tyring to submit informs that I must be logged in.
In order to complete our investigation I must create an account and explore the functionalities that were blocked.
On the login page, we see that there are two forms present. The first one being the login form. It makes a POST request to /webpermit/login.cgi. The fields of this form are the following: {yuppers_user, yuppers_pass}. The second makes a POST request to /webpermit/signup.cgi. This form has many fields, and I will not list them all here, but you will see them further down below in the full overlook. By submitting an empty field, we can see that it gives us a note saying that many fields are empty. By a quick look, it seems like each field is required in order to create an account. After creating a test account, we are told that we have been given an email account with the domain @yuppers.nod, a Y-Web webspace, and access to Yuppers! people. It should also be noted that after login-in, two cookies are set: {yuppers_user, yuppers_pass}. The password is stored in hashed form. Testing with JohnTheRipper quickly, doesn’t result with the potential candidate of the unhashed value that was stored. Checking the website hashes.com/en/tools/hash_identifier, shows that this hash matches with xG1lxrKutest, which could be possible as the password that I set was indeed test. Thus it suggests that the backend appends a salt value in front of the pasword then stores the hashed SHA1 form. Doing a quick test with the following Linux command: echo -n xG1lxrKutest | sha1sum | grep fd9e4ef4e56e46e2d55b35e560f0a5f78057957d does indeed show that the hashes match.
Going back to the ‘Mail’ section, we can see that this webpage hosts a form that makes a POST request to /mail/index.cgi with the following fields: {to, cc, text}. The ‘Y-Web’ webpage displays a form that makes a POST request to /yweb/index.cgi with the field text. The form implies that what is entered into the form will be directly displayed on my account webpage. The webpage can be found at /yweb/?[username]. Checking out an empty /people/index.cgi?room= I can see that there is an embedded applet which points to jirc_nss.zip,resources.zip in the archive attribute.
From here, I can say that the overall initial investigation is complete. I now have a general understanding of the entire website. Sadly, I have no idea where to move forward in order to complete this mission. Below is an overall structure of frontend endpoints with any corresponding calls that exist on them.
Overall, I have noticed that all the inputs, whether it be through a GET or POST request, are validated to some degree. My next step would be to try and push the limits of this validation to try and get some sort of system error rather than a validation error.
I will start off with the search.cgi endpoint and trying some unusual inputs to see whether it cannot comprehend them. After several inputs,with some ‘exotic’ inputs and ‘normal’ inputs, it is evident that this script has a pre-defined set of pages that it would search - using something similar to grep - for the search key word; once it has found all the pages that contain said search key, it would return those results. This implies that this script would not be useful for any ‘hacking’ purposes as it simply does a search of some predefined files for a given search key.
Moving onto news.cgi, using the ‘search’ functionality on this webpage, it is instantly evident to me that it works the same exact way as does the search.cgi script. Otherwise, we already know that we can also use this endpoint to access a specific news story directly by using the query string ?story=. Going back to the prior error message that I pointed out where the query string ?story=5 outputs ‘Failed to load 5.news’ could imply that news stories are actually stored as files marked [int].news. Trying another query string, ?story=test, results with the error message ‘Failed to load test.news’. This implies that the script tries to load some file into the output that we see as the webpage. It is possible that this is done through an include and thus make it susceptible to the Poison Null Byte. The short explination of this exploit is that several different languages interpret the Null Byte differently - \0 AKA %00 - thus when mixing different functionalities across different programming languages there happens to be some unexpected outcomes. A good explanation of this can be found here, and here. Long story short, I assume that the backend does some sort of include as follows: $userinput + ".news". Thus, if we were to inject the Null Byte, we would get an outcome such as: \0.news which, when interpreted by underlying C architecture, would result with the string ‘’ since C uses the Null Byte to distinguish the end of a string. Using this exploit, we could possibly get an output of the current directory by using the query string ?story=.%00. The period is for ensuring that we include the current directory. Unfortunately, this simply gives me the error ‘Failed to load ..news’, which could mean that the Null Byte is stripped prior to executing the include. Trying the query strings {?story=./%00, ?story=.\%00, ?story=..%00}, gives the message ‘Malformed Request’. Subsequently, trying ?story=test%00 results with ‘Failed to load test.news’ which does confirm my suspicion that the Null Byte is stripped prior to any C code interpretation of the constructed C string. Otherwise, nothing else comes to mind that would make anything on this endpoint vulnerable to exploitation. Back to the drawing board!
Shifting my attention to the finance webpage, trying ‘exotic’ and ‘normal’ inputs on either query strings doesn’t show any unexpected behaviour, and neither does it show vulnerability to SQL injection.
Visiting the ‘Mail’ page, we notice an interesting script that handles the logout link above the send email form. We see that a cookie that has not been set yet - admin_login under the path / - being unset. THis same script is found on the ‘Y-Web’ page on the logout link. Exploring both the ‘Mail’ page and the ‘Y-Web’ page, nothing of interest is found. Although, there is an interesting random find that there does indeed exist the user admin as the query string /yweb/?admin does present a valid webpage.
After an hour or so of playing around the website, I haven’t been able to find anything that will suggest that it is the way forward. And I will search up the next step that is required to move forward with this mission. After doing so, I can see that the way forward was actually through the Null Byte exploit that I mentioned above, however, it seems to have been inadvertedly patched as the Poison Null Byte exploit no longer works. Furthermore, this exploit is used more than once in the completion of the mission, thus, I will no longer continue this mission as I deem it to be broken.