Critical OpenSSL vulnerability - Heartbleed (1.0.1 through 1.0.1f)

khav

@elijahpaul
built on: Tue Apr 8 02:33:43 UTC 2014
i guess its already patched but http://filippo.io/Heartbleed says my site is still vulnerable

Should i regenerate ssl certs or do i need to restart something

Openssl was updated via yum

elijahpaul

@khav said:
elijahpaul
built on: Tue Apr 8 02:33:43 UTC 2014
i guess its already patched but http://filippo.io/Heartbleed says my site is still vulnerable

Should i regenerate ssl certs or do i need to restart something

Openssl was updated via yum

His site is getting overloaded at the moment. And it's producing false positives. I think he mentions it on his twitter acc.

But, yes restart your server (or any services using SSL) and check again.

khav

@elijahpaul
Used lsof -n | grep ssl | grep DEL to check which services using openssl(Nginx and PHP-FPM) in my case and i restart both

Vulnerability is now fixed according to http://filippo.io/Heartbleed/

Thanks you very much for your help

sleddog

elijahpaul said: Run 'openssl version -a' and check the build date. It should be April 8th.

built on: Mon Apr 7 20:31:55 UTC 2014 for Ubuntu 12.04

elijahpaul

@sleddog said:

Yeah. I think 7th April is the right build date on Ubuntu systems.

EDIT: http://www.ubuntu.com/usn/usn-2165-1/

Silvenga

iceTwy said: @elijahpaul said: Am I right in thinking that even after you patch OpenSSL you have to re-generate any private keys (and CSRs) generated by the vulnerable version?

Not true, the attacker can take 64KB of data from the server's RAM. The attacker has no way to direct where in RAM they look. The chance of an attack getting your encryption keys is very low.

Source: http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/

Neoon

btw http://possible.lv/tools/hb/ is faster.

Silvenga

darknyan said: Rockster said: How does all this affect OpenVPN keys? Do they need to be replaced.

Yes.

Not true, OpenVPN does not use the Heartbeat extension. This exploit only affects applications that use TLS and the Heartbeat extension - POP3, SMTP, HTTPS, etc.

elijahpaul

@Silvenga said:
Not true, the attacker can take 64KB of data from the server's RAM. The attacker has no way to direct where in RAM they look. The chance of an attack getting your encryption keys is very low.

Source: http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/

I See. So really you'd only have to re-generate your key if you suspect it was actually compromised under the vulnerable version?

Silvenga

elijahpaul said: I See. So really you'd only have to re-generate your key if you suspect it was actually compromised under the vulnerable version?

Yes, theoretically you should believe your keys to be compromised, however, practically if you don't do anything you're unlikely to be in trouble. For example, Cloudflare is not regenerating keys, but they are attempting to find if any keys were compromised.

All these companies who are telling the public that they regenerated keys is pure pr.

elijahpaul

Thanks.

Yeah. I read about cloudflare. A mod in the comment section of their blog post mentioned that due to the scale of their infrastructure, they have to consider the financial costs (as well as actual risk) before deciding regenerating any keys for certs.

skagerrak

@Silvenga said:
Not true, OpenVPN does not use the Heartbeat extension. This exploit only affects applications that use TLS and the Heartbeat extension - POP3, SMTP, HTTPS, etc.

Which OpenVPN does. And thus, OpenVPN is affected, too.

natestamm

I have a thread that should complement this, Puts affected providers up top- http://lowendtalk.com/discussion/25124/heartbleed-it-s-origins-history-and-what-admins-need-to-do


@Silvenga I think given current events, there are obvious reasons as to why prolonged exposure to this vulnerability could raise the brow..And I'm not particularly one to rant very much at all on such things. Really.

ricardo

I think LET providers would earn some brownie points by securing their own server. I'm not going to name and shame them but I know of at least a couple that are still showing the vulnerability, leaving their customers sensitive data wide open to exploitation.

Running this command can see whether they are or not.

openssl s_client -connect server.name:443 -tlsextdebug -debug -state

emg

@ricardo said:
I think LET providers would earn some brownie points by securing their own server. I'm not going to name and shame them but I know of at least a couple that are still showing the vulnerability, leaving their customers sensitive data wide open to exploitation.

Running this command can see whether they are or not.

openssl s_client -connect server.name:443 -tlsextdebug -debug -state

And what do we look for after we run the command, for both secure and heartbleed-vulnerable sites?

ricardo

@emg TLS server extension "heartbeat" (id=15)

(i copied this from elsewhere btw)

openssl s_client -connect server.name:443 -tlsextdebug 2>&1| grep -n 'server extension "heartbeat" (id=15)' || echo safe

elijahpaul

@ricardo said:
emg TLS server extension "heartbeat" (id=15)

(i copied this from elsewhere btw)

openssl s_client -connect server.name:443 -tlsextdebug 2>&1| grep -n 'server extension "heartbeat" (id=15)' || echo safe

Correct me if I'm wrong, but I think that command only determines whether the host is running the heartbeat extension or not. Not whether it's actually heartbleed vulnerable or not.

ricardo

@elijahpaul, you are right. Searched around again, it depends on whether it's openssl or not... as the flaw was introduced at the same time as implementing the heartbeat feature. The output of the command up there ^ only really applies if you know openssl is being used.

sergiodelatorre

Paranoid patch

iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"

iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP

JohnRoe

I dont really understand what this exploit can do. Is it can affect people who dont use ssl?

Gunter

@psycholyzern said:
I dont really understand what this exploit can do. Is it can affect people who dont use ssl?

It allows 64kb of anything in the RAM to be stolen per request. This can be used to piece together encryption keys, current sessions, form submissions, passwords, e.g.

JohnRoe

@darknyan said:
It allows 64kb of anything in the RAM to be stolen per request. This can be used to piece together encryption keys, current sessions, form submissions, passwords, e.g.

wow.. so it can affect all of us.. I tried to update my centos. but it seems uptodate with old openssl

xDragonZ

@psycholyzern said:
wow.. so it can affect all of us.. I tried to update my centos. but it seems uptodate with old openssl

Go to your terminal and type "openssl version" to check you are using the affected version or not

JohnRoe

OpenSSL 1.0.1e-fips 11 Feb 2013

this is on my online.net's dedi..

I got email from online.net saying my dedi are affected..

petris

@psycholyzern said:
OpenSSL 1.0.1e-fips 11 Feb 2013

this is on my online.net's dedi..

I got email from online.net saying my dedi are affected..

Since changes to FIPS certified code requires recertification, it's probably going to be a while. You'll probably want to switch to the non-fipa version for a while.

Drehmini

@psycholyzern said:
OpenSSL 1.0.1e-fips 11 Feb 2013

this is on my online.net's dedi..

I got email from online.net saying my dedi are affected..

Run openssl version -a

Check what the build date is.

sman

I had to to restart apache after the update to pass the check.

You can check your site at this link:
http://filippo.io/Heartbleed/

JohnRoe

@Drehmini said:
Check what the build date is.

OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Tue Apr 8 02:39:29 UTC 2014

JohnRoe

@sman said:
I had to to restart apache after the update to pass the check.

You can check your site at this link:
http://filippo.io/Heartbleed/

I checked my site..passed.. but why online.net tell me my dedi are affected?

Drehmini

psycholyzern said: OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Tue Apr 8 02:39:29 UTC 2014

For some reason on centOS the version isn't updated but the build is (hence Apr 8).
That build has been updated and the heartbleed bug has been fixed.

As long as filippo.io reports passed, then you should be safe.