Authentication bypass via encryption oracle

Description

This lab contains a logic flaw that exposes an encryption oracle to users.

Reproduction and proof of concept

  1. Log in with wiener:peter and the Stay logged in option enabled and post a comment. Study the corresponding requests and responses using Burp’s manual testing tools. Observe that the stay-logged-in cookie is encrypted.

  2. Submitting a comment using an invalid email address, the response sets an encrypted notification cookie before redirecting to the blog post.

  3. The error message reflects the input from the email parameter in cleartext:

Business logic

This must have been decrypted from the notification cookie. Send the POST /post/comment and the subsequent GET /post?postId=x request (containing the notification cookie) to Burp Repeater.

  1. In Repeater, it is possible to use the email parameter of the POST request to encrypt arbitrary data and reflect the corresponding ciphertext in the Set-Cookie header. Likewise, it is possible to use the notification cookie in the GET request to decrypt arbitrary ciphertext and reflect the output in the error message. For simplicity, double-click the tab for each request and rename the tabs encrypt and decrypt respectively.

  2. In the decrypt request, copy the stay-logged-in cookie and paste it into the notification cookie. Send the request. Instead of the error message, the response now contains the decrypted stay-logged-in cookie, for example:

Business logic

This reveals that the cookie should be in the format username:timestamp. Copy the timestamp to the clipboard.

  1. Go to the encrypt request and change the email parameter to administrator:timestamp. Send the request and then copy the new notification cookie from the response.

  2. Decrypt this new cookie and observe that the 23-character "Invalid email address: " prefix (23 bytes) is automatically added to any value passed in using the email parameter.

Business logic

Send the notification cookie to Burp Decoder.

  1. In Decoder, URL-decode and Base64-decode the cookie.

  2. In Burp Repeater, switch to the message editor’s Hex tab. Select the first 23 bytes, then right-click and select Delete selected bytes.

  3. Re-encode the data and copy the result into the notification cookie of the decrypt request. When sending the request, an error message indicates that a block-based encryption algorithm is used and that the input length must be a multiple of 16. Pad the "Invalid email address: " prefix with enough bytes so that the number of bytes you will remove is a multiple of 16.

  4. In Burp Repeater, go back to the encrypt request and add 9 characters (23 + 9 = 32) to the start of the intended cookie value, for example:

Business logic

Encrypt this input and use the decrypt request to test that it can be successfully decrypted.

  1. Send the new ciphertext to Decoder, then URL and Base64-decode it. This time, delete 32 bytes from the start of the data.

Business logic

Re-encode the data and paste it into the notification parameter in the decrypt request.

Business logic

Check the response to confirm that your input was successfully decrypted and, crucially, no longer contains the "Invalid email address: " prefix. You should only see administrator:your-timestamp.

Business logic

  1. From the proxy history, send the GET / request to Burp Repeater. Delete the session cookie entirely, and replace the stay-logged-in cookie with the ciphertext of the self-made cookie. Send the request. You are now logged in as the administrator and have access to the admin panel.

Business logic

  1. Using Burp Repeater, browse to /admin and notice the option for deleting users. Browse to /admin/delete?username=carlos to solve the lab.

Business logic

Exploitability

An attacker will need to log in to wiener:peter; exploit the flaw to gain access to the admin panel and delete Carlos.