Heartbleed Bug
As reported yesterday, security researchers have found a nasty bug in OpenSSL, which allows reading the memory of systems protected by the vulnerable versions of the OpenSSL software. This effectively makes the privacy mechanisms relying on this implementation of encryption protocols non-existent. It doesn’t mean that there is no encryption at all thoughs. It merely means that whoever knew about the bug in OpenSSL 1.0.1 released in 2012, could have exploited its flaw since then, codenamed ‘Heartbleed bug,‘ to eavesdrop on any encrypted communication.
The news has been met with steadily growing panic. On the day after initial exposure, the Heartbleed Bug looks pretty much apocalyptic. But is it really that bad?
The short answer: Yes. Potentially.
The longer answer
First of all, it is really really bad. As BBC News put it, “a bug in software used by millions of web servers could have exposed anyone visiting sites they hosted to spying and eavesdropping…”
In other words, it looks like one of the biggest information security breaches ever. One of the longest too. For now, nobody can tell how widely the breach has been exploited, but the hole has been open for two years – OpenSSL 1.0.1 was released in March 2012.
David Chartier, CEO of Codenomicon security firm, told to Associated Press: “I don’t think anyone that had been using this technology is in a position to definitively say they weren’t compromised.”
That’s right. The potential scale of the problem is vast. Paradoxically or not, but it may become much worse now, after the flaw has been widely publicized: it’ll surely take time for all of the OpenSSL users to update their systems, which opens a ‘window of possibilities’ for potential attackers.
By the way, a list of the proof-of-concept exploits for the Heartbleed Bug is already in place. It’s not hard to guess how soon it will take these POCs to turn into working malware.
In detail
OpenSSL is an open-source implementation of the TSL (Transport Layer Security) and its predecessor SSL (Secure Socket Layer) protocols. They both use X.509 standard certificates and hence asymmetric cryptography, also known as public-key cryptography: an algorithm which requires two separate keys – pieces of information or parameters those determine, functional output of a cryptographic algorithm or cipher – one of which is secret (or private) and one of which is public.
The key used to encrypt a message is not the same as the key used to decrypt it. Each user has a pair of cryptographic keys – a public encryption key and a private decryption key. Similarly, a key pair used for digital signatures consists of a private signing key and a public verification key. The public key is widely distributed, while the private key is known only to its proprietor. The keys are related mathematically, but the parameters are chosen so that calculating the public key from a private one is quite easy, while the reverse process is either impossible, i.e. computationally unfeasible or prohibitively expensive.
Thus the public key may be published without compromising security, whereas the private key must not be revealed to anyone not authorized to read messages or perform digital signatures.
There is, however, another problem: confidence and proof that a particular public key is authentic, i.e. that it is correct and belongs to the person or entity claimed, and has not been tampered with or replaced by a malicious third party.
The usual approach to this problem is to use so-called public-key infrastructure (PKI), in which one or more trusted third parties – known as certificate authorities – certify ownership of key pairs. In other words, the certificate authority is responsible for saying “yes, this person is who they say they are, and we, the CA, certify that”. That is, by the way, the exact reason why cybercriminals attempt to compromise CAs all the time: a successful attack allows them to steal valid certificates or a issue false one, which will be recognized as valid (by browsers, for instance).
Well, with the Heartbleed Bug all the precautions regarding cryptographic keys appear to make little sense. A missing bounds check in the handling of the TLS Heartbeat Extension can be used to reveal up to 64k of memory to a connected client or server. As explained by Codenomicon, “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.”
More to the point, a 64k limit applies only to a single ‘heartbeat’: an attacker can either keep reconnecting or, during an active TLS connection, keep requesting the arbitrary number of 64 kilobyte chunks of memory content until they get enough of the information required.
At the time of the Heartbleed’s disclosure, some 17%, or half a million of the Internet’s secure web servers certified by trusted authorities, were believed to have been vulnerable to the attack. At the same time Apache and nginx web server software together hold 66% of shares in the world, and they are both affected by the bug.
Clearly, it’s a security sinkhole, as large as the Yellowstone Caldera, but unlike the natural geological formation, it can be and must be covered by sod promptly. Until then, everyone everywhere is in jeopardy.
What businesses are recommended to do (ASAP)
The first recommendation issued yesterday stated that if one needs secure communications and privacy, it’s time to get off the grid until the dust settles. But this time, dust won’t settle on its own: with the amount of people potentially affected, everyone should make their own moves. First – update your OpenSSL to 1.0.1g (released on April 7th) wherever it is used: web server software, open source operating systems; then change all your passwords. Especially those used to access sensitive data.
If you are an owner of a web service that uses a vulnerable OpenSSL implementation, there is a reason to go offline just like, according to BBC, Mojang did, the maker of the hugely popular Minecraft game. It took all its services down while Amazon, which it used to host games, did the necessary bug-busting. It does mean possible losses and users’ discontent, but then again: if the risks persist and a possible attack is successful, discontent would be much worse.
Unfortunately, for businesses working with other people’s data it is also imperative to notify users about possible leaks and the immediate need to change passwords.
The world’s largest news media have already reported on the bug, so public awareness is growing, but people still need to be informed.
In addition to changing passwords, new digital certificates should be requested from CAs ASAP and new encryption keys should be generated. Without this, simply updating OpenSSL in your servers will do nothing: if attackers have already exploited the vulnerability, they could steal encryption keys, passwords or other credentials required to access a server, so they just can come in and get out with any critical information, without leaving a trace.
Ladies and gentlemen, have you changed your passwords already?
Tips