Introduction
About Me:
I just finished my coop at Xanthus Security and now work as a junior penetration tester. I am always curious as to how applications work – and how they break. I spend the majority of my work and personal time doing offensive security testing while sharping my skills with new exploitation techniques in hand to detect, exploit, and mitigate vulnerabilities in applications.
About the Vulnerability:
Cryptographic failures feature second in the OWASP Top 10, and they are very common issues nowadays. Vulnerabilities in this category often stem from broken or outdated algorithms, improper implementation, poor key or session management leading to exposure of sensitive data or introducing logic flaws that attackers can exploit.
In this blog post, I want to show why you can’t just “encrypt stuff” and assume it’s secure. While it might resemble a PortSwigger-style lab walkthrough at first glance, this is based on a real-world assessment where cryptographic misuse led to full admin account takeover. It’s not just theory- it’s the kind of bug that can hide in production systems if it’s not looked at closely.
Description
A cryptographic failure vulnerability in the application’s stay-logged-in cookie allows an authenticated standard user to forge a valid cookie for the administrator account. This flaw permits privilege escalation by bypassing access controls and gaining unauthorized admin access.
Proof Of Concept
First, let’s log into the application as a low privileged user and select the “Stay Logged In” checkbox.
After a successful login, the server issues two cookies: a regular session cookie and a stay-logged-in cookie.
To confirm that the user lacks administrative privileges and the access control is enforced on the admin interface, the standard-level user attempts to access the /admin page, the application responds with an error message stating, “Admin interface only available if logged in as an administrator.”
The web application allows users to post comments on a particular post, including name, email address, and website. Submitting a comment with an invalid email triggers a server error message saying, “Invalid email address: [user input].”
Application error:
By intercepting the POST request with Burpsuite, two key observations are made: the POST request to /post/comment returns a 302 redirect with a Set-Cookie header named notification containing an encrypted value.
And, the subsequent GET request to /post?postid=# sends this notification cookie back. The server then decrypts this cookie value and displays the invalid email message inside the response.
This behaviour suggests that the application encrypts the user input from the email field and stores it in the notification cookie during the POST request. Later, the application decrypts this value when processing the GET request and displays it back to the user, indicating a symmetric encryption and decryption process in place for the notification feature.
To test this theory, replace the encrypted stay-logged-in cookie value and set it as the notification cookie. Upon decryption, the application reveals a plaintext string in the format username:timestamp. This confirms that the encrypted cookie value contains the username and a timestamp, and suggests that it may be possible to forge a valid admin cookie by modifying the username component.
Let’s attempts to forge an admin cookie by inputting administrator:timestamp as the email address in the comment form.
The application encrypts this input and later decrypts it in the notification, showing the message “Invalid email address: administrator:timestamp.” This confirms the ability to inject arbitrary plaintext, encrypt it, and have it correctly decrypted by the application.
However, the prefix “Invalid email address: ” must be removed because a legitimate stay-logged-in cookie is simply in the format username:timestamp.
The prefix consists of 23 characters, remove these 23 bytes directly from the encrypted cookie value.
First attempt to forge a stay-logged-in cookie:
This involves URL decoding the cookie, base64 decoding it to raw binary, deleting 23 bytes, then base64 encoding and URL encoding it back.
Result:
When the modified value is set as the stay-logged-in cookie, the application throws an error: “Input length must be multiple of 16 when decrypting with padded cipher.” This error reveals that the encryption algorithm uses a block cipher (likely AES in CBC mode) that requires the ciphertext length to be a multiple of the 16-byte block size.
Second attempt to forge a stay-logged-in cookie:
This time let’s remove the entire prefix in multiples of 16 bytes, 32 bytes must be deleted (two full blocks). Since the prefix is 23 bytes, adds nine filler characters (e.g., “xxxxxxxxx”) before the “administrator:timestamp” string to make the prefix length 32 bytes.
The modified string is encrypted by the application, then the corresponding 32 bytes are removed from the decoded encrypted cookie. The value is then re-encoded and set as the notification cookie.
The crafted encrypted cookie successfully decrypts to the string “administrator:timestamp” which matches the legitimate stay-logged-in cookie format for the admin user. Replacing the stay-logged-in cookie with the forged admin token and revisiting the /admin page grants full administrative access.
Conclusion
This vulnerability highlights the critical risks of improper cryptographic implementation in session management. By allowing encrypted tokens to be manipulated and forged without proper integrity checks, the application exposes itself to severe privilege escalation attacks.
Resources
10, O. T. (n.d.). A02:2021 – Cryptographic Failures. A02 Cryptographic Failures – OWASP Top 10:2021. https://owasp.org/Top10/A02_2021-Cryptographic_Failures/
Academy, P. (n.d.). Lab: Authentication bypass via encryption oracle. Web Security Academy. https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-authentication-bypass-via-encryption-oracle