Crypto MAC by-pass makes default ESAPI symmetric encrytion using CBC mode vulnerable to padding oracle attacks

[GoogleCodeExporter]

NOTE: Originally posted to OWASP ESAPI-Dev mailing list on 2013/08/23 by 
Philippe Arteau <philippe.arteau@gmail.com>.

What steps will reproduce the problem?
1. Add the cipher mode OFB" to the test version of ESAPI.properties to the 
property Encryptor.cipher_modes.additional_allowed so it reads:
        Encryptor.cipher_modes.additional_allowed=CBC,OFB
2. Execute the attached JUnit test.
3. Observe that the encryption succeeds.

What is the expected output?

    An EncryptionException should be thrown with an exception message of:
           "Decryption failed; see logs for details."

What do you see instead?
    The subsequent decryption attempt succeeds.

Original issue reported on code.google.com by kevin.w.wall@gmail.com on 26 Aug 2013 at 4:15

Attachments:

• SignatureByPassTest.java

[GoogleCodeExporter]

Note that Philippe Arteau's original post to the ESAPI-DEV mailing list 
mentioned two conditions. Condition #1 had to do with tampering with the MAC 
length in the generated serialized ciphertext and setting that length to zero.  
That is what this issue and the attached file, is about. An exploit for 
condition #2 as mentioned in his email post has not yet been developed. I am 
looking at that issue as well, but that will require design changes and some 
may be substantial otherwise it may introduce other errors.

Original comment by kevin.w.wall@gmail.com on 26 Aug 2013 at 4:51

[GoogleCodeExporter]

Let's create a second issue to address the second condition and prepare a patch 
release to address the vulnerability this week. I will run the release - Kevin 
can you verify the patch resolves the problem and that all tests pass.

Original comment by chrisisbeef on 26 Aug 2013 at 5:39

[GoogleCodeExporter]

**Additional Precautions**

Once a fix is made available and you have downloaded and installed it, you may 
wish to take the extra precaution of generating all new symmetric encryption 
keys that you have been using, including the Encryptor.MasterKey in your 
ESAPI.properties file if you have been using that. (Of course, if you plan to 
do so, if you have persisted any encrypted data using the old keys, you will 
first want to decrypt that data so it could be re-encrypted with the 
replacement keys just as if you were doing a key change operation.)

The reason that you _might_ want to consider taking this additonal precaution 
is that this vulnerability could lead to a padding oracle attack against your 
system using the ESAPI 2.0 symmetric encryption--but only if you were using CBC 
mode and a MAC, which are the default configuration; if you were using CBC mode 
and no MAC and/or the deprecated encrypt() / decrypt() methods from ESAPI 1.4 
then you were already screwed before this vulnerability. As Duong and Rizzo 
showed us, it is possible to use a padding oracle attack to eventually divulge 
the secret encryption key.

Of course, because doing all this will take quite a bit of effort, especially 
if you have persisted encrypted data encrypted with the keys that need 
replaced, there is a way to tell if anyone has attempted this attack against 
your system.

Assuming that you have have ESAPI logging enabled and have kept those logs 
around, I would recommend that you look through those logs for this string that 
will be in the log file should this vulnerability be attempted against your 
system:

    Cannot validate MAC as it was never computed and stored. Decryption result may be garbage even when decryption succeeds.

If your logs can be trusted (i.e., not writtable by everyone and their 
brother), then you should be safe if you do NOT see this string in your ESAPI 
logs. (Note that if you do see this string in your ESAPI logs, it is not proof 
positive that this vulnerability was attempted. It could also result of someone 
calling the deprecated Encryptor.encrypt(String) with a different key than was 
used to encrypt the plaintext. That is, someone could just have tried the wrong 
Encryptor.MasterKey.)

It is advised that you look back through your ESAPI logs at least back to 
August 21, 2013 which is when Philippe Arteau first posted an announcement of 
this vulnerability to the public.

Original comment by kevin.w.wall@gmail.com on 28 Aug 2013 at 4:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here's the latest updated JUnit test which should test this vulnerability 
out-of-the-box without requiring tweaks to your ESAPI.properties file. Just 
drop it in your
<ESAPI-root>\src\test\java\org\owasp\esapi\crypto folder and run your JUnit 
tests as normal. If it passes, you're good. If the test fails, your version of 
ESAPI is vulnerable.

Original comment by kevin.w.wall@gmail.com on 3 Sep 2013 at 2:56

Attachments:

• ESAPICryptoMACByPassTest.java

[GoogleCodeExporter]

Fixed in ESAPI release 2.1.0, released on 2013/09/02. See release notes for 
additional details.

Original comment by kevin.w.wall@gmail.com on 3 Sep 2013 at 2:58

• Changed state: Verified

[GoogleCodeExporter]

Note: We've applied for a CVE identifier for this issue. I will add reference 
it here as well as update the release notes once we have it.

Original comment by kevin.w.wall@gmail.com on 3 Sep 2013 at 3:05

[GoogleCodeExporter]

Changing label 'Type-Vulnerability' to 'Type-Defect' so that everyone can now 
view this Google Issue.

Original comment by kevin.w.wall@gmail.com on 3 Sep 2013 at 3:08

• Added labels: Type-Defect
• Removed labels: Type-Vulnerability

[GoogleCodeExporter]

Mitre has assigned the CVE identifier "CVE-2013-5679" for this issue. More 
details to be provided later.

Original comment by kevin.w.wall@gmail.com on 4 Sep 2013 at 5:39

[GoogleCodeExporter]

Just to let you know the CVE noted above 
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5960) lists the affects 
version as before 2.1.1 , which is incorrect because there is no 2.1.1 and 
according this this ticket which shows it was resolved in 2.1.0.  This will 
show up as a false positive on security scans, so yo may want to get it updated

Original comment by dsmo...@gmail.com on 10 Mar 2015 at 2:32

[GoogleCodeExporter]

Yes, I am aware of this. In fact, David Dillard at Symantec pointed this out to 
me and asked me to inform Mitre, which I did on Feb 9, 2015. I have had no 
responses to my email so I not sure who else to try to contact to get this 
resolved.

Does anyone have any email contacts at Mitre regarding CVEs other than
<cve-assign@mitre.org>?

Original comment by kevin.w.wall@gmail.com on 11 Mar 2015 at 1:09

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I thought the CVE-2013-5960 was never fixed. As it would require a redesign.

Summary : 
CVE-2013-5679 => MAC can be set to null
CVE-2013-5960 => It is possible to alter metadata of the ciphertext **

** The real exploitability was proven by Synacktiv team 
http://www.synacktiv.fr/ressources/synacktiv_owasp_esapi_hmac_bypass.pdf

@Kevin : Am I correct ?

Original comment by philippe...@gmail.com on 11 Mar 2015 at 4:12

[GoogleCodeExporter]

Yes, correct. BTW, these Google Issues are only historical artifacts at this 
point. The ESAPI issues have moved to GitHub (specifically under 
https://github.com/ESAPI/esapi-java-legacy). Please don't add further comments 
here; if you want to note something for this issue, please note it at 
https://github.com/ESAPI/esapi-java-legacy/issues/312 (There was minor 
renumbering of some of the issues when they were migrated; that is not 
something that is going to be fixed, but I think the offset is '6' so should be 
easy enough to figure out the issue # in GitHub.)

I will make a comment regarding the status of CVE-2013-5960 on the ESAPI-Dev 
mailing list. Subject will have CVE-2013-5960 in the Subject.

Original comment by kevin.w.wall@gmail.com on 12 Mar 2015 at 4:20