Bleichenbacher & DROWN
In addition to attacks targeting padding in symmetric encryption algorithms, there are also attacks that specifically target the asymmetric encryption algorithm RSA.
Bleichenbacher Attack
Bleichenbacher attacks target RSA encryption combined with PKCS#1 padding. PKCS#1 padding is often used with RSA to ensure non-deterministic encryption, meaning that encrypting the same plaintext twice yields different ciphertexts by adding random padding before encryption.
This attack works by sending numerous adapted ciphertexts to a web server. The server decrypts these ciphertexts and checks the conformity of the PKCS#1 padding. If the server leaks information about whether the padding was valid, an attacker can deduce information about the original unmodified plaintext. By repeatedly performing these steps, an attacker can eventually gather enough information to fully reconstruct the plaintext.
In the context of TLS 1.2, Bleichenbacher attacks are effective only when a cipher suite utilizing RSA as the key exchange algorithm is chosen. Furthermore, a flaw in the web server that leaks padding validity (e.g., through verbose error messages or a timing side channel) is required. If these conditions are met, a Bleichenbacher attack can lead to the complete leakage of the session key, allowing an attacker to decrypt the entire communication.
DROWN Attack
DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) is a specific type of Bleichenbacher attack that exploits a vulnerability in SSL 2.0. To successfully execute this attack, an attacker needs to intercept a large number of connections. Subsequently, the attacker conducts a Bleichenbacher attack against an SSL 2.0 server using specially crafted handshake messages. SSL 2.0, intentionally designed with weak "export-grade" encryption algorithms to comply with government regulations in the 1990s, is particularly susceptible. Modern hardware has significantly improved, making it possible to break these weak encryption algorithms without extensive resources. Additionally, DROWN leverages bugs in old OpenSSL implementations to accelerate the decryption process.
However, DROWN specifically targets SSL 2.0, which has been deprecated for a long time. While web servers should no longer support SSL 2.0, encountering an improperly configured server with SSL 2.0 enabled can still occur during real-world engagements.
Tools & Prevention
To execute a Bleichenbacher attack, you first need to install TLS-Breaker:
sudo apt install maven
git clone https://github.com/tls-attacker/TLS-Breaker
cd TLS-Breaker/
mvn clean install -DskipTests=trueVerify your Java installation as TLS-Breaker requires JDK 11 (e.g., /usr/lib/jvm/java-1.11.0-openjdk-amd64):
Once TLS-Breaker is set up, you can run the Bleichenbacher detection tool against a target server. If you have captured TLS traffic in a pcap file, you can extract the encrypted premaster secret from the Client Key Exchange packet in Wireshark. After obtaining the encrypted premaster secret, you can feed it to the bleichenbacher-1.0.1.jar tool using the -encrypted_premaster_secret option:
The tool will output the padded premaster secret. You can then remove the padding to obtain the unpadded premaster secret by stripping everything up to the TLS version (e.g., 0303 for TLS 1.2 in hex) using a command like:
After obtaining the premaster secret and the client's random nonce (found in the ClientHello message in Wireshark), a key file can be created with the format PMS_CLIENT_RANDOM <client_random> <premaster_secret>. This key file can then be used in Wireshark to decrypt the TLS traffic.
Prevention:
DROWN can be prevented by disabling SSL 2.0. Most modern operating systems' cryptographic libraries do not support SSL 2.0 by default, making DROWN vulnerabilities rare in the wild. Bleichenbacher attacks can be prevented by ensuring that padding information is not revealed to the TLS client. Keeping web servers up-to-date with patches is sufficient to protect against plain Bleichenbacher attacks.
Decrypting Traffic with Wireshark
After obtaining the premaster secret (e.g., 030346e31fe27a7ef62f88826f00d95c3e8665d8ac719614369543b077ecac37c112e1313cfa8ecf9fb86c29ed89abc4) and the client's random key (e.g., 9443e40e20140ebf9e3c83f268f73f8de9c564f9eb493c8f6ad7bfe1ddf672bc, found in the ClientHello packet in Wireshark's Random field), you can decrypt captured TLS traffic. Create a key file with the format PMS_CLIENT_RANDOM <CLIENT_RANDOM> <PREMASTER_SECRET>:
Then, import this key file into Wireshark by navigating to Edit -> Preferences -> Protocols -> TLS and specifying the path to your KeyFile under (Pre)-Master-Secret log filename. This will decrypt the TLS packets, allowing you to inspect the original HTTP traffic.
Last updated