Lucene search

K
hackeroneAsheshH1:5617
HistoryApr 02, 2014 - 1:01 p.m.

Slack: TLS1/SSLv3 Renegotiation Vulnerability

2014-04-0213:01:00
ashesh
hackerone.com
1366

5.8 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

MEDIUM

Authentication

NONE

Confidentiality Impact

NONE

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:M/Au:N/C:N/I:P/A:P

0.002 Low

EPSS

Percentile

62.2%

URL: http://www.slack.com

Vulnerability description
A flaw in the design of the TLS v. 1/SSL v. 3 (TLS/SSL) handshake process was discovered in 2009, and RFC 5746 (Feb. 2010) was released to update the protocol specification. Since then, most system manufacturers have released patches to fix this flaw. Still, as of June 2011 approximately half of the systems using TLS/SSL on the Internet have not implemented the patches needed to close this security hole. This vulnerability affects the secure transport of HTTP, IMAP, SMTP, and other protocols that rely on TLS/SSL. Industry representatives and security researchers who have looked into the problem note that sites with the TLS patch may still be vulnerable to this attack, known as the TLS renegotiation Man-In-The-Middle attack (TLS Renego MITM). DigiCert is taking a proactive approach to this problem by contacting its customers to advise them of this potential vulnerability in their systems. At some point in the future, connectivity problems may occur because of server non-compliance with RFC 5746.

A vulnerability in the way SSL and TLS protocols allow renegotiation requests may allow an attacker to inject plaintext into an application protocol stream. This could result in a situation where the attacker may be able to issue commands to the server that appear to be coming from a legitimate source. This issue affects SSL version 3.0 and newer and TLS version 1.0 and newer.
This vulnerability affects Web Server.
Discovered by: TLS1_SSL3_Renegotiation.

Attack details
Just to provide you with a brief overview, the typical TLS/SSL handshake process involves the following:

client hello (highest TLS/SSL version supported, random number, suggested ciphers, suggested compression methods and, if the client is attempting renegotiation, previous session ID)
server hello (TLS/SSL version, random number, cipher suite and compression chosen and, if server is attempting renegotiation, previous session ID)
server sends TLS/SSL certificate
server hello done

client key exchange (preMasterSecret exchange and MasterSecret calculation)
client change cipher spec
client finished (hash and MAC of previous handshake messages)

server change cipher spec
server finished

GET /secure HTTP/1.1\r\n…

(For more information, see Wikipedia’s article on TLS handshakes).

Using the TLS Renego MITM vulnerability, an attacker can either form a TLS connection to the server first, before the client (for example, on a compromised machine in response to the client’s attempt at connection) or can use session renegotiation to effectuate the attack. Even mutual certificate-based client authentication connections are vulnerable to the TLS Renego MITM attack. More details on how various attack scenarios play out are provided in RFC 5746 and related discussions provided here and here.

The impact of this vulnerability
A remote, unauthenticated attacker may be able to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream. This could allow and attacker to issue HTTP requests, or take action impersonating the user, among other consequences.

How to fix this vulnerability

The TLS/SSL specification in RFC 5746 applies to both full handshakes and session resumption handshakes. Because pre-existing TLS/SSL specifications required systems to ignore a ClientHello extension if they did not understand it, RFC 5746 specifies that the ClientHello either contain an empty “renegotiation_info" extension or a Signaling Cipher Suite Value (SCSV) as a pseudo cipher suite with the same semantics as an empty “renegotiation_info” extension. When a client receives the ServerHello, it must check to see if the server supports the “renegotiation_info” extension. Assuming that secure renegotiation is supported per RFC 5746, then for TLS renegotiation, the client can send the “renegotiation_info” extension. If the server does not respond in accordance with RFC 5746, the client MUST abort the renegotiation handshake. Similarly, if a client does not respond in accordance with RFC 5746, then the server MUST abort the renegotiation handshake.

For backward compatibility, a compliant client will be configurable for either allowing insecure renegotiation or aborting an attempt to renegotiate. However, because some TLS servers do not support renegotiation at all there will be a transition period where problems will be encountered. From a server side, if the server does not receive the “renegotiation_info” extension or the SCSV, then RFC 5746 specifies that the “secure_renegotiation” flag be set to FALSE. Thereafter, if a ClientHello for renegotiation contains an empty “renegotiation_info" extension or the SCSV, then the server MUST abort the handshake.

Web references
TLS1/SSLv3 Renegotiation Vulnerability
CVE-2009-3555
VU#120541

5.8 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

MEDIUM

Authentication

NONE

Confidentiality Impact

NONE

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:M/Au:N/C:N/I:P/A:P

0.002 Low

EPSS

Percentile

62.2%