BSides Berlin 2021: Harsh Bothra - Exploiting vulnerabilities in cookie based authentication.

uh today we are going to discuss about god cookies cookie based authentication vulnerabilities often we see cookies a lot of times not only just the cookies jars but in the web application and a lot of time in security especially because token based authentication are not yet that much popular right so uh just a quick introduction as uh already given so i'm just skipping this particular part agenda for today is going to be introduction to cookies what they are for those who don't know the you know current uh scenario for this particular talk then we are going to talk about vulnerabilities in cookie based authentication some real life case studies around them and a quick wrap up

around that so this is a little cookie monster and we all know that we see such kind of cookies in our jar but in web application cookies are a lot more different we use cookie for a lot of purposes from authentication to tracking to just providing some information to third party websites or something like that so assume that what if there is no state in an application any user can see any data flowing right that would be a big mess so cookies were initially introduced to implement some authentication mechanism and introduce like what user has what kind of access right or what kind of information should be provided to what user so initially the authentication

application were using highly cookies these days there are tokens and some other stuff but cookies are still widely used by a lot of application so today we are going to slowly discuss about vulnerabilities in cookie based authentication and this is a quick mind map i will be quickly switching over my screen to a different one to you know take you through a totally uh new world of a mind map and we'll be presenting through that in just a second okay perfect okay so again uh there are a lot of vulnerabilities which you can you know identify in cookie based authentication starting from cross-site scripting now a common question a lot of people ask is how we can you know identify exploit uh

cross-site scripting in cookies right so this is a simple solution assume that the value of cookie parameter let's say name is reflected somewhere in the application now you try to change the value of this name parameter to access payload and it may result into a cross-site scripting now this is more of a self-accesses but you have to find a way to execute or inject cookies uh you know arbitrarily like for example using crlf injection you can try to add a cookie named name and with having a access payload and this may convert a self access into good accesses so today's talk is not just only about how you can exploit and report vulnerabilities in bug bounty but it is

more about how you approach a pen test right now moving forward there is another issue which is insufficient session management so as i initially discussed that cookies are heavily used for the session management and defining what user has what kind of access or even if they have some access or not right so in a lot of scenarios that session doesn't expire on a manual log out as well now this thing can be only on the server side so what what does it mean by only on server side is when you manually log out from an application it logs out from the ui but the session token or the session cookie doesn't expire at all okay and you can reuse this session

cookie to perform the actions as an authentic end user second thing is both server side and client side so as already discussed in the server side now talking about client side what happens is when you refresh the user interface or when you you know after some time you come back to the user interface you will find that okay user is already logged in even after you perform the logo option action okay now moving forward the session doesn't expire on password reset or change or the session might be having a long expiry these might be some of the other interesting issues related to session management when you use cookie based authentication now concurrent session is a very

conflicting term over here a lot of people say that concurrent session is a not a security vulnerability but it's more of you know a best practice or you can say it's a feature because a lot of application wants you to have multiple parallel session on multiple browsers or you can say multiple different ip addresses this is true totally true but in some situation the application also should have uh provide some options like a tracking system where you can see all your sessions or an option where you can log off from all the sessions so uh if the application is uh not having such kind of option content session might be availability as a best practice

now moving forward session fixation is another interesting term where attacker tricks the victim user to use a session identifier which is known to the attacker now what is the goal of this particular attack is to fix a session to the attacker and once attacker is logged into the user is logged into the attacker control session there might be some malicious payloads triggering or something like that which can again help an attacker to perform sensitive action from the victim side moving forward the previous privilege escalation can be one of the another interesting aspect of the cookie based authentications there are multiple type of people escalation like vertical horizontal let's talk about horizontal one first assume that the application

uses a multi-organization model right now cookies are used to define which organizer organization a user can access now after the cookies in order alter the cookies in order to access some other organization let's say there is an organization id called one two three four what if i can change the cookie uh having this organization item two three four five six and try to access some other organizations right now moving forward to the vertical escalation similarly let's say the role is determined by the cookies there's a cookie called roll and now the role says admin what if i change it to super admin and try to see if i can access the super admin user this can help me to elevate

the role of the user this has been seen a lot in the previous uh you know uh especially in the old application php based application where there are a lot of cookies and application utilize cookies for complete authentication as well as authorization metrics okay moving forward eye dots can also be found in cookies uh there are a lot of scenarios where you can simply temper with the various ideas just like we discussed in the previous collision scenario that let's say there is a user id going on say user underscore id is a cookie parameter and let's say there's a cookie in user id is one two three four and now you try to change it to two two

three four and see if you can access that particular user's data right now syncs could be security attributes this is more of a security best practice where uh you check for the various security flags missing like http only flag which protects if cookies cannot be stolen over the javascript or access payloads missing secure flag which helps you to you know basically helps cookies to prevent them by being hijacked or exploited over the http protocols same five flex infect plug basically helps you to prevent from cross-site request forgery attacks now moving forward there are some guessable and weak cookies as well so check if the cookies are not generated randomly by issuing multiple cookies and you you can use burp sequencer to

analyze all those cookies collectively and see if there is some kind of entropy or some kind of randomness and a lot of times you will see that some application are just using md5 uh hash cookies or just using base64 encoding for the rupees and something like that the scenarios are very rare in this particular case but you can you can you know always try your luck over that check if some known or weak cryptography is used as i already mentioned that they might use base64 encoding which can be easily decoded or forced moving forward session puzzling is more about when an application utilize the same session variable for the multiple purposes now assume that when you

perform a forget password action the application assigns you a session token right once the session token is assigned you can also try to use the same session token for performing an authenticated action now in this case an attacker can easily try to perform a session a forget password request for a victim user by just typing his email and get the session token these scenarios are very less seen in the real live scenario applications but you can always try again now this is a pretty interesting attack uh you can also use the cookies to uh perform local file inclusion kind of attacks let's say if your cookie is uh using some kind of server-side values let's say some particular file uh

let's say welcome.php or something like that uh to display a welcome banner now you can try to alter that particular file's name and try to see if you can basically uh perform a local file inclusion attack so let's say there's a welcome cookie called welcome equals to etc uh sorry welcome equals to welcome dot php now you can try to say dot slash dollar slash etc password and try to see if you can read the local user's file of pc password a fighting oracle attack is more of like a cryptographic attack uh there is a complete guide given over here so this is a very more uh more of a cryptographic attack so i'll uh leave it

to reading that particular guy for you similarly the cbc mac uh or ecb encryption is also one of the important thing which you can check in the cookies and try to see if uh these are using uh these kind of encryption which can be altered and which can be you know decrypted as well so moving forward uh to the authentication bypass in this scenario the cookies are not properly validated so what happens is you are trying to access a protected resource let's say profile.php or let's say some payments or php page by removing the cookies or directly hitting that particular end point and if you are able to access for that particular user it means that the

application is not validating the presence of the piece at all now parameter pollution is more about like assume that cookie utilize a parameter called user id to retrieve some sort of data for a specific user now you tried for the idol which we discussed earlier but it was not helping you out right now what you can do next is add an additional user id parameter and add a value with the victim users id for example as shown here that user id goes to attacker and user id equals to victim now three things can happen here is the application may retrieve data of the victim user the application may retrieve data both attacker and victim user and

the application is not vulnerable and doesn't return anything out of the attacker user score now sql injection can be one of the again interesting aspect when it comes to kps authentication if the cookies are somewhere used in the server side or performing some kind of server-side reading and uh you know kind of uh interaction with the database you can also try to inject some sort of sql queries and try to see if you can get something interesting out of that okay denial of service or cookie bombing so what happens is uh there are a different kind of server which accepts only a specific length of cookies in this particular attack what an attacker tries to do is to force the server to

process the cookies larger than the restricted cookie size defined by the server which may cause a denial of service attack there is a nice blog given over here i'll share the link to this particular mind map as well so you can read there is also a blog on the scene which you can also go and refer about this talking about mass assignment which is pretty much similar to the parameter collision attack where an attacker tried to inject multiple user ids and same user id parameter so in the parameter position what we saw is that we are using multiple user id and values let's say user id equals to attacker and user id equals to victim in

mass assignment we are trying to use user id course to victim and attacker or user id equals to attacker and victim like that now arbitrary cookie injection is something like an attacker is trying to inject an arbitrary cookie in order to perform some interesting action uh this can be achieved using crlf injection okay and sometimes it can be used to escalate privileges or perform uh cross-site scripting as we discussed in the very first thing that if the cookie is vulnerable to cross-site scripting you can try to inject that particular cookie using the clf injection okay insecure deceleration let's say the application is using php which is uh also using the serialized objects in the cookie parameter right now you can

easily identify those serialized parameters by looking at the cookies and if the source code is available that's that's a very great thing right now if the cookies are using civilized objects try performing insecure distillation check in php it's called php object injection attack and this is pretty simple to exploit and can get you the remote code execution as well okay length violation is similar to the cookie mass bombing attack it may cause attack such as buffer overflows in the application now uh what we are trying to do in this cookie length violation attack is we are providing a cookie more than its assumed length let's say uh the application is accepting only one zero to four uh

length of the cookie but we are providing less of 10 000 length of the movie and try to see if we can perform any kind of denial of service or kind of overload the buffer for the game session donation is again a conflicting attack uh where this particular block says that you donate your session to the victim user which is again less probable you have to rely upon some attacks like uh crl of attack crf injection or something like that in order to use your session token and donate it to the victim user now this attack is more helpful when the application is having some some sort of self-stored cross-site scripting and you want to convert them

into good stored process scripting where you can uh try to trick a victim to use attacker session and then further once the victim is logged into attacker session the cross-site scripting payload will execute and perform sensitive action on victim system or something like that sensitive data stored in the cookies so a lot of time some pi information such as email address mobile number some database or something like that could be stored in the uh personally like in the cookies now these pa information or other sensitive information should not be stored in the cookies especially in a plain or easily decodable decryptable form right especially when it comes to the healthcare or some similar industries where the sensitive data is the utmost

priority in the concern the application has to make sure that such kind of data should not be stored in the companies now as i already mentioned that this information usually includes email get update mobile address ssn etc okay so this more of concludes my talk on the keyboard authentication