Monthly Archives: June 2013

Browser Exploit Against SSL/TLS

On my last post I wrote about how cipher suite decision works on SSL with a practical example. Today, I would like to write about what is the impact of choosing and prioritizing the appropriate cipher suites on your SSL environment.

Back in May 2011, Juliano Rizzo and Thai Duong released a paper named Here Come The XOR Ninjas [1]. This paper was a contribution to the security community on illustrating a concrete proof of concept against implementations of SSL 3.0 and TLS 1.0 using cipher block chaining (CBC) encryption scheme in a browser environment [3]. The attack also become known as The BEAST (Browser Exploit Against SSL/TLS) [2]. It has been widely publicized after it’s released since the vulnerability was known in the research community but before the paper, attacks against CBC were believed to be theoretical. As a reference, the use of predictable initialization vectors (IV) for CBC mode in a chosen-plaintext attack against SSL 3.0 and TLS 1.0 are described by Bodo Moeller here and by Gregory Bard here.  In a SSL connection if the data is encrypted using CBC with chained IVs, it allows a man-in-the-middle to obtain plain text HTTP headers using blockwise-adaptive chosen-plaintext attack [4][5]. In short it will allow decrypting HTTPS requests and steal information such as session cookies to be used to impersonate the user. The attack has been demonstrated by the researchers on the Ekoparty security conference using Java, a network sniffer and a popular browser [8].

Are you vulnerable to such attack? To quickly verify your web server SSL settings I would recommend looking at SSL Labs from Qualys and running the SSL Server test. If, for example,  you use a SSL load balancer or application firewall from F5 take a look here on how to reduce the exposure to this attack. All major vendors have information about how to configure and remediate this vulnerability. On 09 July 2011 the US National Vulnerability Database published CVE-2011-3389 to address this vulnerability with a CVSS score of 4.3.

On the other hand, in order to remediate this vulnerability the focus should be on configuring the web servers to prioritize a different cipher suite, or upgrade to TLS 1.1/1.2 [8]. Also consider that this attack has a low CVSS score and it’s not easy to pull. Therefore, unless you are exposed to someone who would have the means, motive and opportunity it might be worth to spend time on fixing other things.

If you want to read more about it, I would recommend taking a look at Thai Duong blog article he released one week after the security conference. The summary from Thierry Zoller and the below references.

[1] http://www.infoworld.com/sites/infoworld.com/files/pdfe/BEAST_Duong_Rizzo.pdf
[2] http://vnhacker.blogspot.co.uk/2011/09/beast.html
[3] http://www.imperialviolet.org/2011/09/23/chromeandbeast.html
[4] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
[5] http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html
[6] http://www.openssl.org/~bodo/tls-cbc.txt
[7] http://eprint.iacr.org/2006/136.pdf
[8] http://www.ietf.org/proceedings/85/slides/slides-85-saag-1.pdf

Tagged , , , , , ,

SSL Handshake Protocol

Some years ago during the recruitment phase for a position in professional services. At the end of the technical interview, the practice manager asked if I could provide him by email a little research about the SSL handshake (specific to Web applications) and let him know about the decision on cipher suites, which side (client or server) makes the decision. Basically he wanted to know who makes the decision about which cipher suite to use and details behind it.

I must say I really liked the challenge because it allowed me to do research and build documentation about security matters. So I made a small investigation using one or two good books and produced a three pages document with the technical details.

This is what this blog entry is about. I would like to share with not the three pages document but a short technical summary about the answer I provided on the SSL handshake protocol and the CipherSuite parameter decision. Plus a practical illustration on the usage of the SSL handshake protocol and the cipher suite decision process using openssl and tshark tools.

In short, the most difficult part of SSL stack is the handshake protocol. During the phase 1 of the handshake protocol, where it’s established the security capabilities, the exchange is initiated by the client who sends a client_hello message with a set of parameters. One of those parameters is the CipherSuite which is a list that contains the combinations of cryptographic algorithms supported by the client, in decreasing order of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm and a CipherSpec.

After sending the client_hello message, the client waits for the server_hello message, which containts the same parameters as the client_hello message. Again, here one of the parameters is the CipherSuite, which in the server_hello message contains the single cipher suite selected by the server from those proposed by the client. With this two messages the phase 1 is established and the SSL establishments continues with the phase 2 which is the Server Authentication and Key Exchange. Then the phase 3 for Client Authentication and Key Exchange. Finally the phase 4 to complete the handshake and begin to exchange application layer data.

In short and to make a direct answer to his question: the cipher suits are proposed by the client and decided by the server.

Now, the interesting part is below where a practical exercise was made to illustrate this.

Running on a Linux system I established a HTTPS connection with the host www google.com using openssl command and in parallel executed tshark to capture the packets. Some of the verbose output has been omitted to show what is truly pertinent to the SSL Handshake protocol.

In the output of the openssl command we can see the server X.509 public certificate and its parameters and that the SSL handshake protocol was accomplished using RC4-SHA as cipher and TLSv1 as protocol.

lrocha@host:~$ openssl s_client -connect www.google.com:443
 CONNECTED(00000003)
 depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 verify error:num=20:unable to get local issuer certificate
 verify return:0
 ---
 Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
 i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
 ---
 Server certificate
 -----BEGIN CERTIFICATE-----
 MIIDITCCAoqgAwIBAgIQT52W2WawmStUwpV8tBV9TTANBgkqhkiG9w0BAQUFADBM
 MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
 THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0xMTEwMjYwMDAwMDBaFw0x
 MzA5MzAyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
 MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
 FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
 gYEA3rcmQ6aZhc04pxUJuc8PycNVjIjujI0oJyRLKl6g2Bb6YRhLz21ggNM1QDJy
 wI8S2OVOj7my9tkVXlqGMaO6hqpryNlxjMzNJxMenUJdOPanrO/6YvMYgdQkRn8B
 d3zGKokUmbuYOR2oGfs5AER9G5RqeC1prcB6LPrQ2iASmNMCAwEAAaOB5zCB5DAM
 BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
 LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
 BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
 Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
 ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
 AAOBgQAhrNWuyjSJWsKrUtKyNGadeqvu5nzVfsJcKLt0AMkQH0IT/GmKHiSgAgDp
 ulvKGQSy068Bsn5fFNum21K5mvMSf3yinDtvmX3qUA12IxL/92ZzKbeVCq3Yi7Le
 IOkKcGQRCMha8X2e7GmlpdWC1ycenlbN0nbVeSv3JUMcafC4+Q==
 -----END CERTIFICATE-----
 subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
 issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 1772 bytes and written 307 bytes
 ---
 New, TLSv1/SSLv3, Cipher is RC4-SHA
 Server public key is 1024 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol : TLSv1
 Cipher : RC4-SHA
 Session-ID: 8FEF40B71445984250A6658D3664CB8D391EEA43EB40CD535249FAB6EFC79F11
 Session-ID-ctx:
 Master-Key:
 8CFE3997E583BC3D9FDBCC81F3FA136DCC1872818FF9BECA6B10C64EA03D6D52C163DA470779E7D5AB23A89967A05E39
 Key-Arg : None
 Start Time: 1335093485
 Timeout : 300 (sec)
 Verify return code: 20 (unable to get local issuer certificate)

With tshark we can see that during the client_hello message the client proposes
26 cipher specs in order of preference which by its turn it’s followed by the server_hello
message which decides to use the Cipher Suite: TLS_RSA_WITH_RC4_128_SHA
(0x0005).

lrocha@host:~$ tshark -i eth0 -Vx -s0 port 443 

Secure Socket Layer 
 SSLv2 Record Layer: Client Hello
 [Version: SSL 2.0 (0x0002)] 
 Length: 119 
 Handshake Message Type: Client Hello (1) 
 Version: TLS 1.0 (0x0301) 
 Cipher Spec Length: 78 
 Session ID Length: 0 
 Challenge Length: 32 
 Cipher Specs (26 specs) Cipher Specs (26 specs)
 Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x000039) 
 Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x000038) 
 Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x000035) 
 Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016) 
 Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013) 
 Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a) 
 Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) 
 Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033) 
 Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032) 
 Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f) 
 Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) 
 Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005)
 Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004) 
 Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) 
 Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015) 
 Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012) 
 Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009) 
 Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) 
 Cipher Spec: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000014) 
 Cipher Spec: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x000011) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006) 
 Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003) 
 Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) 
 Cipher Spec: Unknown (0x0000ff) 
 Challenge 

Secure Socket Layer 
 TLSv1 Record Layer: Handshake Protocol: Server Hello
 Content Type: Handshake (22) 
 Version: TLS 1.0 (0x0301)
 Length: 81 
 Handshake Protocol: Server Hello 
 Handshake Type: Server Hello (2) 
 Length: 77 
 Version: TLS 1.0 (0x0301) 
 Random 
 gmt_unix_time: Aug 22, 2009 07:18:05.000000000 EDT 
 random_bytes: 4abfee70b2a89e684e917c40c47054bf074028babe764af3... 
 Session ID Length: 32 
 Session ID: 8fef40b71445984250a6658d3664cb8d391eea43eb40cd53... 
 Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
 Compression Method: null (0) 
 Extensions Length: 5 
 Extension: renegotiation_info 
 Type: renegotiation_info (0xff01) 
 Length: 1 
 Data (1 byte)

Bottom line, I didn’t got the job but it was fun!

Tagged
gb_master's /dev/null

... and I said, "Hello, Satan. I believe it's time to go."

Source Code Auditing, Reversing, Web Security

Finding Hidden codes in the software

BruteForce Lab's Blog

security, programming, devops, visualization, the cloud

Count Upon Security

Increase security awareness. Promote, reinforce and learn security skills.

Naked Security

Computer Security News, Advice and Research

Didier Stevens

(blog \'DidierStevens)

malwology

Adventures in double-clicking malware / by Anuj Soni

Rational Survivability

Hoff's Ramblings about Information Survivability, Information Centricity, Risk Management and Disruptive Innovation.

SANS Internet Storm Center, InfoCON: green

Increase security awareness. Promote, reinforce and learn security skills.

TaoSecurity

Increase security awareness. Promote, reinforce and learn security skills.

Schneier on Security

Increase security awareness. Promote, reinforce and learn security skills.

Technicalinfo.net Blog

Increase security awareness. Promote, reinforce and learn security skills.

Lenny Zeltser

Increase security awareness. Promote, reinforce and learn security skills.

Krebs on Security

In-depth security news and investigation