System administrators, I hope you weren’t planning to have an easy day today?
Not only will Microsoft be releasing critical patches later on Tuesday (including the last ever security patches for Windows XP), but there now comes the potentially disastrous news that a serious security flaw has been uncovered in versions of OpenSSL’s transport layer security (TLS) protocols.
In case you’re not aware, OpenSSL is the open-source software widely used to encrypt web communications, and a security flaw like that could be used by attackers to reveal the contents of a “secure” message, such as your credit card details shared with an online store via HTTPS.
But more than that, it could also disclose the secret SSL keys themselves. These are the “crown jewels”, and could be used by malicious hackers to do even more damage, without leaving a trace.
Finnish security experts Codenomicon say in an excellent write-up of the issue, that large numbers of private keys and other secret information has been left exposed for long periods of time as a result of the programming screw-up.
Bugs in single software or library come and go and are fixed by new versions. However this bug has left large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitation and attacks leaving no trace this exposure should be taken seriously.
The advice is to update to the just-released OpenSSL 1.0.1g immediately, and regenerate your private keys.
If it’s not possible to update to the latest version of OpenSSL, software developers are advised to recompile OpenSSL with the compile time option OPENSSL_NO_HEARTBEATS.
Which versions of OpenSSL are vulnerable?
- 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
For more guidance and further reading:
I made a tool to check the status of your SSL and see if heartbeat is enabled. If it is, you should run this command: openssl version -a
Ensure your version is NOT 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1
Tool at: http://rehmann.co/projects/heartbeat/
I read that only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected http://bit.ly/R0nSDQ and OpenSSL users are advised to upgrade their websites with OpenSSL.. Tech Crunch reported today that this newly bug in OpenSSL holds enormous potential
Hi Graham,
Is there a way for consumers to know if a site's SSL certificate is compromised now?
Thanks,
Yan
Since it is elusive the best bet is to regenerate it if you were using a vulnerable version of OpenSSL. You can determine, however, IF a site that you purchase things from (or log in to for another example) is vulnerable as is (that doesn't mean it is or is not compromised but it does mean it COULD be if it is vulnerable): goto the site referred to, as in http://filippo.io/Heartbleed/
and enter in the address of the site (appending, without quotes ":443" for the port as that is the https port, at least by standard and expected) and it will tell you.
Another critical thing that many administrators might not be aware of (Graham, maybe you should update the post to include this – at least the part about there is more to fixing the problem than updating the library itself!) is that just updating the library is NOT sufficient! Any service (that includes but is not limited to apache – others could be dovecot, postfix, … any number of others) that uses OpenSSL should be restarted. Why? Because, the services load at runtime the library (which openssl is a library). That means if it was running and the version is updated, the webserver (or mail server or …) still has the old version loaded! Even those which statically link to the library would still have the problem if they linked to a vulnerable version (so that means you'd also need to update the service in question).
I got an email this morning (that I set up) from my server to mail (a private mail) that there was an update and this was before I read about the disclosure. I already updated openssl and then saw this. Of course, I knew at the time that any thing linking to openssl would need to be restarted (I am after all, a programmer, and I have also programmed shared libraries and loading of shared libraries too, not even counting the usual linked in libraries to programs) but I did not at that time do so. Mostly because I was waking up still. I have since then done this but this is critical if you are to fix the situation completely (not counting whether your certificate is breached or not).
Example is for CentOS and other Red Hat based Linux distributions. Run as root (or 'sudo [command]' where '[command]' is the command I give; remember that # is the root prompt so don't type that):
# service httpd restart
Do the same thing for others (I would hope you know which services you have configured to use openssl but if not I would take a careful look and/or restart all services or if it isn't a problem then reboot the server. This is up to your discretion though). That is AFTER you update openssl (e.g., with yum, for redhat based systems).
One more tip (two parts to it). For those with the utilities (this is not Windows, by the way, so irrelevant in such systems) lsof and awk (almost assuredly awk is there and lsof may or may not be), here is one way to determine the processes which uses a library from openssl. I'll comment below.
# lsof|awk /libssl\|libcrypt/'{print $1,$3}'|uniq
I'm not going to comment on the construct of the pipeline much because awk is a language itself and this is fairly basic once you understand the awk portion (shortly: output of lsof is sent to awk which searches for either libssl or libcrypt and when found print the first and third field. pass the result to uniq as some services have more than one running thread so this removes duplicates. technically uniq needs the repeats to be adjacent so it could be further improved but it should suffice).
The output might look like this (and I'm specifically showing the third field because the process name does not necessarily mean it is a service name; the third field is the user which in some cases can be useful in determining which service it belongs to, as well as something I'll give below):
pickup postfix
qmgr postfix
ssl-param root
Note that the first two processes are named pickup and qmgr but the user is postfix. Indeed, restarting postfix will suffice here. And if there is a process that doesn't appear to be any service, you can try to locate it (e.g., "locate [name]" if you have the locate program) to get the full path, and then (this is red hat specific but Debian and others I imagine have equivalents). For instance, what is ssl-param? You can try (You shouldn't need to be root for this but you will when you decide – if you decide you need to – restart the service) something like:
$ locate ssl-param
/usr/libexec/dovecot/ssl-params
[more output]
In this case it is clearly dovecot. If you couldn't put that together though, in a redhat system, you can query the file for the package name like:
$ rpm -qf /usr/libexec/dovecot/ssl-params
[package name if found]
or more generally:
$ rpm -qf /path/to/file
Hi Graham,
In your article of 13 October 2013, "This secret post-it note shows the NSA tapping into Google’s data centers" (https://grahamcluley.com/nsa-tapping-google-yahoo-data-centers/) , the drawing on the Post-It note shows a smiley-face next to the words: "SSL added and removed here!".
It is possible, is it not, that the NSA and GCHQ discovered this SSL vulnerability within the last two years, and have taken advantage of it. How bad would that be, if the organisations responsible for national cyber-security have been exploiting a vulnerability that they knew perfectly well had dire potential consequences for the security of websites all over the world handling private personal, commercial, and financial information?
It would be bad but to be honest with you: the NSA has had problems with encryption for a lot longer than 2011/09/11 and they just make that one of their many (invalid) excuses (I have yet to be surprised with the revelations; more like I'm surprised that some countries suggest they have no real spying capability or they refuse to spy… well, okay, I'm not surprised with that either but I think you get the point which is those countries are likely hypocrites and lying about it). Truth be told I'm amazed the encryption export regulations were at one point relaxed some (maybe more than once but once is enough surprise). In other words, they don't actually care: they publicly acknowledge their problems with encryption in the past (unless I'm remembering this with the wrong organisation… Department of Justice might also be it instead – cannot confirm 100%). Yes, if they were to make use of it it would be bad but unfortunately that's no different than them abusing (which is the correct word over use) another flaw (or worse, backdoors, trojans, …). The problem is that by not allowing encryption (and other safety measures) you expose the public to exactly what they claim to be "preventing" (which I personally think is a farce and while I do have something to back up my belief I won't get in to it because I often don't trust people I know – suspiciousness if not outright paranoia, unfortunately is something I'm familiar with – and I certainly do not trust anyone I _don't_ know let alone the government… especially considering how often companies and people take things out of context and abuse it to create fabricated accusations). Regardless, whether they discovered it or not: I am biased in that I don't trust them but I do not think every thing claimed is as impressive as made to be (e.g., identifying hardware is nothing new any more than spoofing and I'm not even referring to IP addresses). Still, one can speculate all they want about whether they would have been able to spot it (the vulnerability) or not (that they supposedly convinced companies to implement backdoors makes me think they have less technical ability than some suggest but you can never be sure 100% and to rely on that is dangerous). The bottom line is this: whether they found it or not is irrelevant in the sense that sites are patched and people then take the appropriate fixes. Anything else is not going to change or help any one else! Sure, they would have explanations to make if they are at all decent (ahem) but it'll be on their terms and not the public's (hence why we always hear/read/etc. "we don't make statements on [insert some topic]" and similar).
I found a Firefox tool that can help the user know if the site is at risk -> http://www.proactiverisk.com/home/proactivetools