Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Testing for SWEET32 with YAWAST

Testing for SWEET32 isn’t simple – when the vulnerability was announced, some argued that the best solution was to assume that if a TLS server supported any of the 3DES cipher suites, consider it vulnerable. The problem is, it’s not that simple. On my employer’s corporate blog, I wrote about practical advice for dealing with SWEET32 – and pointed out that there are ways around the vulnerability, and some are quite simple.

The easy options:

  • Disable the following cipher suites:
    • SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA
    • SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA
    • SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    • SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
  • Limit HTTP Keep-Alive to something reasonable (Apache & Nginx default to 100 requests)

If you don’t need to worry about users on old platforms, it’s easy – just disable the 3DES suites and you’re done. If you do need to worry about customers using Windows XP, disabling the 3DES cipher suites may not be an option, as the only other cipher suites they support use RC4. In that case, you need to limit Keep-Alive sessions.

In cases where 3DES suites are enabled, but reasonable / default limits are in place, SWEET32 isn’t an issue – as there’s no way to issue enough requests within the same session (and thus the same encryption key) to be able to exploit it.

Testing with YAWAST #

To test for this, I added a new feature to YAWAST that will connect to the server using a 3DES suite, and issue up to 10,000 HEAD requests, to see how many requests the server will allow in a single session. If the server allows all 10,000 requests, there’s a good chance that the server is vulnerable to SWEET32. This method is used to determine that the server is likely vulnerable, without the massive data transfer and time required to actually verify that it’s vulnerable.

Testing for SWEET32 with YAWAST looks like this:

$yawast ssl https://adamcaudill.com --tdessessioncount
__   _____  _    _  ___   _____ _____ 
\ \ / / _ \| |  | |/ _ \ /  ___|_   _|
 \ V / /_\ \ |  | / /_\ \\ `--.  | |  
  \ /|  _  | |/\| |  _  | `--. \ | |  
  | || | | \  /\  / | | |/\__/ / | |  
  \_/\_| |_/\/  \/\_| |_/\____/  \_/  

YAWAST v0.3.0 - The YAWAST Antecedent Web Application Security Toolkit
 Copyright (c) 2013-2016 Adam Caudill <adam@adamcaudill.com>
 Support & Documentation: https://github.com/adamcaudill/yawast
 Ruby 2.2.4-p230; OpenSSL 1.0.2f  28 Jan 2016 (x86_64-darwin15)

Scanning: https://adamcaudill.com/

DNS Information:
[I]         104.28.26.55 (N/A)
                https://www.shodan.io/host/104.28.26.55
                https://censys.io/ipv4/104.28.26.55
[I]         104.28.27.55 (N/A)
                https://www.shodan.io/host/104.28.27.55
                https://censys.io/ipv4/104.28.27.55
[I]         2400:CB00:2048:1::681C:1A37 (N/A)
                https://www.shodan.io/host/2400:cb00:2048:1::681c:1a37
[I]         2400:CB00:2048:1::681C:1B37 (N/A)
                https://www.shodan.io/host/2400:cb00:2048:1::681c:1b37
[I]         TXT: v=spf1 mx a ptr include:_spf.google.com ~all
[I]         MX: aspmx4.googlemail.com (30)
[I]         MX: aspmx.l.google.com (10)
[I]         MX: alt1.aspmx.l.google.com (20)
[I]         MX: aspmx2.googlemail.com (30)
[I]         MX: alt2.aspmx.l.google.com (20)
[I]         MX: aspmx3.googlemail.com (30)
[I]         MX: aspmx5.googlemail.com (30)
[I]         NS: hal.ns.cloudflare.com
[I]         NS: vera.ns.cloudflare.com

Beginning SSL Labs scan (this could take a minute or two)
[SSL Labs]  This assessment service is provided free of charge by Qualys SSL Labs, subject to our terms and conditions: https://www.ssllabs.com/about/terms.html
.

[I] IP: 104.28.27.55 - Grade: A+

...[snip]...

TLS Session Request Limit: Checking number of requests accepted using 3DES suites...
.....
[I] TLS Session Request Limit: Connection terminated after 100 requests (TLS Reconnected)

[I] HSTS: Enabled (strict-transport-security: max-age=15552000; preload)

In this case I’m using YAWAST to run a ssl scan, using the --tdessessioncount parameter to instruct YAWAST to perform the SWEET32 test. In this case, you can see that the TLS session was ended after 100 requests (Connection terminated after 100 requests (TLS Reconnected)) – which is a clear indication that the server isn’t vulnerable. Had the server actually been vulnerable, this message would have been displayed:

[V] TLS Session Request Limit: Connection not terminated after 10,000 requests; possibly vulnerable to SWEET32

The use of 10,000 requests is somewhat arbitrary – it was selected as it’s far above the defaults used for the most common servers, and is small enough that it can be conducted in a reasonable time. It could be argued that it should be larger, to reduce false positives – it could also be argued that it’s excessive, as if it allows 5,000, it’s a reasonable bet that there’s no limit being enforced. This value may change over time based on community feedback, but for now, it’s a safe value that strikes a good balance.

Vulnerable or Possibly Vulnerable? #

Unfortunately the only way to confirm that a server is truly vulnerable is to perform the attack, or at least a large part of it. There will be false positives using this technique, but that’s the cost of performing a quick test (that doesn’t involve transferring tens or hundreds of gigabytes of traffic).

When looking at the results, it’s important to understand that it indicates that the server is likely vulnerable, but it is not a confirmation of vulnerability.

Adam Caudill

Related Posts

  • On Opportunistic Encryption

    Opportunistic encryption has become quite a hot topic recently, and blew up in a big way thanks to an Internet Draft that was published on February 14th for what amounts to sanctioned man-in-the-middle. Privacy advocates were quickly up in arms – but it’s not that simple (see here). As pointed out by Brad Hill, this isn’t about HTTPS traffic, but HTTP traffic using unauthenticated TLS; thanks to poor wording in the document, it’s easy to miss that fact if you just skim it.

  • Looking for value in EV Certificates

    When you are looking for TLS (SSL) certificates, there are three different types available, and vary widely by price and level of effort required to acquire them. Which one you choose impacts how your certificate is treated by browsers; the question for today is, are EV certificates worth the money? To answer this, we need to understand what the differences are just what you are getting for your money. The Three Options For many, the choice of certificate type has more to do with price than type – and for that matter, not that many people even understand that there are real differences in the types of certificates that a certificate authority (CA) can issue.

  • Security By Buzzword – Why I don’t support Ensafer

    Update: I had a call with Ensafer’s CTO, Trygve Hardersen to discuss the issues I brought up, and what they can do about it. First, they updated the site so that downloads are now over HTTPS. He stated that the infrastructure that powers their service is separate from the website, and everything is over HTTPS. They are working on making documentation available, and hope to have the first documents available soon.

  • Ruby + GCM Nonce Reuse: When your language sets you up to fail…

    A couple hours ago, Mike Santillana posted to oss-security about a rather interesting find in Ruby’s OpenSSL library; in this case, the flaw is subtle – so much so that it’s unlikely that anyone would notice it, and it’s a matter of a seemingly insignificant choice that determines if your code is affected. When performing AES-GCM encryption, if you set the key first, then the IV, and you are fine – set the IV first, you’re in trouble.

  • PL/SQL Developer: Nonexistent Encryption

    (See here for another issue discovered during this research; Updates over HTTP & Command Execution.) PL/SQL Developer by Allround Automations has an option to store the user’s logon history with passwords – the passwords are encrypted with a proprietary algorithm. At this point, you should know how this is going to go. For those that don’t know, PL/SQL Developer is a tool for developers and database administrators to access Oracle – an essential tool in many enterprise environments.