The Padding Oracle attack is associated with Modern Symmetric(single key to encrypt/decrypt) Cryptographic systems that use a block cipher. Block ciphers work on encrypting fixed length group of bits called
blocks. To enhance security, block ciphers have added
modes of operation which support the repeated operation of the cipher across several blocks. Since the original plaintext is never of a fixed length
modes of operation employ padding algorithms to ensure all blocks have the same size. The attack relates to the implementation of the
Cipher-Block Chaining(CBC) mode of operation and a commonly used PKCS#7 padding scheme and how implementations respond during validation. By iteratively supplying stolen ciphertext concatenated with carefully chosen ciphertext an attacker can work their way towards determining the original data based on receiving padding error or success message.
A Web Application or target vulnerable to Padding Oracle attacks ultimately exposes the confidentiality of their sensitive data. This may lead to account compromise, exposure of sensitive information, and potentially server compromise. A motivated attacker with patience and tools can decrypt sensitive data. Depending on the nature and sensitivity of the data this might lead to account compromise, leakage of sensitive information, and eventually server compromise.
Testing for Padding Oracle in Java
The testing goal for the attack is to determines if the target is vulnerable and not to attempt to decrypt the ciphertext. The broad strokes of this test can be summarized as:
- Determine that there is encrypted content traveling to the target.
- Determine that the target emits validation messages.
- Confirm that those validation messages occur on a variety of errors.
Since establishing that the target is leaking validation information is fundamental to the vulnerability the tester has to pay very close attention to the response of the server. This may go beyond error messages and include timing responses.
Recognize that input is encrypted. This is non trivial as some data in transit may be encoded (base64 for example). This requires potentially decoding the data and careful inspection to see if the data “appears” random.
Recognize blocks. If what you suspect is random data always appears as a combination of blocks (8 or 16) change the first block to all 0s, encode (if necessary), and resend being careful to notice if there are any changes in server behaviour, error messages, or timing. Keep incrementing (and encoding if necessary) the first block while watching server response.
Padding. As this incrementing continues eventually a request will be submitted with the wrong cipher value but the correct number of blocks. This should, if the target is vulnerable, produce a cipher error but not a padding error.
If the target fluctuates in error messages during this sequence then it is vulnerable to a Padding Oracle Attack.
Want to check your projects for free?
Initialized ciphers of CBC PKCS5Padding as outlined below,
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte cipherText = c.doFinal(plainText);
Must be changed to,
Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); c.init(Cipher.ENCRYPT_MODE, k, iv); byte cipherText = c.doFinal(plainText);
ThreatPost: Padding Oracle Crypto Attack Affect Millions of ASP.NET apps
Security researchers have developed an attack against the mechanism that ASP.NET web applications handle encrypted session cookies. The vulnerability could enable attackers to hijack online sessions.
Wikipedia: Padding Oracle Attack
Robert Heaton Blog: The Padding Oracle Attack
Crypto.StackExchange: How Does Padding Oracle Attack Work?
GitHub Luchob Repository: Padding Oracle Attack Demo
OWASP: Testing for Padding Oracle (OTG-CRYPST-002)
InfoSecInstitute: Padding Oracle Attack explanation
Troy Hunt: Fear, uncertainty and the padding oracle exploit in ASP.NET