Pages

Subscribe:

The THC SSL DoS Threat


 Ever since computers became ubiquitous and affordable they have attracted malicious users as well as those who use computers for altruistic purposes. These malicious users– sometimes called “black hats” or “crackers”– often try and take servers, desktops or entire networks offline using something called a Denial of Service attack or “DoS.”
    There are two main kinds of DoS: a Distributed Denial of Service attack, where multiple computers called “Slaves” or “zombies” flood the target with data such as ICMP pings, UDP packets, TCP SYN packets or a wide array of other packets, with the goal of sending so much data that the target crashes; and the Single node or “DoS” attack, in which a malformed packet is sent once or until the server goes offline.
    In the early days of the Internet one computer with enough bandwidth could perform a flood attack, but now that most servers are in server farms, have superior bandwidth, load balancers and other network stress mitigation devices it is no longer feasible for one node to flood a server to any effect. But single node Denial of Service attacks are still a large threat because of an attack known as resource exhaustion. This type of attack, as its name suggests, works by forcing the server to do functions that take up a lot of resources over and over again until it runs out of resources to do that function with (often RAM and CPU power) and then crashes or stops doing its intended function. For HTTP (the protocol used for website access), a tool exists called Slowloris which half opens many HTTP connections and keeps them half open preventing non-malicious users from connecting from the server. But is easy to stop. For older versions of Apache, a tool called Apache killer is available, but it does not work on the most recent version of Apache and various IDS/IPS (Intrusion Detection and Intrusion Protection) solutions can stop it.
    Recently a security collective called The Hacker’s Choice (or THC) released a tool that can perform a Resource Exhaustion Attack on the SSL protocol. This article will explain how this attack works and how to mitigate it.
    SSL, or Secure Socket Layer, is a protocol designed for encrypted and authenticated network sockets across the Internet. While the authentication of SSL is vulnerable to Man-In-The-Middle attacks, as discovered by Moxie Marlinspike, such as sslstrip and sslsniff, the encryption on the server is very strong—so strong, in fact, that it is vulnerable to a Resource Exhaustion Attack. This vulnerability—known as the THC SSL DoS exploits the fact that while it is trivial for a client to generate the proper keys and authenticators to initiate a SSL connection such as that on a HTTPS (HTTP but SSL encrypted) website, it takes 15 times more computing resources for a server to generate its keys and authenticators. This means that if an attacker were to open one or more SSL sockets to a server using an SSL encrypted protocol, it would waste a tremendous amount of resources on that server.
    That is how the THC SSL-DOS tool works: it opens up as many SSL sockets as the attacker requests and has each socket re-key/re-authenticate until the server runs out of memory and computing power to continue operating, resulting in a crash. The THC SSL-DOS program is extremely simple to use: there is a windows binary, and source code with a make file that is available for UNIX users.
Compiling is straight forward.
Run the following commands in terminal:
./configure && make && sudo make install"
On Linux all it requires is OpenSSL and its development files to run.
Running the program is as simple as running the following command:
./thc-ssl-dos 127.3.133.7 443 --accept
Where 127.3.133.7 is the IPV4 address of the target and 443 is port number of a program that makes use of SSL with key renegotiation enabled. The ‘–accept’ indicates we agree to the terms of service of the tool.
To do the SSL-DoS on servers with key renegotiation disabled you must run the following code in a terminal emulator on linux:
thc-ssl-dosit() { while :; do (while :; do echo R; done) | openssl s_client -connect 127.0.0.1:443 2>/dev/null; done }
for x in `seq 1 100`; do thc-ssl-dosit & done
Where 127.0.0.1 is the IPV4 address of the target and 443 is the port number of the vulnerable service. Now let us field test this attack we will target an Apache 2.2.14 server on backtrack 5 R1 with mod_ssl at its latest version. Let’s see if the original Proof Of Concept tool released by THC works:


Hmmm, it seems that modern implementations of mod_ssl by default disable key renegotiation. This means that the original implementation of this vulnerability is ineffective, but we are not without options. If you recall, there is still a way to exploit this vulnerability if key renegotiation is disabled. A function that opens say 100 connections and leaves them open (similar to the Slowloris tool) should DoS a SSL server.
Let’s see how the code above works:

On my mid-range laptop as both the attacker and the target it was able to Dos itself in 10 to 15 minutes. Though on various live targets it may be faster or slower depending on both party’s bandwidth, performance of both the attacker’s and the target’s hardware and what countermeasures are in place.
This attack is not limited to HTTPS– POP3S and SMTPS (secure email) and even secure database connections that make use of SSL are vulnerable.
    While there is no way to 100% eliminate the vulnerability THC-SSL DOS exploits, there are several ways to mitigate it. The simplest is to limit or disable SSL key renegotiation. This makes it harder for one computer to take an SSL server off line because they cannot have each socket re-key but they can still open new sockets, which requires a key to be generated. IDS/IPS solutions may be able to detect THC-SSL DOS packets on the wire and kill them but most IDS/IPSs do not have a good track record when it comes to analyzing encrypted packets. Another mitigation technique is to outfit the server with a SSL accelerator, which is a piece of hardware designed to optimize servers for SSL computation, making it take many more computers to effectively implement a SSL DOS. However, none of these defensive techniques by themselves will eliminate the threats posed by SSL Denial of Service.
    Probably your best bet when it comes to defending your SSL servers is to take the security in depth approach and implement all of these countermeasures. Unfortunately, the vulnerability this tool exploits is difficult to defend against because the vulnerability lies in the SSL protocol its self, not an implementation of that protocol. This means that unless the SSL protocol is re-written or all Servers that make use of it are given unlimited computing power, the threat presented by SSL DoS will still exist.

Sources: