SSL Renegotiation DOS attack – an iRule Countermeasure

The Attack

Earlier this year, a paper was posted to the IETF TLS working group outlining a very easy denial of service attack that a single client could use against a server.

http://www.ietf.org/mail-archive/web/tls/current/msg07553.html

The premise of the attack is simple: “An SSL/TLS handshake requires at least 10 times more processing power on the server than on the client”. If a client machine and server machine were equal in RSA processing power, the client could overwhelm the server by sending ten times as many SSL handshake requests as the server could service.  This vulnerability exists for all SSL negotiations; the only mitigation is the ratio between the two participants, which is why SSL acceleration is such a critical feature.

Because BIG-IP uses state-of-the-art hardware crypto-processors, it is certainly not vulnerable to a single attack from a single client.  However, it is quite conceivable that someone might very easily modify one of the botnets tools (such as the Low Orbit Ion Cannon that we saw used in the Wikileaks attacks) and thus the attack could become distributed.  

The Tool

After the above paper was published, a French hacking group calling itself “The Hacker’s Choice” (www.thc.org) published a simple, yet effective proof-of-concept tool and released it at DC4420.  The tool performs the attack against any server that allows SSL renegotiation.

http://www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz

% ./src/thc-ssl-dos 30.1.1.134 443;

     ______________ ___  _________
     \__    ___/   |   \ \_   ___ \
       |    | /    ~    \/    \  \/
       |    | \    Y    /\     \____
       |____|  \___|_  /  \______  /
                     \/          \/

http://www.thc.org

          Twitter @hackerschoice
Greetingz: the french underground
Handshakes 0 [0.00 h/s], 1 Conn, 0 Err
Handshakes 417 [455.74 h/s], 37 Conn, 0 Err
Handshakes 924 [515.36 h/s], 52 Conn, 0 Err
Handshakes 1410 [486.44 h/s], 62 Conn, 0 Err
Handshakes 1916 [504.41 h/s], 71 Conn, 0 Err
...

The tool itself is about 700 lines of readable C code.  Actually, it looks better than your typical hack-tool so I have to give “The Hacker’s Choice” props on their craftmanship.  The attack tool ramps up to 400 open connections and attempts to do as many renegotiations on each connection as it can.  On my dedicated test client, it comes out to 800 handshakes per second (or 2 per connection per second).

 

Moment of Irony

When you first run the tool against your BIG-IP virtual server, it might say “Server does not support SSL Renegotiation.”  That’s because everyone, including F5, is still recovering from last year’s SSL renegotiation vulnerability and by default our recent versions disable SSL renegotiation.  So in order to do any testing at all, you have to re-enable renegotiation.  But this also means that by default, virtual servers (on 10.x) are already not vulnerable unless they’ve explicitly re-enabled renegotiation.  The irony is that the last critical SSL vulnerability provides some protection against this new SSL vulnerability. 

 

The iRule Countermeasure

Enter DevCentral.  After setting up the attack lab, we asked Jason Rahm (blog) for his assistance.  He put together a beautiful little iRule that elegantly defeats the attack.  Its premise is simple:

If a client connection attempts to renegotiate more than five times in any 60 second period, that client connection is silently dropped.

By silently dropping the client connection, the iRule causes the attack tool to stall for long periods of time, fully negating the attack.  There should be no false-positives dropped, either, as there are very few valid use cases for renegotiating more than once a minute.

The iRule

when RULE_INIT {
  set static::maxquery 5
  set static::seconds 60
}
when CLIENT_ACCEPTED {
  set rand [expr { int(10000000 * rand()) }]
}
when CLIENTSSL_HANDSHAKE {
  set reqno [table incr "reqs$rand"]
  table set -subtable "reqrate:$rand" $reqno "ignored" indefinite $static::seconds
  if { [table keys -count -subtable "reqrate:$rand"] > $static::maxquery } {
    after 5000
    drop
  }
}
when CLIENT_CLOSED {
  table delete reqs$rand
  table delete –subtable reqrate:$rand –all
}

With the iRule in place, you can see its effect within a few seconds of the test restarting.

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err
Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err
Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err
Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err
Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

The 400 connections each get their five renegotiations and then the iRule waits five seconds (to ack any outstanding client data) before silently dropping the connection.  The attack tool believes the connection is still open, so it stalls.  Note that the test had to be restarted, because the iRule doesn’t apply to existing connections when it’s attached to a virtual server.  Take that into account if you are already under attack.

Its understandable if you are thinking “that’s the coolest 20-line iRule I’ve ever seen, I wish I understood it better.”   Jason also provided a visual workflow to elucidate its mechanics.

iRule DDOS countermeasure workflow

Conclusion

At a meeting earlier this year here in Seattle we were talking about the previous Renegotiation flaw. The question was posed “What is the next vulnerability that we’re all going to slap our foreheads about?”  This particular attack falls into that category.  Its a simple attack against a known property of the protocol.  Fortunately, BIG-IP can leverage its hardware-offload or use countermeasures like this iRule to counter the attack. 

There are two take-aways here: first, even long-established and reviewed protocols like SSL/TLS can be used against you and second, iRules are pretty sweet!

And thanks again, to Jason Rahm for his invaluable assistance!