Today the German hacker group “The Hacker’s Choice” officially released a new DDoS tool. The tool exploits a weakness in SSL to kick a server off the Internet.
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: http://www.thc.org/thc-ssl-dos
- Reverse SSL: http://eprint.iacr.org/2006/212.pdf
- DDoS explained: http://en.wikipedia.org/wiki/Denial-of-service_attack
- http://www.ietf.org/mail-archive/web/tls/current/msg07553.html
thehackerschoice 
Renegotiation is used for client side authentication (client side certs) and smart cards. That way the cert or data is not sent in clear text.
The comment goes beyond of what our tool is about (DDoS). I appreciate your comment and the security of SSL surely requires further discussions.
It’s Security Protocol lesson #1: Client side authentication credentials must not be send in clear. This includes usernames, passwords or _client side certificates_. SSL by default does send client side certificates in clear. It’s a fault in the protocol.
Some application (like TOR and some smart cards) use a ‘trick’ (SSL-Renegotiation) to enabled encryption before client side authentication credentials are send. SSL-Renegotiation is used in the scenario because the SSL Protocol does not offer any other way of sending client side authentication credentials in a ‘secure’ way.
It is overkill, complex and merely a dirty trick to use SSL-Renegotation to protect client side authentication credentials.
A good security protocol should not allow that client side credentials are send in clear by default without having to use special tricks.
A client certificate is a public object, you can’t compare it to a password.
[…]
Finally, your tool is non efficient, as you could have used canned TLS messages, avoiding parsing of TLS replies and crypto operations. For example, if the server has a DSA key, then the client uses more CPU than the server, because you verify the server signature.
With constant messages, and a dumb client, you could:
– avoid the whole crypto stuff on client side to verify server authentication
– generate random data for key exchange (that’s free if the the block is created once and reused), and let the server perform the heavy crypto work, it will fail, but you don’t care
– have something lighter, that doesn’t rely on OpenSSL or any other equivalent library
I did not compare a password to a client certificate. I am saying that both require protection.
A security protocol should not leak the identity or other authentication credentials.
Yeah, I agree that sending raw TLS messages would make the impact even better. From here on the attack can only get better but not worse.
THC-SSL-DOS is not the ultimate DDoS tool and was never intended to be. The tool demonstrates vulnerabilities beyond SSL.
The point we want to make with THC-SSL-DOS is that DDoS does not always imply huge traffic and flooding of the target that can only be executed from a large bot network.
DDoS can come in many different forms.
We call the DDoS attacks that do not require a large bot network SMART DDoS.
The Internet is well protected against traffic based DDoS. It’s vulnerable against SMART DDoS.
The next step from here is to think about SMART DDoS against SSH or other crypto protocols, enhance the attack or think about other SMART DDoS attacks. For example some search requests [containing complex regular expressions] on amazon take significantly longer than other requests…and so on…and so on….
Smart DDoS attacks can take down large servers that were impossible to be taken down by traffic based DDoS attacks (LOIC etc).
Keep Hacking,
THC
its not a ddos tool, its a dos tool. single machine is not distributed
first paragraph makes you sound stupid
It’s a DDoS tool and not a DoS tool. The impact of a DoS tool does not change if attacked from multiple sources at the same time. Ping-of-death is a good example here: It does not matter if attacked from 1 host or 1,000 hosts, the impact is the same: The server dies. With THC-SSL-DOS the impact changes if the attack is carried out from multiple hosts. It’s thus by definition a DDoS tool.