The very fact this article came to be implies the answer – yes, they are. Readers who are interested in knowing the rationale behind this statement are encouraged to continue reading.
The main motivation behind writing this article was a padding oracle vulnerability ( CVE-2016-2107 ) found on May 2016 in a popular OpenSSL cryptographic toolkit. Authors of this article decided that it is a great occasion to revisit this area and to refresh information about the padding oracles.
first demonstrated a practical
adaptive chosen-ciphertext attack
. Four years later in 2002
presented the very first practical
padding oracle attack
. Since that time notable vulnerabilities belonging to this category were also discovered, e.g.
, to name the most recognized ones.
After some time, some people even started to believe that this type of attack is no longer a problem (i.e. no longer considered a threat in real-life). Despite this and similar opinions, we can observe that new padding oracle vulnerabilities are continuously discovered by security researchers and 14 years after the first practical attack was presented, they still pose a very real security threat.
What is padding oracle? What can happen if someone finds this vulnerability in my application and will be able to exploit it? How can I test, identify and avoid this type of attack? Let’s address these and other questions in the following sections.
First things first. Let’s refresh on what the padding oracle attack is. The definition according to MITRE states:
“An attacker is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext.
In addition to performing decryption, an attacker is also able to produce valid ciphertexts
(i.e., perform encryption) by using the padding oracle, all without knowing the encryption key”.
For readers who would like to refresh information about the padding oracles, please refer to the following materials:
- MITRE CAPEC-463 – Padding Oracle Crypto Attack
- Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS #1
- Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS…
- Practical Padding Oracle Attacks
- Making sure crypto stays insecure
- Padding oracles and the decline of CBC-mode cipher suites
The best example that padding oracles are a tricky beast to harness is to have a glimpse at how others are struggling to get things right:
|Name||URL / GIT Commit||Date||CVE|
|mbed TLS (f.k.a. PolarSSL)||
Table 1 – Sample vulnerabilities and code changes in popular software that relates to padding oracle attack.
Based on the information from the table it is clear that it is very hard to address the problem of
a Bleichenbacher’s, Vaudenay’s and side-channel attacks. Therefore, it is important to test for these kinds of vulnerabilities even if they are considered very rare or having been addressed a long time ago.
This is especially true for applications that use symmetric key cryptography, are developed
in-house and/or weren’t tested before.
It should also be noted that data in the table contains information only about the most well-known cryptography toolkits/libraries. Surely, it is not complete and doesn’t contain information about vulnerabilities that were identified in individual software products. Nevertheless, the amount of software that relies on the aforementioned toolkits/libraries is tremendous and should give an impression of the scale of the problem.
Testing for Padding Oracles
OWASP Testing Guide
provides good guidance on how to test for the padding oracle vulnerabilities and can be found in the section entitled
Testing for Padding Oracle
Foremost, the guide describes how to identify common places in the application where potential padding oracle vulnerability can be present. Secondly, what other conditions have to be met in order to exploit the vulnerability (i.e. non-uniform error messages, timing discrepancies etc.)?
Across the years various tools have been developed in order to assist testers, researchers and developers in the process of identifying, confirming and fixing the padding oracles. The most renowned ones belonging to this category are:
Dos and Don’ts
Please note that most of the recommendations included below will apply to software developers but some of them also apply to regular users. The below recommendations, at the time of this article writing, should greatly reduce the risk of being affected by padding oracles vulnerabilities but also should prevent many other threats as well.
- Use well known and tested software from trusted vendors.
- Keep your software up to date (there is no excuse not to do so).
- For symmetric key cryptography use a GCM or OCB mode of operation
- The decryption routines should be executed in a constant time manner.
- The error conditions occurring in the decryption routines should produce uniform error messages.
- Preferably use an open source software if it relies on the cryptography in some way.
- Don’t use SSL3 , TLS 1.0 protocols which are now deprecated and were proven to be insecure.
- Don’t use CBC mode of operation for symmetric key cryptography without using Message Authentication Code ( MAC ).
- Don’t write and don’t use custom cryptography software (i.e. in 99% cases that will be true).
In order to provide some hands-on experience in identifying, understanding and exploiting padding oracle vulnerabilities, we have prepared a technical challenge for our readers. It is analogous in form and approach to challenges that can be found during
Capture the Flag
CTF challenges that are prepared by the security enthusiasts and professionals aim to verify, improve and teach technical skills for anyone who is interested in that field.
The vulnerable application can be found at the following URL – http://18.104.22.168/ .
In the second blogpost we will publish a walkthrough for this challenge along with the names of individuals who will manage to complete it. Good luck and enjoy!