Hi all,
Critical info on OpenSSL / Heartbleed bug - Y O U ARE vulnerable. You
are most likely vulnerable if you run servers. However, you are almost
certainly vulnerable if you USE servers, as a consumer ... in other
words, if you log into ANYTHING. This post was inspired by a discussion
on the DC404 security group, then by a podcast I heard on the subject,
then by some research I did on it. I've posted this same info over on
DC404.
-----
I had observed this discussion on the OpenSSL / Heartbleed issue. I
found it interesting, but I figured, I'm not running any servers, so I'm
not too concerned. Then, a podcast I listen to did a show on the topic,
and I heard that Lastpass had some things to say on the subject. Then,
I started thinking, this may affect me as a consumer. Then, I started
researching it more and more, and what I found concerned me greatly.
The bottom line, if I'm understanding this right, is that consumers
who know about this and who care, which will be few, should probably
change their passwords on EVERY site they care about, but ONLY after the
site has patched its software and revoked and replaced their security
certificates. I have a dialog ongoing with Lastpass tech support to try
to determine what the danger is by logging into various accounts, like
my bank, before the site has been updated. I'll try to share the
research I've done. Big caveat, much of this is over my head. I can
only share what I've read and you guys will, no doubt, be able to
understand the implications better than I. This gets a little long, but
I think the information is good.
The documentation at the heartbleed.com site that was already mentioned
is very good. Here are some quotes from it, but I'd recommend reading
the whole thing. Note, I am not quoting the entire site here.
"The Heartbleed bug allows anyone on the Internet to read the memory of
the systems protected by the vulnerable versions of the OpenSSL
software. This compromises the secret keys used to identify the service
providers and to encrypt the traffic, the names and passwords of the
users and the actual content. This allows attackers to eavesdrop on
communications, steal data directly from the services and users and to
impersonate services and users."
"We have tested some of our own services from attacker's perspective. We
attacked ourselves from outside, without leaving a trace. Without using
any privileged information or credentials we were able steal from
ourselves the secret keys used for our X.509 certificates, user names
and passwords, instant messages, emails and business critical documents
and communication."
"Encryption is used to protect secrets that may harm your privacy or
security if they leak. In order to coordinate recovery from this bug we
have classified the compromised secrets to four categories: 1) primary
key material, 2) secondary key material and 3) protected content and 4)
collateral."
"What is leaked primary key material and how to recover?
These are the crown jewels, the encryption keys themselves. Leaked
secret keys allows the attacker to decrypt any past and future traffic
to the protected services and to impersonate the service at will. Any
protection given by the encryption and the signatures in the X.509
certificates can be bypassed."
"What is leaked secondary key material and how to recover?
These are for example the user credentials (user names and passwords)
used in the vulnerable services. Recovery from this leaks requires
owners of the service first to restore trust to the service according to
steps described above. After this users can start changing their
passwords and possible encryption keys according to the instructions
from the owners of the services that have been compromised. All session
keys and session cookies should be invalided and considered compromised."
"What is leaked protected content and how to recover?
This is the actual content handled by the vulnerable services. It may be
personal or financial details, private communication such as emails or
instant messages, documents or anything seen worth protecting by
encryption. Only owners of the services will be able to estimate the
likelihood what has been leaked and they should notify their users
accordingly."
"What is leaked collateral and how to recover?
Leaked collateral are other details that have been exposed to the
attacker in the leaked memory content. These may contain technical
details such as memory addresses and security measures such as canaries
used to protect against overflow attacks."
"Am I affected by the bug?
You are likely to be affected either directly or indirectly. OpenSSL is
the most popular open source cryptographic library and TLS (transport
layer security) implementation used to encrypt traffic on the Internet."
(Ron speaking here, the following three items are very important.)
"Can I detect if someone has exploited this against me?
Exploitation of this bug leaves no traces of anything abnormal happening
to the logs."
"Has this been abused in the wild?
We don't know. Security community should deploy TLS/DTLS honeypots that
entrap attackers and to alert about exploitation attempts."
"Can attacker access only 64k of the memory?
There is no total of 64 kilobytes limitation to the attack, that limit
applies only to a single heartbeat. Attacker can either keep
reconnecting or during an active TLS connection keep requesting
arbitrary number of 64 kilobyte chunks of memory content until enough
secrets are revealed."
So, the bug which has been around for 2 years, allows an attacker to:
* Attack the vulnerable site
* Leave no trace of it
* Repeatedly download 64K chunks of memory
* Attack again and again later with no trace
* Decrypt any past and future traffic to the protected services (if keys
are lost)
* Impersonate the service at will (if keys are lost)
* Steal user credentials (user names and passwords)
* Impersonate the users at will (if user names and passwords are lost)
* Steal user content such as emails or instant messages, documents
* Observe things such as memory addresses and security measures such as
canaries
This is VERY ugly. I know many of you in the security industry are
already taking steps to remediate your servers. But, for those that
haven't taken this seriously, please do so. However, you may not
realize the impact on your users, nor the responsibility to inform all
those users.
This page clearly indicates that the bug allows the potential theft of
user names and passwords right out of the computer's memory. It also
clearly says that the vulnerable services should remediate their servers
then provide instructions to the users as to what to do.
As a consumer, this worries me substantially. A large majority of all
the websites I log into with names and passwords may be vulnerable, and
if history is any example, many will NOT be patching it quickly. It
seems to me, that every time I log into one of those that haven't
patched, I have a good probability of getting my password stolen, as the
bad guys will now be targeting the banks and the isp's and the social
networks that we log into, since they'll have a window of opportunity
until all the systems are patched.
I can envision several scenarios and status levels and my interpretation
of the results:
a) SERVER was vulnerable but ISN'T VULNERABLE now because it was
patched, CERTS are UPGRADED.
- My current and future data is safe. The old certs, my user name
and password, and prior communications and documents may have already
been stolen. Old recorded communications could be cracked without
perfect forward secrecy. I should change my password now.
b) SERVER was vulnerable but ISN'T VULNERABLE now because it was
patched, CERTS are OLD.
- My current and future data is NOT safe, since the certs could have
been stolen. Bad guys could decrypt data or impersonate the site. I
should wait to change my password until the cert is upgraded. In the
mean time, it sounds like I shouldn't even log in to the sites. This is
what I'm trying to get some clarity on.
c) SERVER was vulnerable and STILL IS VULNERABLE, CERTS are UPGRADED.
- Upgraded certs are meaningless since the system can still be
attacked. Implications are the same as b) above except that I should
wait until the server is patched AND the certs are upgraded to change my
password.
d) SERVER was vulnerable and STILL IS VULNERABLE, CERTS are OLD.
Implications are the same as b) above except that I should wait until
the server is patched AND the certs are upgraded to change my password.
The bottom line for me as a consumer, is that, if the server was EVER
vulnerable, I should change my password. The only question is when the
server and certs will be upgraded so I can do so.
You may note that I didn't mention a whole selection of permutations
where the server was never vulnerable. This is very hard for the
consumer to know, unless the site has publically stated that they never
were vulnerable. You can deduce that they may not have been vulnerable
if they are running all MS server software, but that is very hard for
the consumer to determine.
So, as a consumer, I have to assume that I have to change EVERY password
for EVERY site that I connect to, but only after potentially MONTHS of
testing them repeatedly to determine if they've patched their servers
and upgraded their certs. I may make exceptions for the ones Lastpass
says are safe, as described below.
Here's some data from SSL Labs, which has a server test utility (which
runs from the website) available for free on their website.
https://www.ssllabs.com/
https://community.qualys.com/blogs/securitylabs/2014/04/08/ssl-labs-test-for-the-heartbleed-attack
Here are some of their comments:
"Your server is probably vulnerable if it's running any version in the
OpenSSL 1.0.1 branch. If you'd like to verify if you're vulnerable,
today I released a new version of the SSL Labs Server Test. I went
through a lot of effort to implement a test that verifies the problem
without retrieving any bytes from the server, other than the bytes we
send in the heartbeat request. So it should be safe to use. Despite the
availability of the test, if you can identify the library version
number, I would urge to assume that you are vulnerable, even if the test
is not showing a problem."
Here's a link to their server test:
https://www.ssllabs.com/ssltest/index.html
The Lastpass blog has been talking about the issue:
http://blog.lastpass.com/
A specific post about the bug:
http://blog.lastpass.com/2014/04/lastpass-and-heartbleed-bug.html
This text is particularly interesting:
"Because other websites may not be encrypting data the way LastPass
does, we recommend that LastPass users generate new passwords for their
most critical sites (such as email, banking, and social networks) if
those sites utilize Apache, Nginx or show as vulnerable to the
Heartbleed bug. However, users should wait until their sites have
replaced their certificates, with a start date after today (April 8th,
2014)."
Now, I'm asking myself, what are my critical sites? If I've gone to the
trouble to input 80+ passwords into Lastpass, are they not critical? I
think a better way to say that is change the passwords on any site that
you don't want someone breaking into your account on.
Lastpass' Heartbleed checker is here:
https://lastpass.com/heartbleed/
They seem to be just checking for the server name and cert dates and
comparing that to the date of the bug. You can also get a check on your
personal sites by using the tools / security check function from
Lastpass. However, this didn't seem to be giving status on all my
sites, so it may just flag the ones with known vulnerabilities.
I think I'm going to test every site manually that I have stored in
Lastpass. I think the SSL Labs test is better, in that he actually
simulates an attack, rather than trying to infer vulnerability.
However, the Lastpass test does provide valuable data in that it shows
when the cert was updated.
Let's take some examples:
-----
Here's what I get when I put suntrust.com into the SSL Labs checker. By
the way, www.suntrust.com is a different ip:
"This server is not vulnerable to the Heartbleed attack. (Experimental)"
That's good to know. But, still no way to know if it WAS vulnerable.
Here's what I get when I put suntrust.com into the Lastpass checker:
Site: suntrust.com
Server software: BigIP
Was vulnerable: Possibly (might use OpenSSL)
SSL Certificate: Possibly Unsafe (created 3 months ago at Jan 7
02:57:42 2014 GMT)
Assessment: Wait for the site to update before changing your password
Note that the cert is 3 months old, and I'm being advised to wait and
change my password. But, what the heck do I do until then?
-----
Here's what I get when I put wellsfargo.com into the SSL Labs checker:
"This server is not vulnerable to the Heartbleed attack. (Experimental)"
Here's what I get when I put wellsfargo.com into the Lastpass checker:
Site: wellsfargo.com
Server software: KONICHIWA/2.0
Was vulnerable: No
SSL Certificate: Safe (regenerated 7 months ago)
Assessment: This server was not vulnerable, no need to change your
password unless you have used it on any other site!
This is interesting. It says it never was vulnerable and I don't have
to change my password. Not sure how they know that, unless it's based
on the server software in use.
-----
Here's what I get when I put bankofamerica.com into the SSL Labs checker:
"This server is not vulnerable to the Heartbleed attack. (Experimental)"
Here's what I get when I put bankofamerica.com into the Lastpass checker:
Site: bankofamerica.com
Server software: BigIP
Was vulnerable: No
SSL Certificate: Safe (regenerated 4 months ago)
Assessment: This server was not vulnerable, no need to change your
password unless you have used it on any other site!
Never was vulnerable, apparently.
-----
You get the idea. This is how I'm going to check my sites, and it will
be a pain in the rear to go through them all. You can do the same if
you wish to your sites. By the way, Yahoo and Github WERE vulnerable
according to Lastpass. You should change your passwords if you use
those sites.
Hope the info is helpful.
Sincerely,
Ron
--
(PS - If you email me and don't get a quick response, you might want to
call on the phone. I get about 300 emails per day from alternate energy
mailing lists and such. I don't always see new email messages very quickly.)
Ron Frazier
770-205-9422 (O) Leave a message.
linuxdude AT techstarship.com
_______________________________________________
tech-chat mailing list
[email protected]
http://lists.linuxmoose.com/mailman/listinfo/tech-chat
