Blackbox Cookie Testing — How I Cracked The Admin’s Cookie
IF I HAD 8 HOURS TO MUNCH ON COOKIES, I WOULD SPEND 6 HOURS T̶A̶S̶T̶I̶N̶G̶ TESTING THEM. — The Cookie Monster
In today's world, we depend a lot on Web Applications whether it would be to watch Netflix, buy something off of Amazon, or catch up with friends or share pictures on social media. But how do these websites and web servers know who we say we are? After all the HTTP/S protocol is a “stateless” protocol which means each time a visitor retrieves a webpage, the client opens a separate connection to the Web server and the server does not keep any record of the previous client requests.
Meet Browser Cookies
A browser cookie is bits of text that is stored on your web browser when you visit a website. This helps the webserver keep track of the user that visits the page. When you log into a website say for instance facebook.com, the server sends your browser a session cookie. If someone could guess your session’s cookie or steal it they will be able to access your profile without needing your password.
On my most recent web application security testing, I had created two user accounts. My intention was to test the application for IDOR vulnerabilities or Username Collisions. At first glance, the session cookie did not look suspicious. The first user account session’s cookie looked like this
Hmm, the cookie looks complex and secure we should trust it and stop there right?
Luckily during my web application testing, I noticed a pattern with the session cookies while creating multiple accounts.
The first account created (username: test1):
The second account created (username: test2):
The third account I created while testing for admin username collisions looked like this
(username: admin ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ’ ):
The cookie this time looked very different then the first two
There is a long pattern of 2000 2000 2000 2000 2000…. Could that be the spaces I added in the username?
I was curious and created another user account with 16 A’s
Username: : aaaaaaaaaaaaaaaa
Cookie: 0102DF1350BAD9C2D908FEDF2DC1D2DBC2D9080010 6100 6100 6100 6100 6100 6100 6100 6100 6100 6100 6100 6100 6100 6100 6100 6100 00012F00FF
WHAT? I freaked out. At this moment I realized 6100 represents the character A!
Could I modify the cookie to have it use admin? So I put the theory to the test. I created another user account this time with 12 B’s and I get back
Cookie: 0102AAC39811DAC2D908FEAADD092ADCC2D908000C 6400 6400 6400 6400 6400 6400 6400 6400 6400 6400 6400 6400 00012F00FF
6400 repeated 12 times! So we know now that the cookie holds the username and it's encoded with these 4 digits. I repeat the process and create 3 other accounts and come up with the values for admin (a d m i n = 6100 6400 D006 6900 6E00)
I log back into the test1 account user and this time I modify the cookie slightly adding “6100 6400 D006 6900 6E00” which is admin. The cookie looks like
0102 7B459BBEDCC2D908FE7B5F0CD7DEC2D9080005 6100 6400 6D00 6900 6E00 00012F00FF
I refreshed the webpage and I get an error... Ok maybe there needed to be more adjustments and so I look back at the cookie and remodify it slightly this time to
0100 7B459BBEDCC2D908FE7B5F0CD7DEC2D9080005 6100 6400 6D00 6900 6E00 00012F00FF
changing the beginning of the cookie from 0102 to 0100 and it worked! I was able to browse the page as the website's admin user. I owned the website!
With this level of access, I have full control of the web app and I could attempt to upload a webshell but that's beyond the scope of this article.
1-When testing cookies create multiple accounts and look for a pattern in the cookie.
2- Just because it looks complex does not mean it is.
3- If you have a theory always put it to the test no matter how crazy the idea sounds