Slashdot Mirror
New Attack Tool Exploits SSL Renegotiation Bug
Trailrunner7 writes "A group of researchers has released a tool that they say implements a denial-of-service attack against SSL servers by triggering a huge number of SSL renegotiations, eventually consuming all of the server's resources and making it unavailable. The tool exploits a widely known issue with the way that SSL connections work. The attack tool, released by a group called The Hacker's Choice, is meant to exploit the fact that it takes a lot of server resources to handle SSL handshakes at the beginning of a session, and that if a client or series of clients sends enough session requests to a given server, the server will at some point fail. The condition can be worsened when SSL renegotiation is enabled on a server. SSL renegotiation is used in a number of scenarios, but most commonly when there is a need for a client-side certificate. The authors of the tool say that the attack will work on servers without SSL renegotiation enabled, but with some modifications."
Another thing to add to fail2ban... And then grey list the source ... Should only impact sites that can't be agile.
-
Help save SOA on Direct TV http://goo.gl/4ZLEa
This is like the 3rd or 4th SSL renegotation bug. The last one had only one fix: disable SSL renegotiation altogether. Firefox helped speed it along, but marking ssl servers that allowed renegotiation as insecure. And openssl released an updated version to drop support for it.
So pretty much every SSL server has renegotiation disabled.
IIRC it was this bug: CVE-2009-3555
The attack described isn't a problem with a specific cipher or hash. How is your encryption system's ability to change ciphers and hashes relevant?
From what I have read, the renegotiation part only made the tool more effective, such that under optimal conditions a single laptop on ADSL was enough to bring down a server on a 30 gigabit connection. An SSL handshake still requires server resources, so perhaps we'll see this used in DDoS tools like LOIC.
When the copyright term is "forever minus a day", live every day like it's the last.
Considering Facebook API now requires SSL/TLS for Facebook Apps, many servers had to turn on HTTPS just for this. It's just a matter of time until we see this widely exploited.
- Human knowledge belongs to the world
2ndly, that crap's just plain broken. Look, when I heard MD5 (and later SHA1) MIGHT be vulnerable to some kinds of attacks, I just upgraded to a better hash with no known exploits.
The sooner we adopt IPv6 & DNSSEC the better. Oh, it's expensive? Well, who's fault is it that your companies didn't PLAN TO UPGRADE... EVER!?
Just for the hell of it I wrote an encryption system & protocol for my game's network protocol that's extensible to whatever block length you want, and accepts any cipher -- even "ONE WAY" ciphers (hashes) -- resulting in PSK + PKI reversible encryption and identity services. Right now it's running on SHA256, and I just drop in a SHA512 algorithm's function pointer when I want to upgrade. The protocol auto negotiates down to the "minimum allowed" -- Wait -- What I mean is: THIS SHIT'S NOT HARD, FIX THE DAMN THING YOU CHEAP BASTARDS.
Cry me a river, I've got a bridge to test out.
Oh my bajeebus! You figured out howto use dependency injection and delegates! Get this person a gold star and a green gumball! Now get this to work outside of your walled garden, across multiple Arch's, OS's, and software in a way that equally benefits all, write the rfc and get it promoted into a standard.
Sounds more like a protocol flaw than a bug.
#1 - this has been a topic of conversation for a while #2 - per documentation at apache (Yes, I dare say a majority of web servers are running apache) There is a flag that can turn renegotiation on/off http://httpd.apache.org/docs/2.0/mod/mod_ssl.html Available in httpd 2.0.64 and later, if using OpenSSL 0.9.8m or later The default setting is: SSLInsecureRenegotiation off #3 - which leads to the conclusion that this is overhyped.
I've already had my fun with it. It took out over 1/2 of the stuff I hit with it.
for i in {1..10}; do (while true; do wget https://poor.server; done)& done
A dedicated tool may be even more efficient, but bash and wget do the trick too.
Good analysis of this at
http://www.educatedguesswork.org/2011/10/ssltls_and_computational_dos.html
As far as I can tell, Rescorla is trying to polity say this attack is crap. Shocking, yet another low grade hack trying to up publicity.
yawn yawn
pop3s, imaps, smtps, etc. anything that uses ssl should be tested and is probably vuln (quick dovecot & sendmail tests were). I'd really like to see the "private" code that works w/o renegotiation in order to test against https.
This isn't new, hell, I made a nearly identical tool as part of my final year project for my IT Security degree. Not hard to identify a system's most resource intensive procedure and cause the system to repeat it as much as possible, whether is be a search frontend to a SQL database which executes a particularly intensive query or file descriptor exhaustion. Identify the limitations and weaknesses which cause a fail state and exploit them, tada, DoS.
This tool excels in finding bugs and session cache synchronization deadlocks in the latest daily snapshots of openssl.. I found two within 2 minutes..
..Researchers, Hackers, Authors. Sounds like lots of people are involved, or are they all hackers (since they simply released it in the wild, i wouldn't say researchers)
"A group of researchers has released a tool that they say implements a denial-of-service attack against SSL servers by triggering a huge number of SSL renegotiations, eventually consuming all of the server's resources and making it unavailable. The tool exploits a widely known issue with the way that SSL connections work. The attack tool, released by a group called The Hacker's Choice, is meant to exploit the fact that it takes a lot of server resources to handle SSL handshakes at the beginning of a session, and that if a client or series of clients sends enough session requests to a given server, the server will at some point fail. The condition can be worsened when SSL renegotiation is enabled on a server. SSL renegotiation is used in a number of scenarios, but most commonly when there is a need for a client-side certificate. The authors of the tool say that the attack will work on servers without SSL renegotiation enabled, but with some modifications."
Hivemind harvest in progress..
INTIF2=vmnet1
PORTFWIP2=192.168.4.38
$IPTABLES -A rule_j14 -m limit --limit 120/minute --limit-burst 50 -j ACCEPT
$IPTABLES -A rule_j14 -m limit --limit 1/minute -j LOG --log-prefix "wharf"
$IPTABLES -A rule_j14 -j DROP
let i=0
while [ $i -lt $EXTIF_LIST_SIZE ]
do
for redirport in 25 587 995 21 113 22 563 119
do
$IPTABLES -A INPUT -i ${EXTIF_LIST[i]} -p tcp --dport ${redirport} \
-m state --state NEW -m limit --limit 1/minute \
-j LOG --log-prefix "wharf wharf"
$IPTABLES -A INPUT -i ${EXTIF_LIST[i]} -p tcp --dport ${redirport} \
-m state --state NEW -j DROP
$IPTABLES -A FORWARD -i ${EXTIF_LIST[i]} -o $INTIF2 -d ${MAIL_FW_IP[i]} -p tcp \
--dport $redirport -m state --state NEW -j rule_j14
$IPTABLES -A FORWARD -i ${EXTIF_LIST[i]} -o $INTIF2 -d ${MAIL_FW_IP[i]} -p tcp \
--dport $redirport -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A PREROUTING -t nat -p tcp -d ${EXTIP_LIST[i]} --dport $redirport \
-m state --state NEW -m hashlimit --hashlimit 60/hour --hashlimit-burst 15 \
--hashlimit-htable-expire 3600000 --hashlimit-mode srcip,dstport \
--hashlimit-name j14-${redirport} \
-j DNAT --to ${MAIL_FW_IP[i]}:$redirport
done
let i=$i+1
done
Everything I write is lies, read between the lines.
Don't SSL renegotiations have, or follow, packets with the PSH flag set? I'll have to check it out; but, I seem to remember it looks like one or the other. If someone knows off the top of their head it would be helpful.
Having to work for a living is the root of all evil.
Releasing this so called tool is just a hand out for the criminals that will use it. Why release such a dangerous tool to the public?
Jack of all trades,master of none
This is not a bug. We fixed renegotiation with the RFC 5746 RI extension! That said, SSL has long been known to impose more work on the server than on the client and renegotiations are no different than initial handshakes in this respect.
Servers that accept client-initiated renegotiation make things slightly more efficient for the DoS attacker, it saves him maybe three packets. More significantly, it may bypass mitigations that are only looking for TCP SYN packets. But the attacker's mileage will vary.
Eric Rescorla (SSL/TLS RFC author) has a good blog post about the issue. http://www.educatedguesswork.org/2011/10/ssltls_and_computational_dos.html