201704-01

Unauthenticated encryption in CBC mode

Background

Encryption provides confidentiality, but not authentication over the plaintext message. This means we can decrypt encrypted data, but we can’t be sure that it hasn’t been tampered with. This is particularly important in some encryption modes, as changing something in the ciphertext may be possible without breaking decryption. This means an attacker may change a ciphertext in a way that results in a modified plaintext instead of a decryption failure. Cipher Block Chaining (CBC) mode of operation and other unauthenticated modes of symmetric encryption algorithms are affected by this issue.

The ability to modify the ciphertext affecting the result of decryption allows an attacker to recover the original plaintext corresponding to a certain ciphertext by using a Padding Oracle Attack.

Description

The SimpleSAML\Utils\Crypto class provides a couple of methods to encrypt and decrypt data, aesEncrypt() and aesDecrypt(), respectively. They encrypt and decrypt data using the AES algorithm in CBC mode, which does not provide authentication of the ciphertext, and is therefore vulnerable to Padding Oracle Attacks. Neither function provides authentication itself on top of the encryption algorithm, running them vulnerable too.

Those functions are used when we need to send an HTTP POST request via an insecure channel (that is, when HTTPS is not used) after authentication. The typical use case is when the SAML IdP is accessible via HTTPS, but an SP is not. In such case, the browser will display a warning or even block the request because we are sending data obtained from a secure channel, through an insecure one. We avoid the issue by encrypting the session identifier so that we can redirect to a page that is available via plain HTTP without compromising the user’s session by sending it in the clear. This page decrypts the session identifier to recover the current state and uses that to send the final response to the service provider via the insecure channel. The web browser will not complain because we are not sending an HTTP POST request to an HTTP URL, but redirecting there instead. When we perform the HTTP POST request to send a SAML response to the service provider, both the origin of the request and its target are using plain HTTP.

The issue that affects the encryption and decryption methods in the SimpleSAML\Utils\Crypto class makes it possible for an attacker eavesdropping the network to capture the encrypted session identifier, and mount a Padding Oracle Attack to recover that identifier and try to use it to impersonate the user. Bear in mind that the attacker will be able to impersonate the user towards the service regardless of this vulnerability, due to the lack of HTTPS protection in the service provider. In order to use the session identifier just obtained to access other services, the attacker would need though the authentication token, that is not encrypted together with the session ID and is also sent using the same configuration for the session cookie. This means if session cookies are set to be sent only for HTTPS requests, an attacker will be unable to get the authentication token anyway and the session ID obtained by this attack is useless without it.

This particular use case is not possible by default, as it requires setting explicitly the enable.http_post configuration option in the config.php file.

Affected versions

All SimpleSAMLphp versions before and including 1.14.12.

Impact

The issue presented here makes all the data encrypted with SimpleSAML\Utils\Crypto::aesEncrypt() vulnerable to different kinds of attacks that could allow a third party to recover the original data or to modify the encrypted data so that it decrypts into a different plaintext chosen by the attacker.

Beside any uses of those methods in third-party modules, SimpleSAMLphp only uses them to protect the session identifier when replying to non-HTTPS service providers. In such case, an attacker could already impersonate a user if those replies are captured, so this vulnerability doesn’t give any particular advantage without the ability to get the authentication token. However, an attacker could combine this attack with other attacks unknown to date to recover the authentication token too and be able to impersonate a user for every service available.

Even though SimpleSAMLphp is not vulnerable by default and those vulnerable instances (those with enable.http_post set to true) aren’t more vulnerable due to this than they already are because of the fact they are sending SAML responses through unprotected channels, other modules may be using these functions to encrypt and decrypt data, unaware of the issues described here, and posing unforeseeable security risks.

Therefore, it is recommended to upgrade to the latest version as soon as possible. We also recommend keeping the enable.http_post configuration option to false as it is set by default, and requiring all service providers and identity providers to enforce the use of HTTPS and restrict session cookies to be sent over secure channels with the session.cookie.secure configuration option set to true.

Resolution

Upgrade to the latest version.