Test your server for the Heartbleed bug(filippo.io)
filippo.io
Test your server for the Heartbleed bug
http://filippo.io/Heartbleed/
14 comments
Very cool! Tested my site before and after a patch, and it recognized the fix. A quick UI tip: you should give some indicator while the test is running. I couldn't tell anything was happening while I waited. Even just a spinner gif of some kind.
Here's a tool I wrote to test locally: https://github.com/titanous/heartbleeder
I get these errors:
/usr/lib/go/src/pkg/github.com/titanous/heartbleeder/tls/cipher_suites.go:66: undefined: cipher.AEAD
/usr/lib/go/src/pkg/github.com/titanous/heartbleeder/tls/cipher_suites.go:133: undefined: cipher.AEAD
/usr/lib/go/src/pkg/github.com/titanous/heartbleeder/tls/cipher_suites.go:149: undefined: cipher.AEAD
/usr/lib/go/src/pkg/github.com/titanous/heartbleeder/tls/handshake_server.go:556: undefined: crypto.PublicKey
/usr/lib/go/src/pkg/github.com/titanous/heartbleeder/tls/tls.go:93: undefined: net.Dialer
Am I missing something?
Am I missing something?
I'm not familiar with go, can you tell me how to run this?
EDIT: Got it working by changing "github.com/titanous/heartbleeder/tls" to "./tls" and running "go run heartbleeder.go example.com"
EDIT: Got it working by changing "github.com/titanous/heartbleeder/tls" to "./tls" and running "go run heartbleeder.go example.com"
You can run `go get github.com/titanous/heartbleeder/tls`. Then `go build` will create a static executable called `heartbleeder`.
FYI, I tested herokuapp.com's SSL support. It reports as vulnerable. :(
On the bright side, since such servers are Heroku's inbound load-balancers, individual app dyno secrets in RAM probably aren't at risk. But, impersonating herokuapp.com, decoding its sessions, or viewing fragments of arbitrary other traffic through the same server may all be possible.
Heroku reports they're aware and working on it: http://status.heroku.com
On the bright side, since such servers are Heroku's inbound load-balancers, individual app dyno secrets in RAM probably aren't at risk. But, impersonating herokuapp.com, decoding its sessions, or viewing fragments of arbitrary other traffic through the same server may all be possible.
Heroku reports they're aware and working on it: http://status.heroku.com
I thought it was broken since nothing happened when I clicked. Then I looked again and had a result.
I'm also getting this error:
I'm also getting this error:
Error: not well-formed
Source File: http://heartbleed.filippo.io/bleed/foo.com
Line: 1, Column: 1
Source Code:
{"code": 1, "data": ""}Yep sorry the server is being hammered.
Loading bar implemented!
Loading bar implemented!
Yeah, I had the same issue. A spinning wheel while it's waiting would be helpful.
Other than that, great work @ars!
Other than that, great work @ars!
[deleted]
I hope you're saving the results so we can shame companies who don't revoke their certs.
Also caching the results should also lighten the load on your server significantly since many people are probably checking common websites.
Also caching the results should also lighten the load on your server significantly since many people are probably checking common websites.
Ok, deployed on a m1.xlarge! You should see the site responsive now.
Still down, going for a Load Balancer. Should have optimized this more :(
If you want to offer up the code on Github I'm sure plenty of people would be happy to put up some mirrors to spread the fun/pain.
Red Hat rocks. CVE submitted 2014-04-07, errata release 2014-04-07. Nice.
Here's another as the site is getting hammered:
http://possible.lv/tools/hb/
http://possible.lv/tools/hb/
Not quite as good though. The above will let just know whether you have the extension, but not whether you have the patched version, which can also be done from the CLI by using:
echo -e "quit\n" | openssl s_client -connect server.com:443 -tlsextdebug 2>&1 | grep heartbeat
(as suggested someone in another thread here). That will answer Yes to a patched OpenSSL.
The OP's site actually attempts a (mild?) exploit of this.
(as suggested someone in another thread here). That will answer Yes to a patched OpenSSL.
The OP's site actually attempts a (mild?) exploit of this.
Fair enough, thanks for the explanation. :)
Awesome, thanks for this.
Any chance you would open source this?
Any chance you would open source this?
I'm going to say.... not to do this just yet.
I mentioned in another thread today that perhaps having the source code for script-kiddies to start attacking everything might not be the best thing to do at this time. I think it's great to just have a website like this to test the vulnerability. It would also be nice if someone like Google could host the page so it won't get knocked down by too many requests as I'm sure will be happening for the next few days.
I mentioned in another thread today that perhaps having the source code for script-kiddies to start attacking everything might not be the best thing to do at this time. I think it's great to just have a website like this to test the vulnerability. It would also be nice if someone like Google could host the page so it won't get knocked down by too many requests as I'm sure will be happening for the next few days.
Sure, because letting one central source get to compile a list of all the vulnerable sites sure sounds like a fantastic idea...
I'll take my chances with one site having the list rather than open-sourcing it and having every script-kiddie dumping RAM out of all the sensitive systems of the interwebz.
(Sidenote: Bitcoin exchanges, please for the love of all that is good... don't start getting owned by this. UPDATE NOW)
(Sidenote: Bitcoin exchanges, please for the love of all that is good... don't start getting owned by this. UPDATE NOW)
What, you mean like this?
https://gist.github.com/hlein/10121981
What, praytell, is a script kiddie going to do with that, other than oogle at the word "vulnerable"?
https://gist.github.com/hlein/10121981
What, praytell, is a script kiddie going to do with that, other than oogle at the word "vulnerable"?
Sounds a lot like anti-sec to me...
Running masscan would allow to compile a even more comprehensive list.
I have a bunch of servers on Ubuntu 12.04LTS. Did the test. Came back as vulnerable. Then did an apt-get upgrade, which upgraded a bunch of SSL services. Did the test again. Still vulnerable.
What else should I do?
What else should I do?
Restart the services. Run:
grep -l 'libssl.*deleted' /proc/*/maps
And restart all processes listed.On Ubuntu 12.04LTS you need to upgrade both 'libssl1.0.0' and 'openssl' - I’d check that the version of both is: 1.0.1-4ubuntu5.12
And then restart everything that comes back from a
And then restart everything that comes back from a
sudo lsof -n | grep ssl | grep DELExcellent! That did the trick. It was nginx and percona that also had to be restarted.
Found some Facebook servers that are vulnerable for the bug: http://pastebin.com/dmYYpx2y
Good stuff. I forgot to patch a server of mine...