Walkthrough : https://youtu.be/E9EZ3AXqHSE
Code Repository : https://github.com/HaydenMcNally/ISEC-603-Padding-Oracle
History of the Padding Oracle Attack
Padding Oracle attacks, also known as Vaudenay attacks was originally published in 2002 by Serge Vaudenay. The term ‘padding oracle’ appeared in literature in 2002, after Serge Vaudenay’s attack on the CBC mode decryption used within symmetric block ciphers. The earliest well-known attack that used a padding oracle attack was the Bliechenbacher’s attack in 1998. This attacks the RSA with PKCS #1 v1.5 padding. In brief, a padding oracle attack is an attack that uses the padding validation of a cryptographic message to decrypt the ciphertext. This padding oracle responds to queries about whether a message is correctly padded or not, ultimately revealing the cipher text upon correct identification of the padding without using knowledge of the secret key.
POODLE – A Padding Oracle on Downgraded Legacy Encryption (POODLE) attack was discovered by Bodo Meiller, Thai Duong, and Krzysztof Kotowicz from the Google Security Team. This vulnerability was publicly announced in October 2014 in a paper called ‘This POODLE Bites: exploiting the SSL 3.0 Fallback’. ws.
The Padding Oracle Vulnerability
The padding oracle attack relies on having a “padding oracle” who freely responds to queries about how correctly padded a message is or not using Cipher-block chaining (CBC). CBC ensures that no two blocks, even if they contain identical plain-text, will encrypt to the same ciphertext. It does so by mixing the ciphertext from the previous round into the plaintext of the upcoming round using the XOR operator.
This information could be directly given, or leaked through a side-channel.
The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more serious attacks. The error message may be created in different ways:
- self-generated: the source code explicitly constructs the error message and delivers it
- externally-generated: the external environment, such as a language interpreter, handles the error and constructs its own message, whose contents are not under direct control by the programmer
An attacker may use the contents of error messages to help launch another, more focused attack. For example, an attempt to exploit a path traversal weakness as seen in (CWE-22) might yield the full pathname of the installed application. In turn, this could be used to select the proper number of “..” sequences to navigate to the targeted file. An attack using SQL injection as seen in (CWE-89) might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.
The Padding Oracle on Downgraded Legacy Encryption (POODLE) is another type of the Padding oracle attack but POODLE exploits a vulnerability in the SSL 3.0 protocol (CVE-2014-3566). This vulnerability lets an attacker eavesdrop on communication encrypted using SSLv3.
To perform a typical POODLE attack and steal a web session cookie, the attacker does the following:
- The attacker tricks the victim’s browser into running JavaScript code that lets the attacker perform the attack.
- The attacker’s JavaScript code tricks the user browser into sending multiple legitimate requests to the server. These requests include the session cookie.
- The JavaScript code modifies the connection URL (adding extra characters) so that the length of the data sent to the server is a multiple of the block size (for example, 8). This means that the last block will contain only padding (see the explanation above).
- The attacker knows which blocks of data contain the session cookie. For example, the data may have 10 blocks and the attacker knows that the third and fourth blocks contain the session cookie value.
- The attacker copies the entire third block to the last block and sends it to the server many times, changing something in the connection URL every time so that the MAC is different.
- After at most 256 times, the message will be accepted. This means that the last byte of the third block, after decryption, will be the number 07, which signifies correct padding.
- Now the attacker knows the decrypted last byte and they can combine it with previous blocks using XOR operations to obtain the real last byte of the third block.
- The attacker can then make the connection URL one byte longer and repeat the steps above to get the next piece of the cookie. And then repeat again for the fourth block of data.
- If the cookie length is 16, the attacker will know the cookie after no more than 4096 requests, which takes at most a few minutes.
After Math and How the Vulnerability was Fixed
A variety of techniques have been formulated that aim to enhance network security, be it within systems and platforms or within network protocols, in particular in light of padding oracle vulnerabilities:
Encrypt-Then-MAC (EtM) Approach: This is a method that first authenticates the data and then encrypts it. This step aims to conceal padding errors that allow attackers to pinpoint the plaintext using error messages. Such principles have been adopted in many TLS protocols, which effectively reduces the risk of padding based attacks[1].
he image above illustrates the Encrypt-Then-MAC (EtM) approach:
Plaintext: This is the original unencrypted data that needs to be securely transmitted.
Encryption: The plaintext is first encrypted using a symmetric encryption algorithm (e.g., AES). The process involves a secret key (Key1) that ensures only authorized parties with the correct key can decrypt the ciphertext.
Ciphertext: The output of the encryption process is the encrypted data.
Hash Function (Message Authentication Code – MAC): After encryption, a MAC is generated using a cryptographic hash function to ensure data integrity and authenticity. This MAC is computed using the ciphertext and a second secret key (Key2). The MAC provides a way to detect if the data has been tampered with during transmission.
Output (Ciphertext + MAC): The final transmitted message includes both the ciphertext (encrypted data) and the MAC. Upon receiving this, the recipient will:
- Verify the MAC to ensure the data hasn’t been altered.
- Decrypt the ciphertext to retrieve the original plaintext.
Standardized Error Responses: To prevent attackers from exploiting padding error messages, systems began masking or generalizing error responses. This approach involves avoiding exposing the information that can be utilized based on weaknesses[2]. By sending uniform responses for all decryption errors, systems avoid revealing specific padding failures that attackers could exploit. Such measures have been taken in ASP.NET by Microsoft hence removing the attacker’s “oracle.”
Upgrading Protocols and Disabling SSL 3.0: This is most useful against the POODLE (Padding Oracle on Downgraded Legacy Encryption) attacks, and it involves disabling SSL 3.0 across systems and platforms as it does not offer any advantage in terms of padding in newer protocols such as TLS[3]. Practically, organizations were presented with the idea of specifying a TLS-only policy which when complied with represents a more secure connection over padding downgrades from SSL 3.0.
Strict Transport Security: HTTP Strict Transport Security (HSTS) prevents the forced downgrades by mandating that browsers only connect to servers via secure TLS connections. HSTS reduces the risk of protocol downgrades, ensuring that even if an attacker attempts to force SSL 3.0, the browser will reject it and require a secure connection.
The image above explains how HTTP Strict Transport Security (HSTS) works:
Initial Request: When a client (e.g., a browser) tries to connect to a website using an insecure protocol (http://), the request reaches the server.
Server Response: If the server has HSTS enabled, it instructs the browser to always use secure connections (https://) through a special HTTP header (Strict-Transport-Security).
Future Requests: Once the browser receives this directive, it automatically converts all future requests to secure HTTPS, even if the user attempts to access the website via an unsecured link.
Purpose:
- This prevents potential attacks where an attacker forces a downgrade to an insecure HTTP connection or intercepts a session to steal sensitive data.
- HSTS ensures that users interact with the server securely, enhancing trust and data protection.
Discussion Questions
Considering the POODLE attack, how does exploiting SSL 3.0 illustrate the importance of securing network protocols?
What are the key differences between Encrypt-Then-MAC (EtM) and earlier cryptographic practices in mitigating padding oracle attacks?
What is an edge case you need to pay attention to when you implement the padding oracle attack?
References
- https://eprint.iacr.org/2000/025
- https://learn.microsoft.com/en-us/security-updates/SecurityAdvisories/2010/2416728?redirectedfrom=MSDN
- https://security.googleblog.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
- https://en.wikipedia.org/wiki/Authenticated_encryption
- https://www.keycdn.com/support/http-strict-transport-security
- chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf
- https://www.skullsecurity.org/2013/padding-oracle-attacks-in-depth
- https://www.cisa.gov/news-events/alerts/2014/10/17/ssl-30-protocol-vulnerability-and-poodle-attack
- https://www.acunetix.com/blog/web-security-zone/what-is-poodle-attack
- https://en.wikipedia.org/wiki/Padding_oracle_attack
- https://cwe.mitre.org/data/definitions/209.html
- https://www.acunetix.com/blog/web-security-zone/what-is-poodle-attack/
