Massive Security Bug In OpenSSL

[ross549]

The irony here is that servers running Microsoft IIS are not vulnerable.

 

Adam

[Guest LilBambi]

Yep! That's very true! Microsoft and Apple services apparently unaffected.

[ebrke]

If you have a D-Link router here's a good place to start.

http://securityadvis...x?name=SAP10022

 

Turns out my router is OK. I don't have any remote access enabled either.

I've gotta ask and display my ignorance--why is openSSL on a consumer router? Only thing I can think of is to secure remote access. What am I missing?

[ross549]

Remote management of the router would be the only use I can think of for it. All other SSL/TLS traffic should be passed through without being touched.

[ross549]

So you are saying that even though your version is OLDER than 1.0.1 that yours is OK, even though it says should upgrade to 1.0.1g and that 1.0.2 will be fixed in 1.0.2-beta2?

 

For clarification, .9 of openSSL is a branch from the 1.0.1 releases. It is still being actively maintained. Securitybreach is fine and has nothing to worry about.

 

Adam

[sunrat]

The bug was introduced in v1.0.1 and fixed in v1.0.1g.

[ross549]

 

What versions of the OpenSSL are affected?

Status of different versions:

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  
• OpenSSL 1.0.1g is NOT vulnerable
  
• OpenSSL 1.0.0 branch is NOT vulnerable
  
• OpenSSL 0.9.8 branch is NOT vulnerable
  

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

From: http://heartbleed.com/

Adam

[V.T. Eric Layton]

...appears to be unaffected, probably because it's really old.

 

Maybe there are some advantages to being old. I think I'll install my old MS Win 98SE. It's probably more secure than 7 or 8. Most of the pimply-faced hackers attempting to exploit stuff weren't even born when 98 came out.

[V.T. Eric Layton]

The irony here is that servers running Microsoft IIS are not vulnerable.

 

Adam

 

That's not irony. That's expensive closed-source software produced by highly paid private MS coders and devs. That's capitalism, comrade!

[V.T. Eric Layton]

I've gotta ask and display my ignorance--why is openSSL on a consumer router? Only thing I can think of is to secure remote access. What am I missing?

 

Don't confuse apples and oranges. SSL (secure sockets layer) is a TCP/IP transport protocol. It's not to be confused with SSH (secure shell). OpenSSL is just an open source implementation of the SSL protocol.

[ross549]

There's a lot of reports of routers being affected, hence the question.

 

Adam

[ebrke]

Don't confuse apples and oranges. SSL (secure sockets layer) is a TCP/IP transport protocol. It's not to be confused with SSH (secure shell). OpenSSL is just an open source implementation of the SSL protocol.

D-Link is listing what they call consumer routers at risk on their OpenSSL vulnerability notification page saying the devices carry the openSSL library. I wondered why those routers would be affected and couldn't think of any reason other than to make remote access secure.

[V.T. Eric Layton]

The Internet is broken.

[ross549]

Layer 2 and 1 still work fine.

 

Adam

[V.T. Eric Layton]

Yes, but there's nothing human intelligible in those layers.

[Guest LilBambi]

D-Link is listing what they call consumer routers at risk on their OpenSSL vulnerability notification page saying the devices carry the openSSL library. I wondered why those routers would be affected and couldn't think of any reason other than to make remote access secure.

 

For administration pages. They always encourage people to use https for configuration administration pages.

[crp]

Aside from a clean room, has anyone been able to exploit the trick and obtain meaningful data?

[Guest LilBambi]

BREAKING: Heartbleed vulnerability can reliably extract SSL secret keys. Attack demonstrated by @indutny. https://www.cloudfla....com/heartbleed

 

 

That was posted by @EFF here on Twitter.

 

People are already questioning whether this is an OpenSource Failure ... as if that isn't the pot calling the kettle black! Like proprietary never has this sort of massive problem happen... so easily they hope everyone forgets ... Just because Microsoft and Apple were safe this time, doesn't mean they haven't had some major disasters themselves in the past that affected huge numbers of users.

 

[Guest LilBambi]

The Bleeding Hearts Club: Heartbleed Recovery for System Administrators - EFF.org

 

 

 

 

The Heartbleed SSL vulnerability presents significant concerns for users and major challenges for site operators. This article presents a series of steps server and site owners should carry out as soon as possible to help protect the public. We acknowledge that some steps might not be feasible, important, or even relevant for every site, so the steps are given in order both of their importance and the order they should be carried out.

 

1. Update Your Servers

If you haven't yet, update any and all of your systems that use OpenSSL for TLS encrypted communications. This includes most web servers, load balancers, cache servers, mail servers, messaging and chat servers, VPN servers, and file servers, especially those running on Linux, Unix, BSD, Mac OS X, or Cygwin.

The vulnerable OpenSSL version numbers are 1.0.1 through 1.0.1f and 1.0.2-beta1. The flaw is fixed in OpenSSL 1.0.1g. However, some operating systems have introduced the fix to earlier branches of OpenSSL, and may instruct you to install packages with minimum versions such as 1.0.1e-2+deb7u5 (in the case of Debian GNU/Linux).

If your operating system has not yet released an updated package, download

openssl-1.0.1g.tar.gz

directly from

https://www.openssl.org/source/

and follow the instructions in the INSTALL text file to compile the new version locally.

After installing a fixed version of OpenSSL, be sure to restart all services that depend on it. On your sysytem this might include web and proxy servers such as apache, nginx, pound, and squid, caches such as memcached and redis, databases like mysql and postgres, and mail services like postfix, exim, and dovecot. When in doubt, reboot the entire server if possible.

If you manage systems with custom operating systems like switches and routers, you may need to ask your vendor for a patch directly.

If you haven't updated your systems yet, stop reading and do it now. If this is the only step you can carry out in your environment, you will still have done the most important thing by far.

 

2. Test Your Servers

It's important to verify that the hole has been closed, especially if you have multiple servers and services to stitch up. The bad news is that this vulnerability is relatively easy to exploit. The good news is that means there are a few tools available to see if you're safe.

The

SSL Server Test

from Qualys SSL Labs will let you know if your web server remains vulnerable. If you have servers running on other ports to test, or STARTTLS mail servers, you can try the

hb-test.py

script. The

hbcheck

script can help you test an internal network using nmap. Finally, if you have a large number of hostnames to test, my

hb-batch.py

script might be helpful.

Please note these tests might not be completely reliable, and running them against servers you do not own might not always be considered polite.

 

3. Be Safer Next Time

This is the worst and biggest security flaw we've seen recently, but it won't be the last. Putting good practices into play for Heartbleed can help you prepare for anything else that might come down the pike next.

One of the strongest protections you can have against TLS vulnerabilities is

Perfect Forward Secrecy

. This is not simple to configure, and does not yet have global browser support. However, it is the encryption technology that provides the best defense against attacks with the potential to steal your private key and use it to decrypt your traffic.

You should also make sure you're practicing

good password discipline

. Use a password vault, use strong passwords, change them regularly, and don't reuse them.

Practice least authority for certificates, too. If you don't need to give everyone root access to every server, you probably don't need to give every server a certificate for *.example.com.

Finally, make sure you have reliable (if not automated) process for providing all of your servers with security updates quickly. After all, the only thing worse than getting pwned by a zero-day vulnerability is getting pwned by a one-day.

 

4. Consider Rekeying Your Servers

One of the worst things about the Heartbleed vulnerability is that it makes it theoretically possible for an attacker to recover your server's private key. Fortunately, the probability of this being possible on a given server appears quite low. Unfortunately, we can't yet be completely sure if that's true.

Key theft is a terrible attack because it tends to be undetectable by you, the server operator. Worse still is the harsh truth that, unless all your connections are served with

Perfect Forward Secrecy

, this would allow such an attacker not only to decrypt any newly intercepted traffic but to decode records of past traffic. If you run a server that intelligence agencies are likely to attack, this is a

serious

problem

.

That means you may wish to consider revoking and regenerating your existing SSL certificates using new keys. Doing so will protect against the possibility of passive traffic decryption (if you don't use PFS) and man-in-the-middle attacks with a stolen key.

Because private key compromise via Heartbleed currently appears to be quite rare, this may not need to be a priority except for high value services (large or sensitive email and messaging systems, software distribution points, banks). Other services may not need to panic and rush to rekey quite so urgently. For most threat scenarios, adopting PFS provides greater overall protections than rekeying so we will remind you to make PFS a priority.

The details of the rekeying process will vary depending on the Certificate Authority you use to generate certificates and/or manage domain names. Some will allow you to regenerate in one step. Some will require you to revoke the old certificate before requesting a new one.

1

Most will have a prominent link in their control panels, and many will waive their normal fees right now.

If you are given the option during the certificate regeneration process, it's a good idea to create a .csr file (Certificate Signing Request) and private key locally on your server

using the openssl command

. It might seem strange to prefer trusting OpenSSL at the moment, but it's still a safer bet than trusting a third party with your private key right off the bat.

 

5. Consider Changing Passwords

Unlike private key compromises, Heartbleed leakage of recently-used passwords from server processes linked to OpenSSL appears to have been quite common. Unfortunately, this could affect not just your operators and staff but your users.

This means you should perform risk assessment and determine which categories of passwords on your servers and services may need immediate resets, user-reset-on-next-login, or advisories suggesting resets. Variables in the risk assessment include how quickly you were able to patch your servers after the vulnerability was publicly disclosed at around 17:30UTC on 2014-04-07, According to a recent article in Bloomberg, i

2

. the sensitivity and value of potentially accessible accounts, whether accounts had been used recently (meaning their passwords were in RAM), and the probability that random or specific people on the Internet might have found your servers to be interesting targets.

You should determine which passwords are of sufficient value to deserve precautionary resets, and perform these after the steps above, in order to offer the new passwords proper protection. (If you've decided to rekey because of a concern about private key exposure, that is another reason to change users' passwords.)

You should also consider changing CSRF and OAUTH authentication tokens, invalidating session cookies, and rotating authentication cookies. These steps can be performed independently of passwords changes and may be far less disruptive.

 

6. Update Your Users

Your users have already heard of this scary Internet password thing, and chances are they're concerned about how it affects your site. Let them know what you've done, what you will do, and what the remaining risks are. Don't try to give them a false sense of security. Knowing that you're working on it and reaching out to them at all will work wonders.

 

7. Turn on Perfect Forward Secrecy

Because you skipped it in step three, didn't you? That's okay. There's still time. We'll wait.

[raymac46]

http://www.theverge.com/us-world/2014/4/11/5606524/hacker-successfully-uses-heartbleed-to-retrieve-private-security-keys

[Guest LilBambi]

http://www.theverge....e-security-keys

 

Yep, great, you found an article that talks about it too. I saw the actual links for the Cloudflare challenge and who succeeded with the challenge through EFF on Twitter -- links above.

 

Fedor Indutny also was quick to indicate (in a future twitter post that I posted above) as many of us already know that Security by Obscurity is no security at all. It may stumbles legitimate users but not criminal hackers and spammers....and those who buy their talents. This was not a failure of Open Source software, it was a failure by the community itself, where many Devs make use of Open SSL Open Source software without reading the code. It's supposed to be many eyes makes work light...

[ross549]

Aside from a clean room, has anyone been able to exploit the trick and obtain meaningful data?

 

Short answer- yes. The original folks who found the bug first attacked their own servers and were able to extract plenty of critical data- passwords, keys, etc.

[ross549]

BREAKING: Heartbleed vulnerability can reliably extract SSL secret keys. Attack demonstrated by @indutny. https://www.cloudfla....com/heartbleed

 

I am not sure this is really newsworthy. The orignal researchers already showed this was possible by attacking their own servers.

 

 

People are already questioning whether this is an OpenSource Failure ...

 

It is an issue of trust. We've [speaking in generalizations here] trusted FOSS for too long without any accountability. The only real way to know if the software is trustworthy is through independent audits. TrueCrypt is working on this right now, as they believe they have a solid and mature product. We simply cannot say "it's open source, so I can trust it."

 

However, the bug in openSSL was discovered because the code was available to view. This is a crucial piece of the puzzle. We cannot examine the code for Windows, or Apple Safari, because the code is not available to do so. If openSSL had not been open, the bug might not have been brought to light.

 

On the other hand, having the code open means the bad guys can also look at it, and figure out attacks.

 

Really simple, right?

 

Adam

[crp]

Short answer- yes. The original folks who found the bug first attacked their own servers and were able to extract plenty of critical data- passwords, keys, etc.

My impression was that they did it in a basically clean-room setup, not by trying to use this against a real live active target from an outside 'shooter',ie: they didn't get anything in the regular chaos of IP traffic.

 

And how many people use the public IP to access their personal home routers' admin page?

[Guest LilBambi]

How many people are unwise enough to open their router admin pages while they are looking at other websites that could be a problem? Even before this issue. I have seen people do it! And cringe.

 

I always clear my cache and make sure I have NO other webpages open. I often will actually close the browser entirely and open it again after cleaning caches to make sure nothing is in memory before using a router's admin page. Just to be sure.

 

They keep finding that browsers have broken sandboxing, I just don't trust it, in new tabs or fully in new windows anymore.

[ross549]

It is true. The researchers attacked their own production servers.

 

http://heartbleed.com for more info.

 

How many people are unwise enough to open their router admin pages while they are looking at other websites that could be a problem? Even before this issue. I have seen people do it! And cringe.

 

I like to live dangerously.

 

Adam

[Guest LilBambi]

NSA Said to Exploit Heartbleed Bug for Intelligence for Years - Bloomberg

 

 

 

[V.T. Eric Layton]

The more stuff like this happens and the more we find out about how, thanks to technology that was supposed to be to our benefit, we are being spied upon by every BIG GOV analyst and pimply-faced Russian kid, the more I really am considering cutting the cord... and the wifi completely. I've been wondering if I could return to my pre-computer/Internet days without too much pain. I think I could. However, I would miss you folks very much were I to actually revert to 1975.

[Corrine]

I have a problem with the Bloomberg article -- "two people familiar with the matter said." Are those "two people" NSA employees/contractors? Bloomberg writers? People off the street? It is just too open-ended.

 

Found the two Tweets from yesterday that contradict the Bloomberg article:

 

https://twitter.com/NSA_PAO/status/454720059156754434:

Statement: NSA was not aware of the recently identified Heartbleed vulnerability until it was made public.

 

Also see

[ross549]

You are correct, the NSA connection is highly speculative and is not corroborated nor is any real evidence presented. This is much like iPhone rumors, all heresy until Apple announces something.

 

There's a lot of speculation about wether this was previously known before being announced and wether it was being exploited in any way. Sadly, there is no way to tell, since it does not leave a trace.

 

My gut, however, has an opinion. I think this is something new that was not previously known. It is my gut, though, and worth about as much as you paid for it.

 

Adam