Are Padding Oracles still a concern?


August 05, 2016

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.

In 1998 Daniel Bleichenbacher first demonstrated a practical adaptive chosen-ciphertext attack. Four years later in 2002 Serge Vaudenay presented the very first practical padding oracle attack. Since that time notable vulnerabilities belonging to this category were also discovered, e.g. CVE-2013-0169 (Lucky13) and CVE-2014-3566 (POODLE), 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.

Refresher

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”.

Source: https://capec.mitre.org/data/definitions/463.html

For readers who would like to refresh information about the padding oracles, please refer to the following materials:

Problem persists

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
OpenSSL 5b8fa431ae8eb5a18ba913494119e394230d4b70

70428eada9bc4cf31424d723d1f992baffeb0dfb

cf6da05304d554aaa885151451aa4ecaa977e601

4aac102f75b517bdb56b1bcfd0a856052d559f6e

294d1e36c2495ff00e697c9ff622856d3114f14f

2acc020b770920657a169bf6be4ff12b254255e6

5b0b0e98cec653ae1e65e2251c3e0fc273945df5

ee60d9fb282030be3f25e951b86d74d8f2dd1bdd

2016-06-16

2016-04-17

2014-10-15

2014-09-05

2014-08-29

2013-01-08

2003-02-19

2001-09-20

CVE-2016-2107

CVE-2014-3566

CVE-2013-0169

CVE-2003-078

LibreSSL 118c98d2419ce7ec79c96e673dca5cfab4694102

http://www.openbsd.org/57.html

2016-05-04

CVE-2016-2107

BoringSSL 1634a334955ac07d4ee2c13a2efb420d4a406961

0aa0767340baf925bda4804882aab0cb974b2d26

e14dcc45e879807422c0497c7b6a4dcb92ad2a54

7d0a1d680c92c2ca6ebf12b45f5517b085c8abfb

2015-12-01

2014-07-24

2014-07-18

2014-06-20

mbed TLS (f.k.a. PolarSSL) 27290daf3b92b841159d7b23f71251fee5ea6c1e

6c329901142b5ed4bb8ac45b58efc0946a238bd4

8804f69d46ef5cb5fad403f4df8e14725966443d

e47b34bdc8507b63758402f69e7623d11dfb6984

4582999be608c9794d4518ae336b265084db9f93

2013-11-30

2013-10-27

2013-02-28

2013-02-27

2013-01-03

Botan ea07110c86c7ae2601e71dd3c1134873ccfd721f 2015-10-16 CVE-2015-7824
OWASP ESAPI https://code.google.com/p/owasp-esapi-java/issues/detail?id=120 2010-05-03 CVE-2010-3300

 

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

The 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).

Technical Challenge

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 competitions.
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://162.243.166.18/ .

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!

2 thoughts on “Are Padding Oracles still a concern?

  1. orangelemur

    I got the flag from the /oracle directory but I must be missing something because I don’t see anything pointing to flag2. Also what does SecurusGlobal{sha1(FLAG1 + FLAG2)} even mean? Sorry if noob question, maybe is clear once getting flag2?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *