Padding Oracle Attacks arise due to a vulnerability in the decryption validation process of Cipher-Block Chaining (CBC) encrypted messages. This is not a new cryptographic exploit; the first publicly released description of the attack was published back in 2002. However, given a significant percentage of web clients still support unsafe cipher modes, the technique, as well as adaptations of and extensions to the original methodology, persist.
In general, ciphers are created either on a bit-by-bit basis (stream cipher) or in blocks of a set size (e.g. CBC). When messages are sent with CBC mode encryption, they are divided into blocks of X bytes length, with each block XORed with the outcome of the preceding stage. The padding term referenced in the attack name refers to the cryptographic practice of adding bytes to the beginning, middle or end of a cleartext block as a way of either obfuscating the inherent predictability of message formats (e.g. “Dear Sir” or “Best Regards”) or filling out the block when the plaintext message isn’t divisible by the block size.
In the case of Padding Oracle Attacks, a malicious actor exploits the verifiable padding data at the end of the block by continually sending specially crafted messages against the cipher and relying on the error messages returned to determine the correctness of the messages. The attacker takes advantage of the PKCS#7 padding standard, throwing up to 256 combinations for each byte - byte by byte - until the correct padding is reached.
Fundamentally, the attack targets the weaknesses caused due to leaks from the bytes that make up the block, even though the block cipher itself is considered secure as a whole.
A successful Padding Oracle Attack can result in the plaintext corresponding to any block of ciphertext being recovered by an attacker, plaintext that can include information like passwords, cookies and other authentication tokens to be leveraged to gain complete access to the web application, compromising the confidentiality, integrity and availability of the service.
The attack and its various iterations affect Internet browsers, websites and web frameworks: it is critical and widespread. In fact, university researchers behind a study published in 2019 found close to 100 TLS Padding Oracle Attack variations in the wild in just 2019 alone.
Since Padding Oracle Attacks exploit a fundamental weakness in the structure of a mechanism, the cipher block, which underpins a significant portion of our digital world, preventing it from being leveraged by malicious actors is a high priority… and also a difficult goal to achieve if developers and administrators aren’t keeping up with and implementing evolved versions of standards and frameworks resilient to the attack method.
For example, TLS no longer supports the problematic CBC mode due to the most recent version’s adoption of Authenticated Encryption with Additional Data (AEAD) modes, thus preventing Oracle Padding in this particular instance. However, there are numerous other transport standards and web frameworks affected: ASP.NET / SSL / IPSEC, etc., thus ensuring the impact of Oracle Padding Attacks will be felt for some time yet!
The following outlines a number of measures that developers and administrators must be aware of and implement where feasible to mitigate the associated risk.
Encrypt-then-MAC i.e. using Message Authentication Code after encrypting information to generate the ciphertext, must be adhered to for ciphertext integrity.
In this way the attacker loses the ability to forge arbitrary ciphertext and thus to use the web application as an oracle because messages that fail to pass the integrity check are simply not decrypted.
In applications performing CBC decryption without the functionality to authenticate, developers should consider:
- Conducting decryption in a manner wherein the decryption method is unable to verify / extract padding.
- Implementing monitoring functions to detect large volumes of invalid messages arriving in a short period of time, keeping in mind that this too can be bypassed by attackers if they space out there attack times and volumes.
Verify that known insecure block modes (i.e. ECB, etc.) and padding modes (i.e. PKCS#1 v1.5, etc.) are not used. Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.