Saltar a la navegación Saltar al contenido principal Ir al pie de página

SMACK, SKIP-TLS & FREAK SSL/TLS Vulnerabilities

04 marzo 2015

By Ollie Whitehouse

Research Cryptography Vulnerability

Previous current event

This is a current event and as such this blog post is subject to change over the course of the next couple of days as we perform further supplementary research and analysis.

  • 1.0: Initial version.
  • 1.1: Revised to include further vulnerable software, alpha signature and small clarifications.
  • 1.2: Added additional analysis from NCC Group’s Cyber Defence Operations team on FREAK
  • 1.3: Updated to reflect Microsoft confirming vulnerability
  • 1.4: Updated to reflect Apple patches and other CVE – last update

Background

On March 3, 2015 research was disclosed titled SMACK: State Machine AttaCKs. This research discussed a number of attacks against TLS implementations which would enable threat actors who are able to perform Man-in-the-Middle attacks the ability to in some cases spoof the identity and worse case entirely disable the expected encryption (SKIP-TLS). The second attack related to a situation again using Man-in-the-Middle attacks where the strength of encryption could be downgraded would bring it within the realms of being crackable using modern hardware (FREAK – Factoring RSA Export Keys).

This vulnerability whilst serious in situations where Man-in-the-Middle attacks can be performed is less readily exploitable on a mass scale as Heartbleed was. Instead it is most likely to be used in scenarios such as Wi-Fi hot-spots or local / adjacent network attacks. Other exploitation scenarios as arguably more sophisticated and require the ability to intercept and modify communication readily between clients and servers.

Products affected / fixed versions

The following is a summary of the known effected products and software components.

SKIP-TLS (CVE-2014-6593):

FREAK (CVE-2015-0204):

Impact of exploitation

The impact of exploitation of this vulnerability is in the case of SKIP-TLS (Java / CyaSSL), and where the threat actor is able to perform a Man-in-the-Middle attack, the ability to impersonate any server and force the connection to clear-text facilitating eaves dropping and content modification. For FREAK affected components (LibreSSL, OpenSSL, Safari, BlackBerry 10 and Android Browser etc.) the threat actor would be able to downgrade the strength of encryption to a level which is crackable using modern hardware for a particular targeted connection. They would however still have to perform the cracking operation.

Recommendations to customers

NCC Group recommends that customers should in the short term:

  • Identify all Internet exposed systems which support SSL/TLS export cipher suites
  • Where hosts are identified as supporting these cipher suites should be disabled.
  • Identify vulnerable client systems i.e. those running:
    • Oracle Java (SKIP-TLS)
    • Apple Safari (FREAK)
    • Google Chrome (FREAK)
    • OpenSSL (CVE-2015-0204) / LibreSSL (FREAK)
    • Android Browser / WebView (FREAK)
    • BlackBerry 10 (FREAK)
    • Microsoft SChannel (FREAK)
    • For identified vulnerable hosts/devices consider one of the following courses of short term action:
      • Upgrade immediately if patches are available for the platform / device.
      • Deploy and/or configure network based protective monitoring for systems which cannot be disabled until patches become available.
      • Work with vendors of all affected hardware and software to ensure patches are deployed when made available.

Protective monitoring signatures

NCC Group’s Cyber Defence Operations team has developed the following alpha Suricata detection signature for FREAK:

alert tcp any any <> any any (msg:"SSL EXPORT Ciphers"; flow:established,to_server; ssl_state:client_hello; content:"|00 14 00 11 00 19 00 08 00 06 00 17 00 03 00 ff|"; sid:1; rev:1;)

However, this is alpha as research, development and testing continues. To determine if a Server accepts Export Ciphers, run the following command:

openssl s_client -connect google.com:443 -cipher 'EXPORT'

The Server will respond with a message like the following if it does not support the Cipher suite:

CONNECTED(00000003)
3073972424:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 75 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

If the Server does support the Cipher suite, you will get a response similar to this:

CONNECTED(00000003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify error_num=20:unable to get local issuer certificate
verify return:0
---
…SNIP…
---
No client certificate CA names sent
---
SSL handshake has read 4778 bytes and written 193 bytes
---
New, TLSv1/SSLv3, Cipher is EXP-RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : EXP-RC4-MD5
    Session-ID: 1234E36E65F99D0F1234344F3F123493391560B0F123423EECF0835123467959
    Session-ID-ctx
    Master-Key: 057ED9F44171BC3AC2BAD…
 …SNIP…
---

As you can see, the Server responded using TLSv1 Cipher:

EXP-RC4-MD5 (TLS_RSA_EXPORT_WITH_RC4_40_MD5)

Looking at this request in Wireshark, we see our Client only offers the Export Cipher suites: 

So if we are being MITM’d we would have seen our ‘Client Hello’ request (using the Standard Cipher suite) leave our browser, and the Server would have responded but with the Export Cipher suite.

The Suricata signature we created specifically looks for the Export Cipher suite above. The rule is very tight (in regards to what it is looking for), and will fail if one of the Export Ciphers are not included or in they are in a different order (hence why it is an alpha signature).

Further information

For further information:

Published date:  04 March 2015

Written by:  Ollie Whitehouse

Ollie Whitehouse

Ollie Whitehouse

Formally Group CTO for NCC Group 2017 - 2022