Re: [FD] [RT-SA-2016-001] Padding Oracle in Apache mod_session_crypto
Hi Erik, Thanks for backing me up on a number of things. Only one response below. > > In light of that, there's > > nothing particularly wrong with using CBC, if it is implemented well. > > At least, using it is not *more* wrong than using OFB, CFB, or CTR > > That is wrong. CBC mode allows attacks such as "Sweet32" > (https://sweet32.info/), which is not possible with CTR mode. The site you linked mentioned 64bit block ciphers are vulnerable, even in CTR mode. Obviously the birthday "paradox" applies. Regardless of how right or wrong you are about Sweet32, this far from the most important thing *implementors* should be worried about. Obviously if they start with AES, then the birthday paradox issues are vastly reduced. Any new system should be avoiding the likes of 3DES, Blowfish, etc. So it seems moot. On the flip side, tell me what the impact is of these two scenarios where a developer follows *some* of our advice: (A) They use AES in CBC mode and apply an HMAC to the cipehrtext. They actually validate that HMAC before decrypting. However, they fail to use a unique IV for every message. (B) They use AES in CTR mode and apply an HMAC to the cipehrtext. They actually validate that HMAC before decrypting. However, they fail to use a unique IV for every message. Which is worse? Obviously (B) fails pretty catastrophically. (A) is not great, but at least the plaintext isn't nearly as easy to expose (usually only minor block-level information leaks). In the real world I see these kinds of mistakes all of the time. So be careful of steering people toward a mode that doesn't degrade as gracefully when developers make mistakes. They invariably will do so, unless they've spent as much time with crypto as you and I. tim PS- And to re-iterate, we shouldn't ask them to use any particular cipher mode, but instead to use something off the shelf. ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] [RT-SA-2016-001] Padding Oracle in Apache mod_session_crypto
Hi, On Tue, Dec 27, 2016 at 09:01:49AM -0800, Tim wrote: > [...] > > > > But there still are people who use CBC... > > [...] > > All traditional modes that lack integrity protection are vulnerable to > chosen-ciphertext attacks in these kinds of scenarios. > [...] > All traditional modes need a MAC or similar integrity protection. That is correct. > In light of that, there's > nothing particularly wrong with using CBC, if it is implemented well. > At least, using it is not *more* wrong than using OFB, CFB, or CTR That is wrong. CBC mode allows attacks such as "Sweet32" (https://sweet32.info/), which is not possible with CTR mode. > without integrity protection. Correct again, but too simple minded. Any encryption without integrity protection does not provide confidentiality against an active attacker. Using the wrong mode with a block cipher can render authentication irrelevant in attacks on confidentiality. > [...] > We should instead be pointing developers in > the direction of using something off-the-shelf [...]. > Much less room for error. That is sound advice. In addition, broken ciphers, modes, and protocols still implemented for backwards compatibility should not be used. Thanks, Erik -- [A]pplied cryptography mostly sucks. -- Green's law of applied cryptography ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] [RT-SA-2016-001] Padding Oracle in Apache mod_session_crypto
> > res = apr_crypto_passphrase(, , passphrase, > > strlen(passphrase), (unsigned char *) (), sizeof(apr_uuid_t), > > *cipher, APR_MODE_CBC, 1, 4096, f, r->pool); > > CBC. Again. > > The earliest mention of CFB which I know is dated 1989. > The earliest mention of CTR which I know is dated 1990-ies. > > But there still are people who use CBC... > > Please, PLEASE, PPLAASSSE don't use it. Instead, use either > Blowfish in CFB mode or at least Rijndael (AES) in CTR (or GCM) > mode - both are available, for example, in the OpenSSL library. All traditional modes that lack integrity protection are vulnerable to chosen-ciphertext attacks in these kinds of scenarios. CFB isn't immune and CTR is catastrophically weak. All traditional modes need a MAC or similar integrity protection. In light of that, there's nothing particularly wrong with using CBC, if it is implemented well. At least, using it is not *more* wrong than using OFB, CFB, or CTR without integrity protection. GCM is fine if the implementation is sound and the IVs never repeat, but there are pitfalls. We should instead be pointing developers in the direction of using something off-the-shelf, such as libsodium. Much less room for error. tim ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] [RT-SA-2016-001] Padding Oracle in Apache mod_session_crypto
On 2016-12-23 13:28:33 +0100, RedTeam Pentesting GmbH wrote: > res = apr_crypto_passphrase(, , passphrase, > strlen(passphrase), (unsigned char *) (), sizeof(apr_uuid_t), > *cipher, APR_MODE_CBC, 1, 4096, f, r->pool); CBC. Again. The earliest mention of CFB which I know is dated 1989. The earliest mention of CTR which I know is dated 1990-ies. But there still are people who use CBC... Please, PLEASE, PPLAASSSE don't use it. Instead, use either Blowfish in CFB mode or at least Rijndael (AES) in CTR (or GCM) mode - both are available, for example, in the OpenSSL library. -- Alexey V. Vissarionov aka Gremlin from Kremlin GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 pgpt5NEaPky3h.pgp Description: PGP signature ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] [RT-SA-2016-001] Padding Oracle in Apache mod_session_crypto
Advisory: Padding Oracle in Apache mod_session_crypto
During a penetration test, RedTeam Pentesting discovered a Padding
Oracle vulnerability in mod_session_crypto of the Apache web server.
This vulnerability can be exploited to decrypt the session data and even
encrypt attacker-specified data.
Details
===
Product: Apache HTTP Server mod_session_crypto
Affected Versions: 2.3 to 2.5
Fixed Versions: 2.4.25
Vulnerability Type: Padding Oracle
Security Risk: high
Vendor URL: https://httpd.apache.org/docs/trunk/mod/mod_session_crypto.html
Vendor Status: fixed version released
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2016-001.txt
Advisory Status: published
CVE: CVE-2016-0736
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0736
Introduction
The module mod_session_crypto of the Apache HTTP Server can be used in
conjunction with the modules mod_session and mod_session_cookie to store
session data in an encrypted cookie within the users' browsers. This
avoids server-side session state so that incoming HTTP requests can be
easily distributed amongst a number of application web servers which do
not need to share session state.
More Details
The module mod_session_crypto uses symmetric cryptography to encrypt and
decrypt session data and uses mod_session to store the encrypted data in
a cookie (usually called "session") within the user's browser. The
decrypted session is then made available to the application in an
environment variable (in case of a CGI script) or in a custom HTTP
request header. The application can add a custom HTTP response header
(usually "X-Replace-Session") which instructs the HTTP server to replace
the session's content with the value of the header. Detailed
instructions to set up mod_session and mod_session_crypto can be found
in the documentation:
https://httpd.apache.org/docs/2.4/mod/mod_session.html#basicexamples
The module mod_session_crypto is configured to use either 3DES or AES
with various key sizes, defaulting to AES256. Encryption is handled by
the function "encrypt_string":
modules/session/mod_session_crypto.c
/**
* Encrypt the string given as per the current config.
*
* Returns APR_SUCCESS if successful.
*/
static apr_status_t encrypt_string(request_rec * r, const apr_crypto_t *f,
session_crypto_dir_conf *dconf, const char *in, char **out)
{
[...]
apr_crypto_key_t *key = NULL;
[...]
const unsigned char *iv = NULL;
[...]
/* use a uuid as a salt value, and prepend it to our result */
apr_uuid_get();
[...]
res = apr_crypto_passphrase(, , passphrase,
strlen(passphrase),
(unsigned char *) (), sizeof(apr_uuid_t),
*cipher, APR_MODE_CBC, 1, 4096, f, r->pool);
[...]
res = apr_crypto_block_encrypt_init(, , key, , r->pool);
[...]
res = apr_crypto_block_encrypt(, , (unsigned char *)in,
strlen(in), block);
[...]
res = apr_crypto_block_encrypt_finish(encrypt + encryptlen, , block);
[...]
/* prepend the salt and the iv to the result */
combined = apr_palloc(r->pool, ivSize + encryptlen + sizeof(apr_uuid_t));
memcpy(combined, , sizeof(apr_uuid_t));
memcpy(combined + sizeof(apr_uuid_t), iv, ivSize);
memcpy(combined + sizeof(apr_uuid_t) + ivSize, encrypt, encryptlen);
/* base64 encode the result */
base64 = apr_palloc(r->pool, apr_base64_encode_len(ivSize + encryptlen +
sizeof(apr_uuid_t) + 1)
* sizeof(char));
[...]
return res;
}
The source code shows that an encryption key is derived from the
configured password and a randomly chosen salt by calling the function
"apr_crypto_passphrase". This function internally uses PBKDF2 to derive
the key. The data is then encrypted and the salt and IV prepended to the
encrypted data. Before returning to the caller, the result is encoded as
base64.
This procedure does not guarantee integrity of the ciphertext, so the
Apache module is unable to detect whether a session sent back to the
server has been tampered with. Depending on the application this often
means that attackers are able to exploit a Padding Oracle vulnerability.
This allows decrypting the session and encrypting arbitrary data chosen
by the attacker.
Proof of Concept
The vulnerability can be reproduced as follows. First, the modules
mod_session, mod_session_crypto and mod_session_cookie are enabled and
configured:
Session On
SessionEnv On
SessionCookieName session path=/
SessionHeader X-Replace-Session
SessionCryptoPassphrase RedTeam
In addition, CGI scripts are enabled for a folder and the following CGI
script is saved as "status.rb" and is made
