Extended Brain Storage

Currently Known Vulnerabilities of the Transport Layer Security

Posted on January 26, 2020

An attempt to provide a comprehensive overview of known vulnerabilities and recommended parameters for deployment of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) respectively...

Disclaimer: The author tried to provide as many references as possible. However, the Internet was used as the only source.

Jean-Luc Picard on duty [source]

Jean-Luc Picard on duty [source]

The principles of operation of the SSL/TLS were discussed in Transport Layer Security Deep Dive including a little bit of cryptography theory.

A List of Currently Known SSL/TLS Vulnerabilities

Proven by history, the usage of SSL or TLS has never assured 100% confidentiality of the transmitted data.

1998: Oracle Attacks

A cryptographic algorithm attack which explores response of an encryption system based on different PT and response of a decryption system based on different CT. The aim is to acquire useful information which would help disclose secret information (also called an oracle), such as keys. The same as the Pythia (the Oracle of Delphi), it provides an indication to tell an attacker whether their goal was reached. The oracle attacks are also called side-channel attack and there exist the following types:

2006: Bleichenbacher's e=3 RSA Attack

Vulnerability: CVE-2006-4339

Solution:

2008: Protocol Dance

A downgrade attack, which is a gradual decrease of supported protocol version between the client and the server (i.e. a fallback from the TLS to the SSL), has always resembled an imaginary devil's dance. More or less, the protocol dance takes place as follows:

This attack is a way to arbitrarily depreciate a client-server communication in order to ensure that the specific version of SSL or TLS, which is a prerequisite for another attacker, is utilised.

On the other hand, decreasing the protocol version could occur also as a result of increased error rate between the client and server. A fall back down to the SSL resulted in an inability to access services (e.g. domain names) which shared the same IP address on a single server due to the fact that SSL 3.0 does not support the Server Name Indication (SNI). The SSL 2.0 does not support it at all.

Solution:

2008: MD5 CA

Practical exploitation of the Message-Digest (MD5) hashing algorithm, see RFC 1321 for more details to find out that since 1992, it has been known that the MD5 was weak, as methods to successfully generate collisions had already been known (i.e. a situation, in which for two or more different inputs, the hashing function produces the same output -- digest.)

Solution:

2009: Client-/Server-initiated Secure Renegotiation

Vulnerability: CVE-2009-3555 (two issues)

  1. Renegotiation:
    • The TLS and SSL 3.0 protocols (and most probably also the earlier SSL versions) incorrectly associate renegotiation handshakes with an existing connection.
    • Using a man-in-the-middle (MitM) attack, attackers are able to insert unauthenticated data into existing HTTPS and other SSL/TLS protected sessions in an attempt to get processed retroactively by a server in a post-renegotiation context.
  2. Denial of Service (DoS):
    • The renegotiation attack can be combined with a brute-force attempt to trigger hundreds of TLS/SSL handshakes in parallel within the same TCP session.
    • This attack can render a powerful server connected using a 30Gbps link unresponsive only using an average home laptop with a DSL connection.

Solution (upgrade of the used SSL/TLS libraries):

Verification:

$ openssl s_client -connect <target>:<port> -msg
  ...
  Secure Renegotiation IS supported
  ...
  R
  RENEGOTIATING
  ...
<<< TLS 1.2, Alert [length 0002], fatal no_renegotiation
  ...

2011: Browser Exploit Against SSL/TLS (BEAST)

Vulnerability: CVE-2011-3389

Solution:

Verification:

$ openssl s_client -tls1 -connect <target>:<port> -msg
...
<<< TLS 1.0, Alert [length 0002], fatal protocol_version
...
ValueDescription (IANA)OpenSSL
0x00, 0x39TLS_DHE_RSA_WITH_AES_256_CBC_SHADHE-RSA-AES256-SHA
0x00, 0x35TLS_RSA_WITH_AES_256_CBC_SHAAES256-SHA
0x00, 0x33TLS_DHE_RSA_WITH_AES_128_CBC_SHADHE-RSA-AES128-SHA
0x00, 0x2fTLS_RSA_WITH_AES_128_CBC_SHAAES128-SHA

2012: Compression Ratio Info-leak Made Easy (CRIME)

Vulnerability: CVE-2012-4929

Solution:

Verification:

$ openssl s_client -connect <target>:<port> -msg
  ...
  Compression: NONE
  Expansion: NONE
  ...

Practical exploitation (for demonstration purposes only!) using an arbitrary scripting program, which can be easily modified for particular server/application purposes:

  1. Analysis of obtained "HTTP Cookies" and selection of one.
  2. Trying the first character of the selected "HTTP Cookie", waiting for server reply and comparison of both.
  3. Most probably, the length of replies to correct characters will differ from those to incorrect characters (longer replies).
  4. Progressively, the whole "HTTP Cookie" value can be acquired.

2012: Timing Info-leak Made Easy (TIME)

Vulnerability: No registered CVE available

Solution:

Verification (two phases to detect the):

  1. SSL/TLS compression enabled (the same as with CRIME).
  2. Instead of comparison of returned values (as with CRIME), the server response times are analysed by the client. In order to minimise the influence of the Round Trip Time (RTT), i.e. the delay it takes a message to travel back and forth from a client to a server and back, it is useful to retry the attempt approximately 10x followed by an appropriate statistical analysis.

2013: Lucky Thirteen (Lucky 13)

Vulnerability: CVE-2013-0169:

Solution:

Verification:

2013: Rivest Cipher (ARCFOUR, RC4)

Vulnerability: CVE-2013-2566 and CVE-2015-2808

Solution:

Verification:

$ openssl s_client -cipher RC4 -connect <target>:<port> -msg
  ...
  140355035514528:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:770:
  ...
$ openssl s_client -cipher RC4 -connect <target>:<port> -msg
Error with command: "-cipher RC4"
108509023008000:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2558:

2013: Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext (BREACH)

Vulnerability: CVE-2013-3587

Solution:

Verification

$ target=URL-OF-TARGET\
$ for compression in compress deflate exi gzip identity pack200-gzip br bzip2 lzma peerdist sdch xpress xz; do\
  curl -ksI -H "Accept-Encoding: ${compression}" https://${target} | grep -i ${compression}\
  done

2014: Heartbleed

Vulnerability: CVE-2014-0160

Solution:

Verification:

$ nmap --script ssl-heartbleed <target> -p <port>
...
PORT STATE SERVICE
443/tcp open https
| ssl-heartbleed:
|   VULNERABLE:
|   The Heartbleed Bug is a serious vulnerability ...
|     State: VULNERABLE
|     Risk factor: High
...
$ nmap --script ssl-heartbleed <target> -p <port>
...
PORT STATE SERVICE
443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 0.87 seconds

2014: BERserk

Vulnerability: CVE-2014-1568

Solution:

2014: (Early) CCS Injection

Vulnerability: CVE-2014-0224

Solution:

Verification

$ nmap --script ssl-ccs-injection <target> -p <port>
...
PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http ...
| ssl-ccs-injection:
|   VULNERABLE:
|   SSL/TLS MITM vulnerability (CCS Injection)
|     State: VULNERABLE
|     Risk factor: High
...

2014: Padding Oracle On Downgraded Legacy Encryption (POODLE)

Vulnerability: CVE-2014-3566

Solution:

Verification:

$ nmap -sV --version-light --script ssl-poodle <target> -p <port>
...
PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http ...
| ssl-poodle:
|   VULNERABLE:
|   SSL POODLE information leak
|     State: VULNERABLE
|     IDs: ...
...
$ nmap --script ssl-heartbleed <target> -p <port>
...
PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http ...

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.81 seconds
$ openssl s_client -ssl3 -connect <target>:<port> -msg
s_client: Option unknown option -ssl3
s_client: Use -help for summary.
$ openssl s_client -tls1 -fallback_scsv -connect <target>:<port> -msg
...
<<< TLS 1.0, Alert [length 0002], fatal protocol_version
...

2014: Padding Oracle On Downgraded Legacy Encryption (POODLE attack against TLS)

Vulnerability: CVE-2014-8730

Solution:

Verification:

$ nmap -sV --version-light --script ssl-poodle <target> -p <port>

2015: Factoring RSA Export Keys (FREAK)

Vulnerability: CVE-2015-0204

ValueDescription (IANA)OpenSSL
0x00, 0x03TLS_RSA_EXPORT_WITH_RC4_40_MD5EXP-RC4-MD5
0x00, 0x06TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5EXP-RC2-CBC-MD5
0x00, 0x08TLS_RSA_EXPORT_WITH_DES40_CBC_SHAEXP-DES-CBC-SHA
0x00, 0x14TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHAEXP-EDH-RSA-DES-CBC-SHA

Vulnerability: CVE-2015-1637 (Microsoft SChannel)

Vulnerability: CVE-2015-1067 (Apple Secure Transport)

Solution:

Verification

$ openssl s_client -cipher EXPORT -connect <target>:<port> -msg
$ openssl s_client -cipher EXPORT -connect <target>:<port> -msg
Error with command: "-cipher EXPORT"
109528135714048:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2558:

2015: #OprahSSL

Vulnerability: CVE-2015-1793

Solution:

Verification:

$ if [[ `openssl version|cut -d' ' -f2` =~ ^1.0.1(n|o)|1.0.2(b|c)$ ]]; then\
  echo "VULNERABLE";\
  else\
  echo "NOT vulnerable";\
  fi

2015: Logjam (WeakDH)

Vulnerability: CVE-2015-4000

Solution:

$ openssl dhparam -out dhparams.pem <key-length>

Verification:

$ openssl s_client -cipher DHE:EXPORT -connect <target>:<port> -msg
...
<<< TLS 1.3, Alert [length 0002], fatal handshake_failure
...

2015: Lucky Microseconds

Vulnerability: "A Timing Attack on Amazon's s2n Implementation of TLS"

Solution:

Verification:

2016: Decrypting RSA with Obsolete and Weakened eNcryption (DROWN)

Vulnerability: CVE-2016-0800CVE-2016-0703, CVE-2016-0704 and others

Solution:

Verification:

$ openssl s_client -ssl2 -connect <target>:<port> -msg
$ openssl s_client -ssl2 -connect <target>:<port> -msg
s_client: Option unknown option -ssl2
s_client: Use -help for summary.
$ nmap -sV --script=sslv2-drown <target> -p <port>
...
PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http ...
|_sslv2-drown:
...

2016: Sweet32

Vulnerability: CVE-2016-2183 and CVE-2016-6329

Solution:

Verification:

$ openssl s_client -cipher DES -connect <target>:<port> -msg
$ openssl s_client -cipher 3DES -connect <target>:<port> -msg
$ openssl s_client -cipher Blowfish -connect <target>:<port> -msg
$ openssl s_client -cipher DES -connect <target>:<port> -msg
Error with command: "-cipher DES"
105822496478464:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2558:

2016: Don't Use Hard-coded Key (DUHK)

Vulnerability: CVE-2016-8492:

Solution:

Verification:

2017: Return Of Bleichenbacher's Oracle Threat (ROBOT)

Vulnerability: CVE-2017-6168, but there are more (according to the affected manufacturer or service provider).

Solution:

ValueDescription (IANA)OpenSSL
0x00, 0x2FTLS_RSA_WITH_AES_128_CBC_SHAAES128-SHA
0x00, 0x35TLS_RSA_WITH_AES_256_CBC_SHAAES256-SHA
0x00, 0x3CTLS_RSA_WITH_AES_128_CBC_SHA256AES128-SHA256
0x00, 0x3DTLS_RSA_WITH_AES_256_CBC_SHA256AES256-SHA256
0x00, 0x9CTLS_RSA_WITH_AES_128_GCM_SHA256AES128-GCM-SHA256
0x00, 0x9DTLS_RSA_WITH_AES_256_GCM_SHA384AES256-GCM-SHA384

Verification:

2017: The Return of Coppersmith's Attack (ROCA)

Vulnerability: CVE-2017-15361

Solution:

Verification:

$ nmap -sV --script rsa-vuln-roca <target> -p <port>
...

2018: ARM mbed TLS

Vulnerability: CVE-2018-0488

Solution:

2018: Jenkins vSphere Plugin

Vulnerability: CVE-2018-1000151

Solution:

2019: Further Attacks on TLS

The recent TLS Padding Oracles study reveals that the SSL/TLS protocols and all of their technical aspects will be tested in various ways. In relationship to the CBC mode, the following variants were presented in 2019:

Published CVE:

Solutions:

Verification:


Testing Tools

Generally speaking, the testing of the particular vulnerabilities and supported cipher suites can be performed as follows:

The Internet is full of manuals and hints, such as the Doing your own SSL/TLS testing.


Protecting the Client

Generally speaking, an updated web browser is a best practice to provide adequate protection to the user, as it does not allow the usage of obsolete algorithms by default. However, particular browsers can be additionally configured to further fine-tune the setup provided by the manufacturers.

Considering the Bar Mitzvah attack, modern and up-to-date browser will protect users by not providing the RC4-based cipher suites support. Considering an outdated browser as an example, the attack can be prevented manually by disabling all RC4-based cipher suites as follows.

Google Chrome and Opera

It is possible to execute the browser with a parameter to disable support of specific cipher suites as follows (e.g. the RC4):

$ chrome -cipher-suite-blacklist=0x0005,0x0004,0x002f,0xc012,0xc011,0x003c,0xc011,0x0032,0xc007,0xc00c

Mozilla Firefox

In a running browser instance, the following steps need to be followed in order to disable a particular cipher suite:

Microsoft Internet Explorer

Naturally for the Microsoft-based environment, the configuration of the Internet Explorer can be found in the Windows Registry. Considering the RC4, it can be disabled using the option Enabled (type REG_DWORD) by setting it to 00000000 in the following locations:


Conclusion

Support of obsolete algorithms and protocols provides maximum variability and interoperability. However, it also increases attack surface and security risk. From the configuration perspective, the most easiest and safest is to strictly support the TLS 1.3 only. However, it also increases operational and business risks, which are strongly tight with possible incompatibility with communicating parties that have not adopted this version yet. Therefore, as an optimal solution, it seems to use a compromise of supporting also the TLS 1.2 with carefully selected cipher suites to increase compatibility (see Transport Layer Security Hardening).

Either strict or optimal cipher suite setup does not solve all TLS-related issues which are bound to the public key infrastructure (PKI). For the purpose of TLS certificate revocation, the following methods are designed:

Browsers usually implement the "soft-fail" approach to OCSP checks, where a revoked certificate will be regarded as valid if the OCSP request fails. A "hard-fail" approach would not allow paid WiFi hotspots or hotel captive portals to work, as the OCSP responder used by the site's certificate could not be used before the user was authenticated. OCSP stapling combined with the must-staple extension (see the RFC 6066 and the RFC 6961) is one of the methods to deal with the aforementioned chicken-egg problem. Although the principle is simple, i.e. browsers have to request OCSP responses in the TLS handshake and provide the complete certificate chain, which eliminates the need of clients to contact the CA directly. However, it is unlikely to be adopted quickly. More info on blog.apnic.net or scotthelme.co.uk.


More Information Sources

Tags: #TLS #SSL #security #RSA #Diffie-Hellman

⏴ Previous Post Next Post ⏵