Open Server Sadness Layer | TechSNAP 256

Posted on: March 3, 2016

OpenSSL issues a major security advisory, we break down the important details, then go in depth on the real world impact of these flaws.

Plus some great storage and networking question, a packed round up & much, much more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

OpenSSL issues major security advisory

OpenSSL has released versions 1.0.2g and 1.0.1s to address a number of vulnerabilities:
CVE-2016-0800 (DROWN): HIGH: Cross-protocol attack on TLS using SSLv2
CVE-2016-0703: HIGH: Divide-and-conquer session key recovery in SSLv2
CVE-2016-0702 (CacheBleed): LOW: Side channel attack on modular exponentiation
CVE-2016-0704: MODERATE: Bleichenbacher oracle in SSLv2
CVE-2016-0705: LOW: Double-free in DSA code
CVE-2016-0798: LOW: Memory leak in SRP database lookups
CVE-2016-0797: LOW: BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption
CVE-2016-0799: LOW: Fix memory issues in BIO_*printf functions
As per previous announcements, support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date
Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates.

As many as one third of all HTTPS sites vulnerable to DROWN

“More than 11 million websites and e-mail services protected by the transport layer security protocol are vulnerable to a newly discovered, low-cost attack that decrypts sensitive communications in a matter of hours and in some cases almost immediately”
The researchers have dubbed the latest vulnerability DROWN, short for Decrypting RSA with Obsolete and Weakened eNcryption
DROWN Attack
“The attack works against TLS-protected communications that rely on the RSA cryptosystem when the key is exposed even indirectly through SSLv2, a TLS precursor that was retired almost two decades ago because of crippling weaknesses. The vulnerability allows an attacker to decrypt an intercepted TLS connection by repeatedly using SSLv2 to make connections to a server. In the process, the attacker learns a few bits of information about the encryption key each time. While many security experts believed the removal of SSLv2 support from browser and e-mail clients prevented abuse of the legacy protocol, some misconfigured TLS implementations still tacitly support the legacy protocol when an end-user computer specifically requests its use.”
LibreSSL is not affected by DROWN because support for SSLv2 was removed long ago
“Recent scans of the Internet at large show that more than 5.9 million Web servers, comprising 17 percent of all HTTPS-protected machines, directly support SSLv2. The same scans reveal that at least 936,000 TLS-protected e-mail servers also support the insecure protocol. That’s a troubling finding, given widely repeated advice that SSLv2—short for secure sockets layer version 2—be disabled. More troubling still, even when a server doesn’t allow SSLv2 connections, it may still be susceptible to attack if the underlying RSA key pair is reused on a separate server that does support the old protocol.”
So even a locked down and tightened up server can be compromised, if a less secure server shares the same certificate
I have seen this with my bank, when I changed settings in my browser to be more restrictive on what TLS versions and algorithms were used, a specific subdomain of the bank’s site would no longer load properly
“A website, for instance, that forbids SSLv2 may still be vulnerable if its key is used on an e-mail server that allows SSLv2”
How many people think to adjust the settings on their email server to protect their web server?
TLS security hit a new low last May with the discovery of Logjam, a vulnerability caused by deliberately weakened cryptography that allowed eavesdroppers to read and modify data passing through tens of thousands of Web and e-mail servers
“It’s pretty practical because if you know you want to target certain websites and they’re vulnerable, you can pretty much set up shop and the next thing you know you have all of these secure connections, the passwords, and everything else,” Matt Green, a cryptography expert at Johns Hopkins University who has read the research paper, told Ars. “It’s amazing to me that we keep finding one or two of these [vulnerabilities] per year for protocols that are this old. This shouldn’t keep happening. It kind of makes me feel like we’re not doing our jobs.”
“Tuesday’s OpenSSL updates make it impossible for ordinary end users to enable SSLv2 without declaring explicit intent to do so. The patch also removes support for extremely weak 1990s-era ciphers that are key to making DROWN attacks work. The weak ciphers were added to all SSL and TLS versions prior to 2000 as part of US government’s export regulations”
“Microsoft’s IIS versions 7.0 and on and versions 3.13 and above of the NSS crypto library all have SSLv2 disabled by default. Anyone using older versions of either of these programs should upgrade right away.”
“The most general DROWN attack exploits 1990s-era cryptography that uses extremely weak 40-bit symmetric encryption so software would comply with export restrictions. The attacker captures roughly 1,000 RSA key exchanges made between an end user and a vulnerable TLS server, and the connections can use any version of the SSL or TLS protocols, including the current TLS 1.2. The attacker then uses the intercepted RSA ciphertexts to initiate several thousand SSLv2 connection attempts that include an instruction for the server to use the 40-bit cipher. The attacker then compares the ciphertext to all the 240 possibilities”
“Decrypting the TLS connection requires just 250 computations, a task that in a worst-case scenario Amazon’s EC2 service can perform in eight hours for just $440. The researchers devised an alternate decryption method that uses a cluster of graphics cards and takes 18 hours”
“The researchers also devised a significantly more severe version of DROWN that works against servers running versions of OpenSSL that haven’t been patched since March 2015. It allows attackers to decrypt the “premaster secret” almost instantly. An attacker can use the technique to perform man-in-the-middle attacks that cryptographically impersonate a vulnerable server. Scans performed by the researchers show that a significant percentage of servers vulnerable to DROWN are also susceptible to this more severe version of the exploit. The finding suggests that a surprisingly large number of OpenSSL users have yet to install the March 2015 update, which unknowingly fixed the vulnerabilities that make the more severe attack possible.”
“DROWN is an extension of what cryptographers call the 1998 Bleichenbacher attack, named after Daniel Bleichenbacher, the Swiss cryptographer who discovered the underlying weakness in the PKCS#1 v1 encoding function. While considered a seminal exploit for the mathematical insight it provided, it wasn’t considered especially practical, because it required attackers to make hundreds of thousands or millions of connections to the victim server to compromise a single session key.”
“Ironically, some of the Bleichenbacher countermeasures built into the SSLv2 provided precisely the type of data required to carry out the type of so-called “padding oracle” attack that Bleichenbacher discovered. The Bleichenbacher defenses, it turned out, provided its own oracle that exposed TLS version 1.0 and later exposed it to plaintext recovery attacks. The DROWN research is notable not only because it requires many fewer queries to the server, but also because its cross-protocol nature allows attackers to exploit the SSLv2 weakness to defeat the separate TLS specification. The DROWN findings are also significant because they were the first to identify the ineffectiveness of the Bleichenbacher countermeasures, some two decades after they were added to SSLv2.”
Additional Coverage: CSO Online — Latest attack against TLS shows the pitfalls of intentionally weakening encryption
There is actually a second major exploit that is fixed by this recent OpenSSL update
While this one requires local access to the machine, and is much harder to pull off, the results could be quite disastrous
CacheBleed: A Timing Attack on OpenSSL Constant Time RSA
“CacheBleed is a side-channel attack that exploits information leaks through cache-bank conflicts in Intel processors. By detecting cache-bank conflicts via minute timing variations, we are able to recover information about victim processes running on the same machine. Our attack is able to recover both 2048-bit and 4096-bit RSA secret keys from OpenSSL 1.0.2f running on Intel Sandy Bridge processors after observing only 16,000 secret-key operations (decryption, signatures). This is despite the fact that OpenSSL’s RSA implementation was carefully designed to be constant time in order to protect against cache-based (and other) side-channel attacks.”
“While the possibility of an attack based on cache-bank conflicts has long been speculated, this is the first practical demonstration of such an attack. Intel’s technical documentation describes cache-bank conflicts as early as 2004. However, these were not widely thought to be exploitable, and as a consequence common cryptographic software developers have not implemented countermeasures to this attack.”
“We believe that all Sandy Bridge processors are vulnerable. Earlier microarchitectures, such as Nehalem and Core 2 may be vulnerable as well. Our attack code does not work on Intel Haswell processors, where, apparently, cache-bank conflicts are no longer an issue”
“Cache timing attacks exploit timing differences between accessing cached vs. non-cached data. Since accessing cached data is faster, a program can check if its data is cached by measuring the time it takes to access it.”
“In one form of a cache timing attack, the attacker fills the cache with its own data. When a victim that uses the same cache accesses data, the victim’s data is brought into the cache. Because the cache size is finite, loading the victim’s data into the cache forces some of the attacker’s data out of a cache. The attacker then checks which sections of its data remain in the cache, deducing from this information what parts of the victim’s memory were accessed.”
“To facilitate access to the cache and to allow concurrent access to the L1 cache, cache lines are divided into multiple cache banks. On the processor we tested, there are 16 banks, each four bytes wide. The cache uses bits 2-5 of the address to determine the bank that a memory location uses. In the Sandy Bridge microarchitectures, the cache can handle concurrent accesses to different cache banks, however it cannot handle multiple concurrent accesses to the same cache bank. A cache-bank conflict occurs when multiple requests to access memory in the same bank are issued concurrently. In the case of a conflict, one of the conflicting requests is served immediately, whereas other requests are delayed until the cache bank is available.”
“The main operation OpenSSL performs when decrypting or signing using RSA is modular exponentiation. That is, it calculates cd mod n where d is the private key. To compute a modular exponentiation, OpenSSL repeatedly performs five squaring operations followed by one multiplication. The multiplier in the multiplications is one of 32 possible values. All the numbers involved in these operations are half the size of the key. That is, for a 2048 bit RSA key, the numbers are 1024 bits long.”
“Knowing which multiplier is used in each multiplication reveals the secret exponent and with it the private key. Past cache timing attacks against OpenSSL and GnuPG recover the multipliers by monitoring the cache lines in which the multipliers are stored. To protect against such attacks, OpenSSL stores the data of several multipliers in each cache line, ensuring that all of the cache lines are used in each multiplication. However, the multipliers are not spread evenly across cache banks. Instead, they are divided into 8 bins, each bin spanning two cache banks. More specifically, multipliers 0, 8, 16 and 24 only use bin 0, which spans cache banks 0 and 1. Multipliers 1, 9, 17, and 25 only use bin 1, which spans cache banks 2 and 3, etc. As a result of this memory layout, each multiplication accesses two cache banks slightly more than it accesses the other cache banks. For example, in the case of 4096-bit RSA, the multiplication makes 128 additional accesses to the multiplier’s cache banks.”
“Recovering a 4096 RSA key from 60% of the key material requires around two CPU hours and can be accomplished on a high-end server in less than 3 minutes.”