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

  • The (Questionable) Future of YAWAST

    The last release of YAWAST was on January 1, 2020; while the release history was sometimes unpredictable, the goal was a new release each month with new features and bug fixes. I intentionally took January off from the project. In February, I left the company I was at; the team of penetration testers there had helped to inspire new features while looking for ways to make them more productive. But something else happened in February, an issue was opened – something that appeared to be simple, but in fact, made me realize that the entire project was in doubt.

  • YAWAST: News & Mission

    It’s been some time since I last wrote about YAWAST on here, it was actually back in April when I posted the last update – that was for the release of YAWAST v0.7.0. Currently, it’s at version 0.11.0 and a lot has changed. It’s been rewritten from scratch, more people have become involved, it has moved to a (fairly) regular release cycle, and has expanded a fair bit in terms of functionality.

  • YAWAST v0.7 Released

    It has now been over a year since the last major release of YAWAST, but today I am happy to release version 0.7, which is one of the largest changes to date. This is the result of substantial effort to ensure that YAWAST continues to be useful in the future, and add as much value as possible to those performing security testing of web applications. If you are using the Gem version, simply run gem update yawast to get the latest version.

  • 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.

  • YAWAST 0.5 Released

    Today, I’ve released the latest version of YAWAST, a security scanner for web applications that provides basic information about the application, and performs common checks so that you can move on to the fun part of testing more quickly. YAWAST also remains the only tool I’ve found that can perform an accurate test for SWEET32. Here is the change log for version 0.5.0: #35 – Add check for SameSite cookie attribute #53 – Added checks for .