Authentication bypass via encryption oracle
The Authentication Bypass via Encryption Oracle vulnerability demonstrates how cryptographic functionality can be abused when an application exposes both encryption and decryption behavior to the client. In this lab, the application uses encrypted cookies to store authentication and notification data. Although the encryption itself may be technically strong, the application leaks enough information through different endpoints to act as an encryption oracle and a decryption oracle, allowing an attacker to forge valid authentication tokens and impersonate another user.
The attack begins by logging in as a normal user with the “Stay logged in” option enabled. After authentication, the server issues a stay-logged-in cookie. By inspecting the request and response in Burp Suite, it becomes clear that this cookie is encrypted rather than plain text. This suggests that the application uses the cookie to persist authentication state securely. At this point, the attacker does not know the format of the plaintext inside the cookie.
Next, the attacker explores another application feature: posting comments on a blog post. When submitting a comment with an invalid email address, the application responds by setting a notification cookie before redirecting back to the post page. For example, submitting:
POST /post/comment
with an invalid email such as:
test
results in an error message on the redirected page:
Invalid email address: test
This reveals an important detail: the application is storing the error message in encrypted form inside the notification cookie, then decrypting it later and reflecting it in the response. This means the application is effectively exposing an encryption oracle and decryption oracle.
The attacker sends both requests to Burp Repeater:
POST /post/comment
and:
GET /post?postId=x
The POST request can be used as an encryption oracle because arbitrary input in the email parameter gets encrypted and returned inside the Set-Cookie header as the notification cookie. The GET request can be used as a decryption oracle because arbitrary ciphertext placed in the notification cookie is decrypted and reflected back in the error message.
To understand the structure of the authentication cookie, the attacker copies the encrypted stay-logged-in cookie and pastes it into the notification cookie of the decrypt request. When the request is sent, the server decrypts it and reflects the plaintext in the response. Instead of an email-related error, the attacker sees something like:
wiener:1598530205184
This reveals that the plaintext format of the authentication cookie is:
username:timestamp
The timestamp is copied for later use.
The next step is to forge an administrator cookie. In the encrypt request, the attacker changes the email parameter to:
administrator:1598530205184
and sends it. The response includes a new encrypted notification cookie. However, when decrypting it, the attacker notices that the plaintext contains a prefix automatically added by the application:
Invalid email address: administrator:1598530205184
This means the attacker cannot use the ciphertext directly because the authentication system expects only:
administrator:1598530205184
without the prefix.
To manipulate the ciphertext, the attacker sends it to Burp Decoder, URL-decodes it, and Base64-decodes it to raw bytes. By testing and observing server responses, the attacker determines that the application uses a block cipher with a 16-byte block size, likely AES in ECB or CBC mode.
The prefix:
Invalid email address:
is 23 bytes long. Since blocks are processed in 16-byte chunks, simply removing 23 bytes would corrupt the ciphertext structure. Therefore, the attacker needs to align the desired plaintext so the removable portion occupies full blocks.
To do this, the attacker pads the beginning of the intended plaintext with 9 extra characters:
xxxxxxxxxadministrator:1598530205184
The reason is:
23 bytes (prefix) + 9 bytes (padding) = 32 bytes
32 bytes equals exactly two full 16-byte blocks.
The attacker encrypts this input using the POST request and obtains new ciphertext. After decoding it in Burp Decoder, the first **32 bytes** of ciphertext can safely be removed. The remaining ciphertext now decrypts to:
```text
administrator:1598530205184
without the unwanted prefix.
The attacker verifies this by placing the modified ciphertext into the notification cookie in the decrypt request. The response confirms that the decrypted output is correct.
Now the forged ciphertext can be used as a valid authentication token. From Burp Proxy History, the attacker sends a request like:
GET /
to Burp Repeater. The normal session cookie is removed entirely, and the forged ciphertext is placed into the stay-logged-in cookie.
When the request is sent, the server decrypts the forged cookie and treats it as a valid authentication token for:
administrator
The attacker is now logged in as the administrator.
At this point, the application displays administrative functionality, including access to:
/admin
From there, the attacker can browse to:
/admin/delete?username=carlos
to delete the user and solve the lab.
The root cause of this vulnerability is the unsafe exposure of cryptographic operations through application features. The POST request provides arbitrary encryption of attacker-controlled input, while the GET request provides arbitrary decryption and plaintext reflection. Together, these create a full cryptographic oracle attack surface.
Additionally, the application fails to use authenticated encryption or message integrity checks. Even if the ciphertext is modified, the server still attempts to decrypt and trust the result. Secure implementations should use authenticated encryption modes such as AES-GCM or apply HMAC validation to prevent tampering.
This vulnerability demonstrates that strong encryption alone is not enough. If an application exposes encryption and decryption behavior in a predictable way, attackers can use the application itself to forge tokens, bypass authentication, and escalate privileges.
Comments