Vulnerability Description
A team of researchers, including Tripwire VERT’s Craig Young has announced that TLS stacks from at least 8 different vendors are vulnerable to a well-known 19-year-old protocol flaw. The problem is that these implementations allow an attacker to identify whether or not a chosen ciphertext has proper PKCS#1 v1.5 padding when decrypted. This allows for a classic Bleichenbacher attack on RSA due to the following properties:
- RSA is a malleable encryption such that an attacker can “multiply” ciphertext
- PKCS#1 v1.5 is not plaintext aware; an attacker can produce valid ciphertext with high probability without knowledge of the plaintext.
In 1998, Daniel Bleichenbacher published an algorithm for exploiting this with an adaptive chosen ciphertext attack. Bleichenbacher argued for a plaintext-aware cryptosystem such as PKCS#1 v2, but TLS designers instead decided to prescribe a series of complicated countermeasures to avoid leaking error details. The current vulnerabilities are the result of a general failure to properly implement or test these countermeasures in popular products.
Exposure and Impact
Successful exploitation of the vulnerability allows an attacker to perform cryptographic operations using the private key configured on the vulnerable server. In practice, this means that an attacker could decrypt previously recorded sessions established with an RSA key exchange. An attacker capable of carrying out a signature attack within the duration of a TLS handshake timeout could become a full man-in-the-middle by downgrading connections to use RSA encryption key exchange modes as described in DROWN.
Remediation & Mitigation
The most complete remediation is to disable RSA encryption-based key exchange modes where possible. This guarantees protection against known and unknown vulnerabilities with a minimal impact on HTTPS client compatibility. Several vendors have released patches or support notes as indicated in the references section below and tracked on https://robotattack.org
Detection
The underlying vulnerability presents itself with several unique behaviors indicative of how exploitable the system is. Readily exploitable systems are termed as having a “Strong Oracle,” while systems with a “Weak Oracle” will take on average considerably longer to exploit. Tripwire released coverage for CVE-2017-6168 in ASPL-753 with generic coverage scheduled for ASPL-756.
