Main Content

Heya - HollyGraceful here, I make all of this content in my spare time, like it? Please support me :)
You can donate via Bitcoin or Patreon!

TLS/SSL Vulnerabilities

“Which SSL ciphers should I disable?”

A client recently gave me a list of their supported ciphers and asked me which SSL ciphers they should disable – effectively looking for the most secure SSL ciphers they can use. Instead of the fast answer of “disable the insecure ones”, I thought I’d try and write up something useful.

So here’s a handy reference guide I’m working on. This has been time consuming to develop and no doubt will be added to over time. This isn’t intended to be read from start-to-finish, but is more of a handy SSL/TLS issue cheat-sheet.

Got a vulnerability to add, noticed an inaccuracy, got a new reference? Message me!

 

Vulnerabilities

DROWN

CVE-2016-0800, or Decrypting RSA with Obsolete and Weakened eNcryption (DROWN), is a vulnerability that affects servers still supporting SSLv2 or servers that share a private key with any other server that allows SSLv2 (even for other protocols such as email). It allows an attacker who has an effective man-in-the-middle to break the encryption of a TLS connection in under eight hours with a variant being achievable in one minute. The attack takes many hundreds of requests which can be achieved by the user visiting a load intensive application or alternatively being coerced in to visiting a site which can make a large number of cross-site requests. The target application can use any protocol suite including TLSv1.2 as long as the requirement for SSLv2 is also met, additionally RSA key exchange must be used. This issue can be combined with CVE-2015-3197 which is an OpenSSL vulnerability that allows SSLv2 connections to be made even in no SSLv2 ciphers are enabled.

References

https://drownattack.com/
https://drownattack.com/drown-attack-paper.pdf

 

CRIME

Compression Ratio Info-leak Made Easy (CRIME) is an attack against TLS/SSL, but it has a much smaller probability of exploitation. The authors of CRIME also wrote the BEAST attack. The attacker requires a man-in-the-middle connection and the ability to repeatedly inject predictable data whilst monitoring the resulting encrypted traffic. This could be achievable through Cross-site scripting attacks; JavaScript is not required and an attack could be possible with HTML Injection alone however it would be less efficient.

For CRIME to be possible the client and server must support compression of the request before encryption. TLS supports DEFLATE which is vulnerable, as is SPDY.

References
https://www.gracefulsecurity.com/crime-against-tls/

 

BEAST

Browser Exploit Against SSL/TLS (BEAST) is a practical attack was found to be possible against TLS v1.0 and SSLv3.0 (and below) when a block cipher is in use. Effectively an attacker is able to determine the Initialisation Vector utilised as part of the encryption process meaning that if a repeating pattern is evident in the plaintext then it will be evident in the ciphertext. However, it is of limited use an it is only possible to retrieve small pieces of data, such as session tokens. The attacker must be able to man-in-the-middle a connection and there must be a way of generating additional traffic such as an SOP bypass or a Cross-site Scripting vulnerability. The user must be using an older web browser, as modern browsers protect against this issue. If all of these conditions are met and session tokens are protected against XSS through a mechanisms such as HttpOnly cookies then an attacker may exploit BEAST to gain access to these protected tokens.

Remediation
Enforce TLS v1.1 and above
Alternatively you could accept the risk and rely on the protections offered by modern browsers, or alternatively prefer RC4 ciphers to mitigate beast but introduce their own issues.

References
https://www.gracefulsecurity.com/what-is-beast/

 

BREACH

CVE-2013-3587, or Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) is an instance of CRIME against HTTP Compression. That is to say that CRIME attacked TLS SPDY whereas BREACH targets HTTP gzip/DEFLATE. Therefore turning off the TLS compression has no affect on BREACH as it exploits the underlying HTTP compression. The attack follows the basic steps of the CRIME attack and there are several methods to remediate the issue, such as disabling HTTP compression, protecting the application from CSRF attacks, randomising CSRF tokens per request to prevent them being captured, obfuscating the length of page responses by adding random amounts of arbitrary bytes to the response.

References

https://bugzilla.redhat.com/show_bug.cgi?id=995168

 

FREAK

CVE-2015-0204, CVE-2015-1637, CVE-2015-1067, or Factoring RSA Keys (FREAK), is a vulnerability that allows an positioned attacker with a man-in-the-middle attack to reduce the security offered by SSL/TLS by forcing a connection to use “Export-grade” grade encryption – which reduces the RSA strength to 512 bits, which is breakable by attackers with a modest budget (In 2015 researchers showed this to be about $104 on Amazon EC2 instances). However breaking keys is still computationally expensive and slow, however an attacker may not require to break a key for every session due to implementation details – for example with Apache mod_ssl a single key was generated at boot time and used for all connections. Export-grade refers to US law which restricted the use of strong cryptography.

References

https://blog.cryptographyengineering.com/2015/03/03/attack-of-week-freak-or-factoring-nsa/

 

Logjam

CVE-2015-4000, or “Logjam”, is a vulnerability which affects TLSv1.2 and below which allows a man-in-the-middle attacker to downgrade the encryption to 512-bit export grade cryptography, which is breakable by attackers with a modest budget (In 2015 researchers showed this to be about $104 on Amazon EC2 instances).

References

https://weakdh.org/

https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

 

NOMORE

Numerous Occurrence MOnitoring & Recovery Exploit, or “RC4 NOMORE”, is a practical attack against RC4 which allows a HTTP Cookie to be retreived within 52 hours, given an effective man-in-the-middle attack. The developers of the NOMORE attack also noted there were several optimisations that could be made to their work to further reduce this time.

References

https://www.rc4nomore.com/

 

Bar Mitzvah

CVE-2015-2808, or “Bar Mitzvah”, relates to a vulnerability known as the Invariance Weakness which allows for small amounts of plaintext data to be recovered from an SSL/TLS session protected using the RC4 cipher.The attack was described at Blackhat Asia 2015. It requires a positioned attacker with a man-in-the-middle attack capable of capturing “many millions” of requests. This vulnerability allows a positioned attacker to recover the least significant bit of as many as 100 bytes from the encrypted stream.

References

https://www.blackhat.com/docs/asia-15/materials/asia-15-Mantin-Bar-Mitzvah-Attack-Breaking-SSL-With-13-Year-Old-RC4-Weakness-wp.pdf

 

SWEET32

CVE-2016-2183, or “SWEET32”, relates to a birthday attack against 64-bit block ciphers such as DES and 3DES. It requires a positioned attacker with a man-in-the-middle attack capable of capturing a long-lived HTTPS connection. The original proof of concept showed that it was possible to recover secure HTTP cookies by capturing around 785 GB of traffic, by generating traffic through malicious JavaScript. Effectively therefore, this vulnerability allows a positioned attacker to bypass the protections offered by the “secure”  flag on cookies when used in conjunction with a vulnerability such as a SOP bypass or Cross-site Scripting.

DES-CBC3-SHA

References
https://sweet32.info/
https://www.openssl.org/blog/blog/2016/08/24/sweet32/

 

SSL POODLE

CVE-2014-3566, SSL Padding Oracle On Downgraded Legacy Encryption Vulnerability (POODLE) is a vulnerability affecting SSLv3 where a block cipher is enabled utilizing the CBC cipher mode. It requires a man-in-the-middle attack and the ability for the attacker to cause the application to send the same data over newly created SSL3.0 connections but allows an attacker to decipher a chosen byte of cipher text in as few as 256 attempts. This vulnerability is an issue in the specification not a specific implementation issue. Additionally if a service prefers TLS over SSLv3 it may be possible to ‘roll back’ the connect if the TLS Fallback SCSV mechanism is not enabled.

References

https://www.imperialviolet.org/2014/10/14/poodle.html

Any SSLv3 block cipher with CBC

 

TLS POODLE

CVE-2014-8730, TLS Padding Oracle On Downgraded Legacy Encryption Vulnerability (POODLE) is a vulnerability affecting certain implementations of TLS. Originally the attack was described against SSLv3 although later expanded with certain limitations. This vulnerability is implementation specific, but known to affect F5 products.

References

https://www.imperialviolet.org/2014/12/08/poodleagain.html

https://support.f5.com/csp/#/article/K15882

 

Heartbleed

CVE-2014-0160, or “Heartbleed”, is not an issue in SSL/TLs specifically, but instead was an implementation issue  in OpenSSL affecting versions 1.0.1 through 1.0.1f. It can be fixed either through upgrading to a more recent version of OpenSSL or alternatively compiling with the option -DOPENSSL_NO_HEARTBEATS. It does not require a Man-in-the-Middle to exploit and can be exploited against both the server and the client. The issue allows an attacker to extract up to 64kb of memory from the vulnerable system, which can lead to the theft of credentials, session tokens and server private keys.

References

http://heartbleed.com/

 

Cipher Suites

RC2

RC2 ciphers are considered to offer only a low amount of security as their key length. Low strength ciphers are considered to be those with a key length <= 64-bits.

EXP-RC2-CBC-MD5

 

RC4

RC4 ciphers are known to be vulnerable to a number of issues such as the “Invariance Weakness” first described in 2001. Several attacks have been discussed, such as the “Bar Mitzvah attack” demonstrated at Blackhat Asia 2015. This algorithm is also referred to as ARC4 or ARCFOUR (for Alleged RC4) in some contexts due to the term RC4 being trademarked. The most notable attack is likely the RC4 NOMORE attack which can recover a TLS protected HTTP cookie in as little as 52 hours.

ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, EXP-RC4-MD5, RC4-64-MD5, RC4-MD5, RC4-SHA

 

DES

DES is a 64-bit block cipher and is therefore affected by the “SWEET32” vulnerability described in CVE-2016-2183.

Additionally it is marked as a “Medium” strength cipher which is below the recommended level. Medium strength ciphers are those with a key length at least 56 bits and less than 112 bits.

ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5, ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5, ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5, ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5

 

3DES

3DES uses a 64-bit block cipher and is therefore affected by the “SWEET32” vulnerability described in CVE-2016-2183.

PSK-3DES-EDE-CBC-SHA, PSK-3DES-EDE-CBC-SHA, PSK-3DES-EDE-CBC-SHA, PSK-3DES-EDE-CBC-SHA

 

NULL

The NULL cipher suites simply inform the browser not to encrypt data, therefore effectively nullifying any protection given through the use of SSL/TLS.

ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, RSA-NULL-SHA256

Hashing

SHA-1

Both Microsoft and Google have announced that it is inappropriate to use. Microsoft, when speaking about SSL/TLS for HTTPS noted back in 2013 that they will no longer be supporting SHA1 as a security algorithm past 2016. Google had a similar announcement stating they will be penalising companies for using SHA1 during 2016 and no longer supporting it post-2016 – that announcement and a little further information is available here: https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.htmlMicrosoft also published the following article which shows movement towards deprecation in Internet Explorer and Edge: https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#Jeb54DCIEtIIcY4r.97 

References
https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#Jeb54DCIEtIIcY4r.97

https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html

 

Certificate Issues

Self-Signed Certificates are those which have not been signed by a recognized certificate authority. These effectively nullify the protections offered by SSL/TLS as an attacker can simply create their own “forged” certificate and the end user would have no way of knowing that the certificate was no the one that should be expected – therefore allowing a positioned attacker to establish a man-in-the-middle attack to capture all encrypted data and to modify both client requests and server responses. This is different to a certificate which is signed by an unrecognized Certificate Authority (CA) as the attacker would not be able to forge these certificates specifically although the client may have the Certificate Authority as trusted within their local store; this situation is often found on internal corporate networks where the company have implemented their own CA.

 

Certificate with Wrong Hostname

If the Common Name does not match the hostname of the server then a user may not be able to determine if the certificate is for that service or not, this generally results in a security error within web browsers and requires the user to “click through” the message to view the application. This would also prevent a user from visiting the application if HSTS is enabled. This would likely require some degree of social engineering to be useful to an attacker attempting to man-in-the-middle a connection, however users may be used to clicking through the error message when visiting this service and therefore not notice the illegitimate certificate.

 

 

Something missing? Something new? Let me know!