Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Attack Tool Exploits SSL Renegotiation Bug

Soulskill posted more than 2 years ago | from the increment-arms-race dept.

Encryption 47

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."

cancel ×

47 comments

Sorry! There are no comments related to the filter you selected.

FP to bring back Taco! (-1)

Anonymous Coward | more than 2 years ago | (#37840810)

And John Katz too!

1st off... it's not SSL, it's TLS you dolts. (-1)

Anonymous Coward | more than 2 years ago | (#37840882)

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.

Re:1st off... it's not SSL, it's TLS you dolts. (0)

Anonymous Coward | more than 2 years ago | (#37840982)

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?

Re:1st off... it's not SSL, it's TLS you dolts. (1)

Anonymous Coward | more than 2 years ago | (#37841018)

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.

Re:1st off... it's not SSL, it's TLS you dolts. (-1)

Anonymous Coward | more than 2 years ago | (#37841132)

What I mean is: THIS SHIT'S NOT HARD, FIX THE DAMN THING YOU CHEAP BASTARDS.

If it's not hard, then where is the patch you made?

Gray list update (0)

Anonymous Coward | more than 2 years ago | (#37840900)

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

Re:Gray list update (1)

yakatz (1176317) | more than 2 years ago | (#37845508)

Great idea. Submit your regex back so that everyone can use it.
https://github.com/fail2ban/fail2ban [github.com]

NON ISSUE (5, Informative)

Anonymous Coward | more than 2 years ago | (#37840906)

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 [nist.gov]

Re:NON ISSUE (1)

BagOCrap (980854) | more than 2 years ago | (#37842052)

I recently noticed that myself. Had to re-enable SSL renegotiation via about:config so I could login to various secure websites with my smartcard.

Re:NON ISSUE (1)

HTH NE1 (675604) | more than 2 years ago | (#37845106)

Speaking of you, doesn't Woot! invite this kind of attack at least once a month?

SSL renegotiation not required (2)

CanEHdian (1098955) | more than 2 years ago | (#37840998)

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.

Re:SSL renegotiation not required (2)

d4fseeker (1896770) | more than 2 years ago | (#37841252)

LOIC DDOS' mostly relies on large bandwiths to disable their target - regardless of the server's processing capacity.
This issue can be tackled with 3 lines of iptables (ratelimit connections/time and concurrent connections), at least for low capacities.
Most clients are perfectly capable of HTTP keep-alive and thus we can set the limit significantly lower on HTTPS than on HTTP; all we need is a reverse proxy between Apache and the clients or apache mpm_event.

Facebook API now requires SSL/TLS (2)

crazybit (918023) | more than 2 years ago | (#37841008)

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.

Re:Facebook API now requires SSL/TLS (0)

Anonymous Coward | more than 2 years ago | (#37841120)

Nov. 5?

Re:Facebook API now requires SSL/TLS (0)

Anonymous Coward | more than 2 years ago | (#37841892)

Wait - you're complaining that they're forcing the migration to HTTPS?

Is it a Bug? (3, Interesting)

allo (1728082) | more than 2 years ago | (#37841020)

Sounds more like a protocol flaw than a bug.

Re:Is it a Bug? (0)

Anonymous Coward | more than 2 years ago | (#37847880)

Is it a protocol flaw that you can make as many HTTP requests as you want in a keepalive connection? Save of course, optional server-side forced closures.

Apache Server Settings (4, Informative)

triemer (569734) | more than 2 years ago | (#37841144)

#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 [apache.org] 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.

Re:Apache Server Settings (0)

Anonymous Coward | more than 2 years ago | (#37841402)

how can a real DoS attacks that affects a significant percentage of the web servers be considered overhyped? your facebook might be unaffected but all sites using client-side certificates such as your bank and your corporate website are

Re:Apache Server Settings (1)

Anonymous Coward | more than 2 years ago | (#37841450)

how can a real DoS attacks that affects a significant percentage of the web servers be considered overhyped?

Here is how:

#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 [apache.org] 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.

Or since you obviously didn't get it the first time- this is old news, old exploit, old old old. The only news here is that somebody released a new tool to do it for you. Or in other words, the haxxors are using slashdot as a marketing platform again.

Re:Apache Server Settings (0)

Anonymous Coward | more than 2 years ago | (#37846252)

#2 is invalid. Even if you turn re-negoation off you are still vulnerable simply by using SSL.

Re:Apache Server Settings (0)

Anonymous Coward | more than 2 years ago | (#37844654)

You're wrong, wrong and wrong. Everything in your post is about an older SSL issue, which has nothing to do with this current DoS one. You can't even disable SSL renegotiations with that setting, you can only disable INSECURE renegotiations.

This was released few days ago (0)

Anonymous Coward | more than 2 years ago | (#37841240)

I've already had my fun with it. It took out over 1/2 of the stuff I hit with it.

Who needs tools when we have wget? (2)

Mereel (154801) | more than 2 years ago | (#37841262)

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.

Analysis of this from TLS WG Chair (1)

cullenfluffyjennings (138377) | more than 2 years ago | (#37841272)

Good analysis of this at
http://www.educatedguesswork.org/2011/10/ssltls_and_computational_dos.html [educatedguesswork.org]

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.

Re:Analysis of this from TLS WG Chair (1)

Mysteray (713473) | more than 2 years ago | (#37849018)

It's a real attack and a real DoS vector. SSL/TLS is definitely weak in this regard.

But it's not new and it doesn't have much to do with renegotiation.

yawn (0)

Anonymous Coward | more than 2 years ago | (#37841326)

yawn yawn

https not the only thing to test (1)

jroysdon (201893) | more than 2 years ago | (#37841370)

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.

!New (0)

Anonymous Coward | more than 2 years ago | (#37841388)

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.

Re:!New (1)

gl4ss (559668) | more than 2 years ago | (#37841472)

how come there's no flood protection?

per ip it would cause some big natted networks(looking at you cellphone operators) to get blacklisted I suppose but still..

It worked for the wrong reason. (2)

WaffleMonster (969671) | more than 2 years ago | (#37841476)

This tool excels in finding bugs and session cache synchronization deadlocks in the latest daily snapshots of openssl.. I found two within 2 minutes..

Re:It worked for the wrong reason. (1)

Tomato42 (2416694) | more than 2 years ago | (#37846578)

Oh, so it's like siege, but for SSL? neat!

..Researchers, Hackers, Authors. Now who? (1)

Barryke (772876) | more than 2 years ago | (#37841622)

..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."

Re:..Researchers, Hackers, Authors. Now who? (0)

Anonymous Coward | more than 2 years ago | (#37841940)

Coincidentally these Hackers happen to do Research and Author software as a result of that research...

iptables (3, Informative)

ls671 (1122017) | more than 2 years ago | (#37841712)

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

Re:iptables (0)

Anonymous Coward | more than 2 years ago | (#37842250)

My eyes are bleeding - why is iptables still so damn fugly? I mean, by now the developers have seen IPFW and PF, amongst others, yet they still keep a tool that looks like a cat was dancing on the keyboard whilst the perl interpreter was running.

Fix it now!

Re:iptables (0)

Anonymous Coward | more than 2 years ago | (#37842406)

Fix it you and illuminate all of us.
Put up or shut up.

Re:iptables (1)

higuita (129722) | more than 2 years ago | (#37842918)

hey, you can always post the same script in IPFW/PF so we can compare...

just in case you didnt read. that is (part of) a script, full of long variable names... yes, their names could be better, the rule_j14 is weird name, the multi-line makes it harder to read... bug again, this is clearly just a small part of s bigger script and the user ls671 didnt wanted to clean it up... simply because the idea is there, adapt that for your own use.

Re:iptables (0)

Anonymous Coward | more than 2 years ago | (#37846052)

My eyes are bleeding - why is iptables still so damn fugly? I mean, by now the developers have seen IPFW and PF, amongst others, yet they still keep a tool that looks like a cat was dancing on the keyboard whilst the perl interpreter was running.

Fix it now!

Translation: I'm too lazy to get off my ass and learn iptables. There are pretty GUIs included with most linux distributions you might be happier with.

Re:iptables (0)

Anonymous Coward | more than 2 years ago | (#37849154)

Translation: I know FreeBSD or similar and have used a good but easy to configure firewall. Why in the hell would I want to run Linux and use iptables?

Let's see... FreeBSD, OpenBSD, NetBSD, DragonFly BSD, MidnightBSD, MirBSD and Mac OS X all have firewalls that are easier to use.

Re:iptables (0)

Anonymous Coward | more than 2 years ago | (#37876458)

Try Shorewall. Using IPtables directly is rather low-level and indeed very ugly. C++-with-Perl-Regex ugly.

Re:iptables (1)

sgt scrub (869860) | more than 2 years ago | (#37843182)

for redirport in 25 587 995 21 113 22 563 119

Not allowing any 443 (HTTPS) traffic should do the trick :P IMHO I would rethink allowing ftp and ssh from the outside world.

hmmmm (1)

sgt scrub (869860) | more than 2 years ago | (#37842900)

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.

Re:hmmmm (1)

sgt scrub (869860) | more than 2 years ago | (#37843462)

It looks like PSH is set ON the renegotiation packet.

08:54:25.852659 IP localhost.localdomain.51515 > localhost.localdomain.6060: Flags [P.], seq 1:62, ack 1, win 513, options [nop,nop,TS val 19313608 ecr 19313608], length 61
08:54:25.852793 IP localhost.localdomain.51516 > localhost.localdomain.6060: Flags [P.], seq 1:62, ack 1, win 513, options [nop,nop,TS val 19313609 ecr 19313609], length 61

Releasing this so called tool (1)

Stan92057 (737634) | more than 2 years ago | (#37843814)

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?

Re:Releasing this so called tool (0)

Anonymous Coward | more than 2 years ago | (#37844582)

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?

Because shining a light on security flaws and potential attack vectors is one of the best motivators for the community as a whole to address the problem.

I'm the guy who found CVE-2009-3555 renego bug (1)

Mysteray (713473) | more than 2 years ago | (#37848976)

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 [educatedguesswork.org]

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>