MiniCTF Security Challenge 6

August 13, 2014

MiniCTF  Security Challenge VI: Cookie, Cookie

 



Security challenge IV gives us a similar page to challenge III, with a changed color scheme, a dynamic member's list, and a way to register an account. So we have a way to enter a user account and the ability to read it elsewhere? Interesting. Let's continue. Try entering a single quote into the login and register pages to see if we get any SQL errors. No luck. Let's create an account to see what happens. 

I made the password asdf.


Click the link to the member's list and check out the order in which the account was posted.




Conveniently enough, the member order is chronological so we KNOW (in the context of this challenge) the first account is actually an admin account. Let's try logging on with the account that was just made:


In the picture above, I have an arrow pointing to the remember me box. This creates a cookie that tells the server what your account is and the password associated with it. If you don't click the remember me, the cookie gets flagged for deletion and you won't be able to see it using my favorite web tool--the web inspector on firefox. You can also see cookie data being passed along real time through Burp. I'd recommend it for some quality cookie viewing. Checking the cookie:


So here we see usernamesch6 and passwordsch6 which are obviously the username and password that we've logged in with. The username and password are encoded,which is a relatively common practice in these challenges. The "==" (%3D%3D) usually signifies base64 encoding. If you're not sure, you can google search the encoding. Anyway, let's just do a quick test to make sure we're doing exactly what we think we are.


So the usernamesch6 decoded is asdf. If we look at the password, though, it's encrypted. Let's try to get past it by changing the usernamesch6 to admin (remember we have to encode it with base64 because our query is read in base64!). Reload the page and it shows a welcome to the admin. Click the admin only page and we're still denied access. We need a way to stop the query from checking the password. We've done it before on previous challenges. Let's put in our own query to check if 1=1 (which is always true) in place of the query which searches for a matched password. 


 
This stops the password check from even being processed and allows us to skip the auth process altogether.

Changed our usernamesch6 cookie to the encoded injection and we get our key!



You Might Also Like

0 comments

Popular Posts

Like us on Facebook

Flickr Images