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:

$yawastsslhttps://adamcaudill.com --tdessessioncount ______________________ \ \ / / _ \| || |/ _ \ /___|__| \ V / /_\ \ || / /_\ \\ `--.| | \ /|_| |/\| |_| `--. \ | | | || | | \/\/ | | |/\__/ / | | \_/\_| |_/\/\/\_| |_/\____/\_/ YAWASTv0.3.0 - TheYAWASTAntecedentWebApplicationSecurityToolkit Copyright (c) 2013-2016 AdamCaudill <adam@adamcaudill.com> Support & Documentation: https://github.com/adamcaudill/yawast Ruby 2.2.4-p230; OpenSSL 1.0.2f28 Jan 2016 (x86_64-darwin15) Scanning: https://adamcaudill.com/ DNSInformation: [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=spf1mx a ptrinclude:_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 BeginningSSLLabsscan (this couldtake a minuteor two) [SSLLabs]This assessmentserviceis providedfreeofchargebyQualysSSLLabs, subjectto ourtermsand conditions: https://www.ssllabs.com/about/terms.html . [I] IP: 104.28.27.55 - Grade: A+ ...[snip]... TLSSessionRequestLimit: Checkingnumberofrequestsacceptedusing 3DES suites... ..... [I] TLSSessionRequestLimit: Connectionterminatedafter 100 requests (TLSReconnected) [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.