

Heartbleed vulnerability tester - mholt
https://github.com/titanous/heartbleeder

======
teoruiz
The one posted in a previous thread is significantly more clarifying. It
features a web server and a command line version:

* Live version: [http://filippo.io/Heartbleed/](http://filippo.io/Heartbleed/)

* Code: [https://github.com/FiloSottile/Heartbleed](https://github.com/FiloSottile/Heartbleed)

~~~
chaosmonkey
We have the same version of OpenSSL on 2 different test nodes.

OpenSSL 1.0.1e-fips

One came up positive, One negative. Shouldn't it be negative for both?

~~~
Ronnie76er
I think it's also possible you are getting a false positive, because it's
timing out or whatever. The newer version of that check tells you if it's
timing out.

~~~
chaosmonkey
Tried again. Still get the same result.

------
k2enemy
I'm surprised that I haven't been contacted by any sites yet with advice to
reset my password. Is it the case that not many sites were actually running
1.0.1? Or are they just patching, creating new certs, and calling it a day?

~~~
zhemao
I may be wrong, but I think that your credentials with a site are only
vulnerable if they had the heartbeats extension turned on.

------
rubiquity
Tools like this and FiloSottile's[0] are great. But given how serious of a
vulnerability this is, anything short of manually verifying your OpenSSL
version is probably not enough.

0 -
[https://github.com/FiloSottile/Heartbleed](https://github.com/FiloSottile/Heartbleed)

~~~
spatten
True, but it's _extremely_ useful when you're terminating SSL on Amazon's
Elastic Load Balancer and want to know if they've fixed it yet or not.

Or, another example, when you want to know for sure that you've restarted your
webserver and you weren't doing something stupid like running a version of
nginx that was statically linked against openssl.

------
purephase
How about Symantec? Those of you logging in to renew Verisign certificates
might want to take note:

[http://filippo.io/Heartbleed/#trustcenter.websecurity.symant...](http://filippo.io/Heartbleed/#trustcenter.websecurity.symantec.com:443)

It's vulnerable as well.

------
tlogan
And this is what really makes me mad:

$ ./heartbleeder yahoo.com

VULNERABLE - yahoo.com:443 has the heartbeat extension enabled and is
vulnerable to CVE-2014-0160

I can understand when some random service has vulnerability like this. But big
corporations like yahoo should resolve this immediately.

~~~
BrandonMarc
But isn't it _because_ they're big & complex that it's more difficult to
quickly resolve ... on the other hand, since they're so big & important (and
have the means) they should have plans in place already to deal with such
things.

------
fexl
I see a funny thing when I test it against yahoo.com:

    
    
      $ ./Heartbleed yahoo.com:443
      (bunch of returned bytes)
      2014/04/08 12:59:46 yahoo.com:443 - VULNERABLE
    

Near the front of the returned bytes is the sequence
"yheartbleed.filippo.ioYELLOW SUBMARINE". That is some padding buried inside
the Heartbleed source code.

I assume that the returned bytes are a peek inside the memory of a yahoo.com
server, and we can see the padding supplied by Heartbleed, followed by some
more bytes that depend on the server state.

Am I interpreting that correctly?

~~~
revelation
Interestingly, I just got that for HackerNews, but not on a second try. I
thought they were using CloudFlare anyway?

(And yes, you interpreted that correctly. Notice that this online test does
not _request_ even a fraction of the 64k possible, and you can always repeat
it to get more)

------
zaphoyd
The Qualys SSL Lab server test is also checking for Heartbleed now:

[https://www.ssllabs.com/ssltest/index.html](https://www.ssllabs.com/ssltest/index.html)

------
ce4
The bug also leaves the client vulnerable.

Has anyone a link to test client implementations? (E.g Browsers,...
Windows,... Android, Apps, etc)

~~~
agwa
The vulnerability is in OpenSSL only, and no major browser uses OpenSSL.
Firefox and Chromium use NSS, IE uses a Microsoft library, and Safari uses
Apple's SecureTransport.

Other OpenSSL-using clients are definitely vulnerable though - best bet to
tell if you're vulnerable is to check the OpenSSL version.

~~~
anonymfus
What about Opera 12, still major browser in CIS countries? OpenSSL license is
listed on opera:about page, but version is not specified. How to find out?

~~~
ce4
Opera 12 should be safe, as it doesn't support the heartbeat extension

I tested it using openssl's s_server (with a quickly generated cert using
tinyca) and then connecting to
[https://localhost:12345](https://localhost:12345)

    
    
      openssl s_server -accept 12345 -tlsextdebug -cert cert.pem | grep ^TLS
      TLS client extension "server name" (id=0), len=14  
      TLS client extension "renegotiation info" (id=65281), len=1  
      TLS client extension "status request" (id=5), len=5  
      TLS client extension "next protocol" (id=13172), len=0

------
mkmk
Yahoo mail appears to be vulnerable

~~~
smtddr
Well, Here we go...
[https://twitter.com/WarrenGuy/status/453510021930680320](https://twitter.com/WarrenGuy/status/453510021930680320)

pikachu@BATTLEGYM ~/heartbleeder $ date

Tue Apr 8 08:37:08 PDT 2014

pikachu@BATTLEGYM ~/heartbleeder $ ./heartbleeder mail.yahoo.com

INSECURE - mail.yahoo.com:443 has the heartbeat extension enabled and is
vulnerable

pikachu@BATTLEGYM ~/heartbleeder $

~~~
ibmthrowaway218
>
> [https://twitter.com/WarrenGuy/status/453510021930680320](https://twitter.com/WarrenGuy/status/453510021930680320)

Heh. Eliding the hex values of the password might have been a good idea.

------
xd
An online tester: [http://possible.lv/tools/hb/](http://possible.lv/tools/hb/)

------
euroclydon
Does heartbleed affect ssh or only TLS?

~~~
mey
This does not impact SSH, see [http://heartbleed.com/](http://heartbleed.com/)

~~~
Lockal
There is no information about SSH on this page. OpenSSH is a program depending
on OpenSSL the library, specifically OpenSSH uses the libcrypto part of
OpenSSL. So after updating OpenSSL ssh service should be restarted anyway.

~~~
pritambaral
ssh doesn't need to be restarted. As you said, OpenSSH never uses the
vulnerable part of OpenSSL code. When the ssh service was started, libcrypto
(which isn't vulnerable) was loaded into memory and made available to OpenSSH
code. That memory isn't going to be invalidated if libcrypto's on-disk copy
changes.

------
gprasanth
Oh, this time, the (free)ssl cert provider(s) is/are vulnerable!

