The Heartbleed Bug

Past and present notices and rants from the Editor. Please feel free to discuss the topics posted, but please do NOT add new topics. Thanks.
Post Reply
User avatar
editor
Site Admin
Posts: 679
Joined: Thu Feb 21, 2013 9:24 am
Contact:

The Heartbleed Bug

Post by editor » Wed Oct 08, 2014 8:41 am

April 10th: Regarding the Heartbleed Bug. A vulnerability has been uncovered in all versions of OpenSSL, which is the encryption software protecting nearly all ecommerce on the Internet. Apparently, this bug has existed since December 31, 2011, and has allowed attackers to view private encrypted data on effected websites. Most virus warnings you read on the Internet are re-hashed hoaxes, but it appears this one is for real.

OpenSSL is open source software. Open source is usually immune, or nearly so, to these kind of vulnerabilities. The reason for this is because, since the source code is open and available for anyone to see, flaws such as this usually come to light quickly, and are fixed. The fact that this vulnerability has existed for more than two years leads me to believe it was most likely engineered by people in the U.S. government (NSA), and that these same people have been the primary attackers taking advantage of the bug.

The existence of the bug became known on April 7, three days ago. On the SAME DAY, the developers of OpenSSL released a patch which disables the bug, and stops the attackers dead in their tracks.

It is important to realize that this software is used by both Unix based, and Windows based servers, and that any server which is not upgraded with a patched version of OpenSSL will remain vulnerable. It is my understanding and belief that when vulnerabilities come to light, Windows based servers are usually vulnerable for a much longer period than Unix based servers-- first because Microsoft takes their sweet time about releasing security updates, and second, because (in my opinion) the administrators of Windows servers tend to be less diligent and/or less competent.

In any case, I want to caution all of our readers about this bug. Some servers may go unpatched for years! Users of large servers such as Yahoo, Facebook, Gmail, Amazon, etc., are the biggest targets. It is assumed they will all patch their servers promptly, if they have not done so already, but I advise you to do some checking to be sure, particularly if you use any financial services over the Internet. Experts are suggesting the average internet user wait a week or so for things to "shake out", before conducting business online.

To our Patrons: We thank you again for your support. Please rest assured that we patched our own servers moments after receiving notice of the bug. I have also personally verified that Paypal guarantees they have no vulnerabilites to this bug.

The important question to ask your vendors is this: What is the build date of the version of OpenSSL on your server? If the date is prior to April 7, 2014, do not conduct business with them until they upgrade.
--
Editor
Lawfulpath.com
User avatar
editor
Site Admin
Posts: 679
Joined: Thu Feb 21, 2013 9:24 am
Contact:

Re: The Heartbleed Bug

Post by editor » Mon Nov 03, 2014 8:21 am

I've just returned from a weekend-long tech security conference. I sat through a very interesting session on the Heartbleed Bug, and I want to get this written down while I still remember most of it.

Turns out this thing is much nastier than I had originally thought, and the problem is far from fixed.

The nature of the bug, and the reason it continues to be a problem is a little technical, but I'll try to explain it in layman's terms, as best I can. Please remember I'm paraphrasing this info from what I learned from a professional security analyst, which I am not. I'm likely to make some technical errors in my explanation, as well as leave out parts I've forgotten or never understood, but I'll try to give you the gist of it.

Heartbleed is the name given to a vulnerabilty in an encryption program called OpenSSL. Encryption is another word for secret code.

When you visit any website, before that information gets from the website to you, or vice-versa, it may bounce through as many as a dozen other computers, each one handing the data to the next, until it reaches its destination.

Ordinary websites communicate in both directions across the Internet in plain text. That means if anyone happens to be looking at the datastream going across the lines, or through those other computers, they can read everything. This includes authentications like usernames and passwords.

For most things this is okay. If you're looking at Wikipedia, or the latest scores for the game, this is stuff anyone can get anyway, so who cares if it's in plain text? No one. But some things need to be kept private.

When you use a browser to access a site that is supposed to be keeping secrets, such as your banking or medical information, or your credit card number, websites handling this kind of information generally use encryption, and in almost every case that means they use OpenSSL. Most browsers will tell you when encryption is being used by displaying a lock somewhere on the page. You can also verify this by looking at the address of the site in the location bar. If it starts with https it's encrypted. If it starts with http without the "s", it is not encrypted.

When two people (or two computers) use a code, there has to be a key, so the information can be read by the right person at the other end. OpenSSL uses a really cool kind of encryption that uses something called a key-pair. This is really two keys, which are uniquely paired to each other. One is called a private key, and the other is a public key. If a message is encrypted using the public key, it may only be decrypted (decoded) using the private key. If it is encrypted with the private key, it can only be decrypted with the public key.

When you click on the link for a secure website, thereby starting an https connection, the first thing the browser needs to check is that the server you connect to is really the right one, and not some crook impersonating the place where you intend to connect. Such impersonation is much easier than most people think. Without some way of verifying server identity, you have no idea whether you connected to your bank, or a scam artist in Nigeria.

Servers equipped with the ability to provide a secure connection obtain a certificate from a recognized organization called a "Certificate Authority" (CA). The certificate is really a key-pair and is in two parts. The CA keeps the public key, and the server keeps the private key. When you click on the link for the secure site, behind the scenes your browser goes to the CA and causes a bit of encrypted information to be sent to the server using the public key the CA has on file. The server sends back a reply, encrypted with the private key, which can be read with the public key. If the reply is correct, then identity is confirmed.

The server should never show anyone its private key. That's the only thing that can confirm its identity. If ever a hacker can get a copy of a server's private key, he can convince any computer that he (the hacker) is really the server.

The Heartbleed Bug causes something called a buffer overrun. Basically it forces the server to give up its private key to whoever knows the right way to ask. Needless to say, this is very bad.

By now, most (surely not all) servers running OpenSSL have patched the bug. This means anyone who hasn't already made a copy of their private key probably won't be able to get it any more (unless there's another vulnerability we don't know about). But what about the crooks who may already have a site's private key?

In theory, this problem could be overcome by the server first patching the buggy OpenSSL, and THEN revoking their certificate, and getting a new one. Trouble is, most companies did not revoke their certificates, because the most widely available instructions for fixing the bug did not include in the instructions that they should.

That problem is bad enough, but it goes deeper. When this certificate system was first implemented, it was envisioned that keys would seldom ever be revoked, and that every key would expire within six months, or at longest a year. Now, in practice, keys may last as long as sixteen years. And what happens when huge numbers of keys are revoked all at once (as they now need to be). How does this revocation process work?

Turns out the CA doesn't delete the old key. Instead it puts a note in its database that the key has been revoked, and lists a pointer to the new key.

This database is becoming huge, and is sometimes very slow to access. Most browsers are set for "soft fail", which means if a certificate fails to authenticate, the browser connects anyway in plain text.

Another problem is the potential vulnerability of the CA itself. I a CA was ever hacked, and the revocation list deleted, then the CA would start authenticating the old compromised keys. There isn't just one certificate authority, so this is a very real concern. Some CAs undoubtedly have worse security than others.

I remember reading, maybe fifteen years ago, that banks routinely lost an insane amount to ATM machines, through fraud and theft. They kept using them anyway because they considered it important to condition the public to use them, and I guess they figured the security would get better over time.

The point I'm making is that banks never openly disclosed the problem with these machines to the public. They (probably rightly) thought that if more people knew how vulnerable the machines were (are), then even more would be stolen.

Will theft due to Heartbleed be treated any differently? I don't know, but I suspect not. Disclosing the depth of the problem would chill Internet commerce, so my guess is that much of the theft, if indeed this actually happens, will be covered by banks and go unreported in mainstream media. But that's only my guess, and the outcome remains to be seen. Unless significant changes are made in the way these certificates are authenticated, Hearbleed may continue to be a problem for the next sixteen years.

Anyone who has additional (or better) information is invited to please contribute it to this Forum, and I'll happily amend anything which may be inaccurate or misleading.
--
Editor
Lawfulpath.com
Post Reply