Technical details can be found at http://www.thc.org/thc-ssl-dos.
"We decided to make the official release after realizing that this tool leaked to the public a couple of months ago” said a member of THC who wants to remain anonymous.
The tool departs from traditional DDoS tools: It does not require any bandwidth and just a single attack computer ("bot”).
"We are hoping that the fishy security in SSL does not go unnoticed. The industry should step in to fix the problem so that citizens are safe and secure again. SSL is using an aging method of protecting private data which is complex, unnecessary and not fit for the 21st century.”, Says a THC member, referring to 3 major vulnerabilities disclosed in SSL over the past 3 years.
To list the 3 major vulnerabilities here THC explains: "In 2009 a vulnerability was disclosed that broke the encryption of SSL. De-facto making all SSL traffic unsafe. In 2011 various Certification Authorities got hacked. De-facto making all SSL traffic unsafe _again_.”
"We warned in 2002 about giving hundreds of commercial companies (so called Certification Authorities) a master key to ALL SSL traffic.”, says Fred Mauer, a senior cryptographer at THC. "Only a real genius can come up with such an idea!”.
"And last but not least the immense complexity of SSL Renegotiation strikes again in 2011 with the release of THC-SSL-DOS.”.
"It’s time for a new security model that adequately protects the citizens.”.
The THC-SSL-DOS tool is a Proof Of Concept tool to disclose fishy security in SSL. It works great if the server supports SSL Renegotiation. It still works if SSL Renegotiation is not supported but requires some modifications and more bots before an effect can be seen.
Our tests reveal that the average server can be taken down from a single IBM laptop through a standard DSL connection.
Taking on larger server farms who make use of SSL Load balancer required 20 average size laptops and about 120kbit/sec of traffic.
All in all superb results.
Interesting here is that a security feature that was supposed to make SSL more secure makes it indeed more vulnerable to this attack:
SSL Renegotiation was invented to renegotiate the key material of an SSL connection. This feature is rarely used. In fact we could not find any software that uses SSL Renegotiation. Yet it’s enabled by default by most servers.
An old saying comes true all over again: Complexity is the enemy of security.
"Renegotiating Key material is a stupid idea from a cryptography standpoint. If you are not happy with the key material negotiated at the start of the session then the session should be re-established and not re-negotiated”, says THC.
------------------------------------------------------
THC-SSL-DOS is a tool to verify the performance of SSL.
Establishing a secure SSL connection requires 15x more processing
power on the server than on the client.
THC-SSL-DOS exploits this asymmetric property by overloading the
server and knocking it off the Internet.
This problem affects all SSL implementations today. The vendors are aware
of this problem since 2003 and the topic has been widely discussed.
This attack further exploits the SSL secure Renegotiation feature
to trigger thousands of renegotiations via single TCP connection.
Download:
Windows binary: thc-ssl-dos-1.4-win-bin.zip
Unix Source : thc-ssl-dos-1.4.tar.gz
Use "./configure; make all install" to build.
Usage:
./thc-ssl-dos 127.3.133.7 443
Handshakes 0 [0.00 h/s], 0 Conn, 0 Err
Secure Renegotiation support: yes
Handshakes 0 [0.00 h/s], 97 Conn, 0 Err
Handshakes 68 [67.39 h/s], 97 Conn, 0 Err
Handshakes 148 [79.91 h/s], 97 Conn, 0 Err
Handshakes 228 [80.32 h/s], 100 Conn, 0 Err
Handshakes 308 [80.62 h/s], 100 Conn, 0 Err
Handshakes 390 [81.10 h/s], 100 Conn, 0 Err
Handshakes 470 [80.24 h/s], 100 Conn, 0 Err
Comparing flood DDoS vs. SSL-Exhaustion attack:
A traditional flood DDoS attack cannot be mounted from a single DSL connection.
This is because the bandwidth of a server is far superior to the
bandwidth of a DSL connection: A DSL connection is not an equal opponent to
challenge the bandwidth of a server.
This is turned upside down for THC-SSL-DOS: The processing capacity for
SSL handshakes is far superior at the client side: A laptop on a DSL
connection can challenge a server on a 30Gbit link.
Traditional DDoS attacks based on flooding are sub optimal: Servers are
prepared to handle large amount of traffic and clients are constantly
sending requests to the server even when not under attack.
The SSL-handshake is only done at the beginning of a secure session and
only if security is required. Servers are _not_ prepared to handle
large amount of SSL Handshakes.
The worst attack scenario is an SSL-Exhaustion attack mounted from
thousands of clients (SSL-DDoS).
Tips & Tricks for whitehats
1. The average server can do 300 handshakes per second. This would require
10-25% of your laptops CPU.
2. Use multiple hosts (SSL-DOS) if an SSL Accelerator is used.
3. Be smart in target acquisition: The HTTPS Port (443) is not always the
best choice. Other SSL enabled ports are more unlikely to use an SSL
Accelerator (like the POP3S, SMTPS, ... or the secure database port).
Counter measurements:
No real solutions exists. The following steps can mitigate (but not solve)
the problem:
1. Disable SSL-Renegotiation
2. Invest into SSL Accelerator
Either of these countermeasures can be circumventing by modifying
THC-SSL-DOS. A better solution is desireable. Somebody should fix
this.
---
//hackerz.do.am