Duncans Security Blog An enthusiasts musings

19Apr/142

Heartbleed: my comments

It has been 11 days since the public disclosure of a major bug in OpenSSL, known as Heartbleed. I have been asked about my thoughts by a few people(both technical and non-technical), and so I find myself writing this blog post. I must mention that security disclosures occur on a weekly(if not, daily) basis, but heartbleed has been one that has stood out, even to laymen. To clear the air, there is a lot of discussion about stolen passwords. This isnt necessarily true. The passwords could potentially have been stolen, but it doesnt mean they have been(and unfortunately, there is no way to know if they have been compromised).

So what is it about? Is it important? What is being overlooked?

What is it, in a nutshell?
Heartbleed is the name that has been given to a bug which was found in OpenSSL. OpenSSL is an open source implementation of the SSL and TLS protocols, which are used for secure communications across a network. OpenSSL is also by far, the most widely used implementation of SSL/TLS in the world. If you have ever logged in to any website on the internet, there is a very good chance that OpenSSL was involved. Some of the major websites that use OpenSSL, are listed in the Heartbleed hit-list.

The bug revolves around a piece of code committed to OpenSSLs codebase in 2012, known as heartbeat. OpenSSL makes use of a process of secret exchanges in order to authenticate the client and server, in order to establish a secure connection. The heartbeat feature is used to keep existing sessions "alive", when there is no data being transmitted. Heartbeat involves an exchange of an arbitrary message from the client to the server, and the subsequent reply from the server, with the same arbitrary message. However, security researchers found that there was no bound check done on this arbitrary message. So they discovered that when receiving their arbitrary message back, they could request a bigger message in response, up to 64K in size.

This meant that the server would "bleed"(hence the name, "heartbleed") the extra bits of information that where not in the original message from heartbeat, and this additional data would come directly from the servers memory. This has been nicely summarised in a comic by XKCD. Due to the nature of heartbleed, there is unfortunately no way that the use of heartbleed could have been detected, and so it is not known if or where the exploit has been used.

What can be bled from the servers memory?
The spoils are random dumps of the next blocks of memory after the heartbeat message. So this may or may not be of use to an attacker. However, it is entirely possible that the data could consist (either in full, or in part) of sensitive information, such as; the servers private key(the holy grail), user names and passwords, credit card information, sensitive documents, confidential communications. The fact that the entire key/password etc wont necessarily be returned, is not a comfort. Because the attacker can simply keep exploiting heartbleed in order to get more data, and ideally all the pieces needed to put the puzzle together.

What I would like to see, is the capture of the random numbers which have been used to create the secret keys. With these, the attacker can generate their own copy of the private key(and perhaps infer some other sensitive details to add to the spoils).

Who is vulnerable?
Heartbeat was introduced with OpenSSL version 1.0.1, and remained unchanged up to version 1.0.1f, so anyone using these versions of OpenSSL are vulnerable. The emergency release of OpenSSL version 1.0.1g on 7th April 2014 fixed the bug, by applying bounds to the heartbeat message. There are a few web services available which you can use to test a website if it is vulnerable(the websites you use, for example). One such service can be found at filippo.io. Java haters will be fascinated to know that the Java standard edition (SE) is unaffected. Microsofts servers are also mostly unaffected, because they tend to use their own implementation of TLS(SChannel). However, other products, such as OpenVPN(which can be used on a microsoft box), do use OpenSSL.

What should you do about it?
The most obvious steps for you to take, would be to change your passwords at any website that has been affected. Indeed, just about every article on heartbleed recommends this. While this is good advice, dont rush out and do it immediately. The reason behind password changes is due to the possibility that your password has already been compromised. But if you change it before the servers OpenSSL has been updated, then your astuteness will not have paid off. If you arent sure that your websites where compromised before the disclosure of heartbleed, you can be sure that there is a much higher chance that they are now. Rather verify that the server has applied the bugfix first(either by testing it with a webservice, or by taking note of any public announcements made by the website).

If you run your own server, you should update your OpenSSL, or recompile it with the -DOPENSSL_NO_HEARTBEATS option, as well as revoking and reissuing all certificates that use SSL/TLS(with new keys, of course. Have fun...), and force client password resets.

One thing which has been bugging me about all the current media coverage to date, is that they are all server centric. I havent seen much mention at all about the possibility that the client is also at risk. Indeed, if a server has been compromised, there is nothing to stop it from using heartbleed against the client. I have found an article about the possibility of a reverse heartbleed attack, where it has been shown that although it is harder to do, the clients(IE. your own devices) are also at risk.

Should we be pointing fingers at anyone about this?
In short, no. Remember that OpenSSL is an open source project. It is the most widely used implementation of SSL/TLS in the world. Not bad for a project run by a core group of four developers, only one of which is considered to be working on it full time. And the pay is next to non-existant. On average, donations to the OpenSSL Software Foundation (OSF) are a meagre $2000 per annum. They do not have the man power to do extensive code reviews, however the larger companies that use the software, do have that capability(and should have reviewed all outsourced code fully anyway, whether the code came from a small group of developers or not).

Some parting thoughts
One question on many peoples minds, is whether or not the NSA has been exploiting heartbleed all along. They claim to have had no prior knowledge of heartbleed, but then they wouldnt admit it if they had known. With their resources and tenacity, I would be surprised if heartbleed was news to them. Other, more paranoid people are saying that since it is known that the US government has worked to weaken encryption standards, they further undermined internet security by not donating any significant amount to the OSF. I think this last is a bit of a stretch. But the real question is, was the bug introduced to the code base deliberately?

Re-issuing certificates is going to be an extremely daunting task to the Certificate Authorities. I doubt they have infrastructure capable of doing all the work in the time frame they have(IE. immediately).

The use of two factor authentication(depending on which kind of 2FA), as well as perfect forward secrecy would have greatly reduced your risk to exposure. Affected servers should be sending out emails explaining the plan of action(change of password etc), but do not trust any link you may find in any of these emails. It could be a phishing attempt(we have all received such emails many times in the past, and this is the perfect opportunity to go phishin').

Lastly, I think it falls on large companies that use OpenSSL to make an effort and donate to the OpenSSL project. The OpenSSL team have done one hell of a job, and have achieved an astounding market share. Perhaps with adequate funding, heartbleed could have been prevented.

Have you got any further questions? Feel free to leave your questions and comments on this page.

Some additional info

Facebooktwittergoogle_plusredditpinterestlinkedinmail
12Mar/120

HTTPS security

 

HTTPS is a secure layering of the HTTP protocol used for communication over a computer network, most notably used on the internet. It achieves this security by using the SSL/TLS protocol, which is the standard as far as securing web applications go. In particular, HTTPS is used by banks, social networks, live streaming services, email, instant messaging and more. SSL/TLS extends HTTP by providing a secure tunnel through which a web browser and web server communicate. By encrypting transmissions, SSL/TLS provides confidentiality and prevents unauthorised and undetected modifications, which preserves integrity.

Authenticity is ensured with a digital certificate, which establishes a binding between a public key and an entity(Eg. address, company name, persons name, hostname etc). In HTTPS' case, the public key is used by SSL/TLS to negotiate a key between the browser and server. The certificate contains the entity with its key, and is digitally signed by a certification authority(CA).

The CA is responsible for checking that the public key and entity really belong together. The entity itself can be a certificate, so the original entity can be wrapped up in certificates signed by multiple CA's. In general, a certificate can be considered valid by a web browser if there is a chain of certificates from a CA the web browser trusts, to the certificate which is checked.

Public Key Infrastructure, in a nutshell
By default, web browsers ship with a list of CAs which they may consider trustworthy. These CAs have been added to the list by the browsers creators, once they have reviewed them. The CA is audited to see if the standards imposed by the CA are sufficient (so far as verifying key-entity relationships are concerned). It is also important that the CAs systems are secure and well tested. The audit should ideally be redone annually, to ensure that the standards are kept, and that new security developments are accomodated for. Of course, the browser vendor has an interest in keeping its list of trusted CAs up to date, or else they will expose their users to potential security risks. Ultimately, the certificate acceptance is determined by the browser if it establishes at least one chain of trust to a CA it trusts.

Public key infrastructure failures

VeriSign-Microsoft certificate
In 2001, and anonymous attacker managed to persuade VeriSign(a major CA) that he was an employee of Microsoft. He was granted several certificates(with his public key) to use as a result. VeriSigns checks in 2001 were clearly not good enough to ensure a secure infrastructure.

MD5 collisions
Cryptographic hashes of the certificate are signed instead of signing the entire certificate(for various technical reasons). In the early days, the most commonly used hash function used was the MD5 hash. Many weaknesses have been found in the MD5 hash, and its use is therefore discouraged these days(in favour of one of the SHA hash functions).

An MD5 collision occurs when two different certificates have the same hash. In this case, a signature on either certificate would also be valid for the other. This was proved in 2008 when security researchers managed to generate their own sub-CA using an MD5 collision. This sub-CA then requested a signature from a CA, and then copied the signature received into their own sub-CA certificate. This meant that they were able to operate their own CA, and issue arbitrary certificates for any hostname and email address they wanted to. Soon after this proof of concept, CAs stopped using MD5.

DigiNotar
Dutch CA, DigiNotar, had become compromised when an attacker gained access to their systems and granted a certificate for *.google.com to himself, and subsequently launched a man-in-the-middle attack on Gmail. DigiNotor was removed from all browser vendors' trusted lists, and soon afterwards DigiNotar went bankrupt. The attacker who claimed responsibility remarked that other CAs were susceptible to attack, and it is therefor only a matter of time before a similar attack happens again.

Preventative measures available
Three measures available can be implemented by the website administrator, and do not require CA involvement, nor do they need to modify certificates.

HSTS
The default assumed protocol for web browsers is HTTP. If a user types an address in their browser, the browser will send an HTTP request. This request would be redirected to HTTPS in the event that the website uses HTTPS. The problem comes in where the redirect request is not protected, and can be exploited via a man-in-the-middle attack which would suppress the HTTPS request, and return a bogus page to the user, in the hope that the user enters valuable details which can be recorded.

HSTS was designed to avoid this, by specifying that every subsequent request sent to the web server shall be done over HTTPS, and that the web browser should never use HTTP on that particular website. Although still in its infancy, HSTS is used by some high profile websites, such as paypal.

Public key pinning
Public key pinning works by the web server specifying which public keys may be used in the certificate chain for a particular website. When a browser connects to the website a second time, the public keys offered in the server certificate chain are compared to the list of allowed public keys for that website. If no certificate in the chain matches at least one allowed public key, the connection is terminated.

DANE (DNS-Based Authentication of Named Entities)
If the CA is compromised, public key pinning wont work because a first time user can be impersonated. DANE can protect even the first visit to a website. Instead of pinning a public key on the first visit, the pins are stored in the users DNS records. Instead of a chain of trust from an arbitrary CA to a certificate for your hostname, a chain of trust from the operator of the DNS root zone to the DNS records for your hostname is established. The benefit of such as system is that there are over 1000 CAs which can issue valid certificates for any host name on the internet, but there is only one authority responsible for a top level domain. DANE is also not limited to HTTPS, and may be used on any SSL/TLS connection. As with public key pinning and HSTS, DANE is still in draft stages.

Presently a combination of HSTS and public key pinning is the best solution for securing a HTTPS web server against compromise or other attacks on CAs. DANEs complexity makes it more preferable when a higher level of security is required, but presently is badly supported amongst the browsers.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Tagged as: No Comments