Broken Authentication - Brute Forcing a Stay Logged In Cookie

what is up guys we're going to be taking a look at this lab brute forcing a stay logged in cookie easiest starting point here is just to see how the functionality is supposed to work and we given some credentials here for a regular user username wiener password Peter objective is to Brute Force Carlos's cookie all right without further Ado let's access the lab let's imagine we're looking to log in as a regular user we click on my account we have been given some valid credentials username Wier password Peter notice fairly common feature of a login box we have a stay logged in checkbox this means we don't have to log in every time we revisit this site from the same browser will automatically be authenticated so let's check that option stay logged in and choose the option to log in now one thing to notice here is that when we are successfully authenticated we have this output update email to the screen that may not immediately seem relevant but we're going to GP output for this particular string update email as an indication that the brute force of the victim's cookie has been successful so note that when we're successfully logged in the page says update email so here is a copy of the request sent to for slm my account you can see as part of the query string there we have the ID parameter equals wiener and we also have a value in our headers for the cookie you can see there is a session ID but also we have a stay logged in value and we're given a string for this now this is obviously unreadable at this stage but if we highlight the string we see that over on the right hand side in the inspector that burp automatically detects that this is probably a base 64 encoded string and it's able to decode that string for us if it wasn't automatically decoded we could head over to the decoder and we could experiment with different types of encoding figure out whether there's an underlying readable value now the decoded version of this string is WIA that's the username colon followed by another unreadable string which is likely in an encoded format also now once again we don't automatically know how that string has been encoded although we can make some logical guesses and we will find depending on let's say the hashing algorithm used that certain strings have certain signatures could be the character set that's used it could be the length of the resultant hash so in this case we're going to make an educated guess that this is the result of an md5 hashing algorithm now we can confirm that simply by making use of the Linux command line tool md5 sum now often this is used to get the hash of a file but we can actually use the command to get the md5 hash of a string by echoing the string and piping it into the md5 command so we're going to make use of bash Echo we'll use python n this is going to exclude any new line characters from the echoed string and we're going to Echo our password string which is Peter in this case we're then going to pipe the output to the md5 sum command notice we get a string starting in 51 ending in 770 taking a look at the string that was decoded using base 64 we see that same md5 hash starting with 51 and ending in 770 now words after we base 64 decode the stay logged in value we are left with the username a colon then the md5 hash of the password now at this stage we are going to log out of our account and we're going to attempt to reacc the account by tampering with the value of the cookie now it's not too much of a feat in this case because we already know our password anyway so it's pretty easy to generate that cookie if we wanted to question is can we have a proof of concept that we can recreate that cookie without using the SES built-in login system so here is the request sent to for/ myy account we have the value of the stay loved in cookie and we're going to attempt to recreate that so we'll delete the current value of the stay logged in cookie and then we're going to add payload positions either side of the stay logged in value let's then go to payloads and under payload processing we're going to be adding some rules but we will start with a simple payload of our password in this case which is going to be Peter we can then use payload processing to modify this value so we're going to add several rules the first is that we're going to take the md5 hash of the payload Peter so at the moment we're just using a single payload but the idea is these rules will apply to a whole list of payloads so let's choose the option to Hash we're then going to choose md5 hash go to okay that's the first processing task that's going to be performed on the payload Peter we know then that we need to add a prefix because this is going to be the username select rule type add prefix the prefix in this case is the username followed by a colon let's choose okay then we know that that entire string so that's the username followed by the md5 hash of the password is going to be base 64 encoded let's add another rule in code base 64 in code choose okay you can see there are three steps there let's choose start attack so we can see request one we have our payload which is that base 64 encoded string we have a 200 status code and if we take a look at the response we'll see the string update email now we didn't need to grep for that because we have a single payload however when we're brute forcing the victim's cookie it's going to make sense to grep for that string update email so that we can understand which payload was successful in brute forcing the victim's cookie so let's return now to our Intruder attack with the payload positions around the stay locked in value going to make some changes first of all we're going to change the ID parameter to Carlos we're then going to update the list of payloads let's remove Peter let's paste the sample list of passwords that's provided to us through the portswigger site we're still going to be taking an md5 hash but the prefix we're going to add is no longer going to be Wier it's going to be our Target Carlos so instead of weer colon going to use Carlos colon but we then proceed to base 64 in code in exactly the same way now we're going to head to the settings tab and we're going to set up a GP match match type simple string let's clear the existing list and we'll looking to match the string update email we'll click add to add this to the list of strings that are being GPT for and with everything in place we can choose the option to start attack and we're looking for a result that has a match in the update email column in this case we see request 45 gets a 200 response the other requests get a 302 redirect to the for SL login in other words this user is not authenticated please log in however with this particular payload we get the status code 200 and we get a one in the update email column we check out response we can see that we do in fact have the update email string as part of that response now if we head back to the lab it detects that we have actually accessed Carlos's account and we get the flag congratulations you sold the lab now if we want to actually access Carlos's account on the browser we can right click on the request choose request in browser in original session we then receive a link that we can copy we paste that in our browser here we are at Carlos's account so clearly the issue with this vulnerable lab was the cookie it was simply too easy to reproduce the value of the cookie that cookie really represents a pass squ in this case in other words if you have access to the cookie you can access the account so it shouldn't be something that's too easy to reproduce so although there were Protections in place you can see that it was fairly trivial to generate the cookie of another user and that cookie value is also always going to be the same it's not rotating to different values so once we have that cookie it's going to work in perpetuity second issue we had there's no Brute Force protection on the cookie so ideally even if the cookie is fairly simple to regenerate we still have that Brute Force aspect to this lap if there was a mechanism in place that prevented us from being able to make Brute Force attempts on the cookie then we wouldn't have been able to solve this lab so we can see two weaknesses here in the way that authentication is implemented via that stay logged in cookie all right hope it was helpful thanks very much for checking out the content and I'll catch you guys in the next lap

Channel: z3nsh3ll

Views: 110

Keywords:

Id: 8KTMZBE2P7E

Length: 8min 55sec (535 seconds)

Published: Tue Jul 02 2024