Heartbleed: a serious security bug. What should I be doing?

In My Humble Opinion
41

News roundup:
As reported earlier, Cloudfare Challenge conquered. The first white hat cracker to acquire the keys was Software Engineer Fedor Indutny of Russia, after 2.5 million server requests. Let’s give him a round of applause. Runners up were Rubin Xu, PhD student in the Security group of Cambridge University and Ben Murphy of the British Isles. I think. We need more North American hackers.
Did Open Source matter for Heartbleed? TLDR: We need to set up hacker bounties for core open source programs like OpenSSL. Microsoft, Google, Apache and others already do that for their proprietary stuff.

Akamai Heartbleed patch not a fix after all: “The Web infrastructure company’s patch was supposed to have handled the problem. Turns out it protects only three of six critical encryption values.” I do not understand this article, nor its implications except that it implies less sleep for our brave IT engineers.

Q: What’s a good specialist forum that discusses these issues? Tom’s Hardware? Slashdot? Reddit? What?

42

Not immediately. But…

…Remember that scene in Star Trek II: The Wrath of Khan, where Kirk makes up for his earlier blunder by using the Enterprise console to make the Reliant lower her shields?

As they’re looking up Reliant’s command code and plugging it into Enterprise’s helm, Lt. Saavik asks Kirk what he’s doing. Kirk replies absently, “You’ve got to learn WHY things work on a Starship.”

In this case, it’s good to think about what’s happening behind the scenes. The typical web application is a front-end webserver, running Apache/Tomcat/Orion/some other httpd, and talking to a back-end database server, Oracle/mysql/whatever else.

Typically, the front end web server is the only interface that’s exposed to the public internet. The front end web server sits in a DMZ, a “Demilitarized Zone,” a section of the company’s network that permits inbound traffic. The web server is only accessible from the internal company network – which of course includes the DMZ, but does NOT include you at home. So the short answer is that the database server is safe.

BUT: not really. Because if the credentials the web server uses to authenticate to the database server have been exposed – and this is not all that unlikely, if the back-channel communication between the web server and the database also use SSL – then the enemy has a username and password that works to access that database.

Now, what they still don’t have is a place to do it from. But if they can compromise the server and upload a webshell, then they can use the webserver as a beachhead and log in to the back-end database.

This requires more weakness than just Heartbleed – there would need to be some exploitable weakness in the Linux box that allowed the webshell, for instance. But you’d be amazed at how often there’s a SQL Injection vulnerability out there in the web design.

In short: it’s not impossible. It requires more than just Heartbleed.

Lots of folks won’t change internal passwords until after they patch. And if they were compromised in the meantime, maybe the hacker added his own credentials, so even if other accounts are changed, he can still get in.

43

Goodness, imagine a SQL Injection weakness in WordPress or vBulletin !

44

Long before this Heartbleed business existed Akamai made some change to their version of OpenSSL that would supposedly make it more secure than the official OpenSSL version. When Heartbleed came out Akamai thought that the changes they had made earlier would protect them from it. They were wrong.

In short the Akamai “patch” being talked about was not a patch designed to fix Heartbleed but one that existed long before Heartbleed. They were just silly enough to announce that it had also pre-empted heartbleed and there fore that their OpenSSL version was secure. This turned out not to be true.

The patch released by OpenSSL since Heartbleed was revealed, and specifically designed to fix Heartbleed, does in fact fix Heartbleed. Akamai was just wrong about whether they were as vulnerable as everyone else before that fix was released.

45

There’s a big difference between “ssl private key” and “certificate”. So far we know that SSL private keys can be obtained. Please correct me if I’m wrong, but I assume that SSL uses a new private key for every session. (Whether that’s a TCP connection or a higher level session, I’m not sure, but I suspect it’s higher level: you get a new session each time you log in. If I’m correct on this, a session could last for a couple weeks at many sites, and only for hours or less on others.)

That would not leak your password.

I’m not quite sure what it would permit a hacker to do. If the hacker could also intercept (monitor) your traffic to and from the server, he could decode the messages. However, if I’m guessing correctly, your password would have been used earlier (and never sent in the clear, and sent only in a way that allows the server to check “good vs bad”).

I don’t think it would permit the hacker to pose as the server, without also hacking the network to intercept traffic to the server’s IP address (or to masquerade as the server by hacking DNS, on a subsequent TCP connection to the same server after long enough for your DNS entry to time out.)

I think it’s prudent to assume the worst, though.

My knowledge of security is limited to studying the basic mechanisms and their applications to network layer security, in the late 90’s, as the principle engineer on a project that my company bid on and won but our customers did not win their bids, so I never got to find out how right or wrong I was in my estimates. I’m sure I’ve forgotten and misremembered a lot since then. I’d appreciate anyone with a practical knowledge of security mechanisms and especially SSL to shed more light on this.

BTW, one of the quotes above mentions “stack data”. This is a heap attack, and will not expose any stack data, so whoever wrote that was mistaken, or I’m missing something myself.

Stack vs. Heap: Heap is when your program asks for and gets a specific sized segment of memory to use temporarily and return (though, you can keep it as long as you want, as long as you don’t routinely lose it and ask for another.) Stack is where a function or procedure’s local variables are stored, if they don’t fit in the CPU registers. It’s also where the contexts of calling procedures or functions are stored when calling a new procedure or function. Lots of data can naturally appear in either place, but buffers for received packets are very rarely – maybe never – allocated on the stack.

46

You’re wrong.

Well, let’s be clearer: you’re correct that there is such a thing as a “session key.” But there is ALSO such a thing as a server private key. The session key, as you intuit, is unique to every session. But the server private key remains the same as long as the signed SSL certificate used by the system remains the same.

When your browser negotiates an SSL-encrypted session with the server, the server supplies you with its public key. Your browser encrypts a random number using the server public key and sends that encrypted result back to the server. The server’s public and private keys are asymmetric, meaning a package encrypted with the server’s public key can only be decrypted with the server’s private key. So even if an eavesdropper is listening to that negotiation, the eavesdropper can’t determine what random number your browser sent the server.

The server receives the encrypted package and decrypts it using its private key. Now you and the server share a secret: the random number. that number is used by both of you to generate a symmetric session key, which again should be impervious to an eavesdropper, since the eavesdropper doesn’t know the symmetric key.

Now let’s add Heartbleed to the mix. There are now two avenues for compromise. First, the server’s private key may have been read from its memory. This means an eavesdropper can, in fact, decrypt the random number used by the browser to create a session key, and in turn independently create an identical symmetric session key.

Secondly, the session key may itself be present in heap memory and can be read and used by an eavesdropper.

Usernames and passwords in clear text may also be present in server heap memory. These may be used to directly authenticate to the server without needing to eavesdrop on a session.

Sure. With a small amount of effort, I can impersonate bank websites while sitting at Starbuck’s, supplying users my own rogue DNS information and a “signed” SSL certificate that lets your browser display the little “lock” icon that says, “Everything’s safe.”

Correct, but openssl dumps a bunch of stuff in heap, including the internal private key as well as contents passed via httpd.

47

News roundup:

NYT: Study finds no evidence of Heartbleed attacks before bug was announced. As I understand it, 2 of the internet’s nodes examined their traffic and found no evidence. They keep copious records, at least as far back as January. Also, a hacker was arrested in Canada; he had been trying to breaking into the tax authority’s computers after the announcement. Study Finds No Evidence of Heartbleed Attacks Before the Bug Was Exposed - The New York Times
Crowdfunding: they are trying to raise money for a bounty on future Open-SSL bugs. I would want to examine the legitimacy of these fund raisers before donating. Also, this is something that should be organized by the tech industry, with matching funds by the Feds IMHO. Move along, folks: nothing to see here. OpenSSL bug hunt: Find NEXT Heartbleed, earn $$$ – if enough people donate cash • The Register
Tor network shrinks as some of their nodes haven’t been patched yet. Tor anonymity network to shrink as a result of Heartbleed flaw | PCWorld
Some days ago, Brian Krebs mentioned that there had not been an uptick in stolen credit cards at the main scuzball dark sites. It looks to me like we’ve basically dodged this bullet, subsequent phishing notwithstanding.
And in other news, Critical Java Update Plugs 37 Security Holes. Just so you know.

48

There’s a fairly good, sceptical, article on this alleged problem in of all places Slate.
**Are there other zero-day bugs in OpenSSL, or in other core infrastructure like Apache or BIND? Almost certainly. And OpenSSL’s lack of funding is not the only problem. After all, Apple’s “goto fail” disaster was created by one of the richest companies on Earth. Target managed to lose 40 million credit-card numbers to hackers. Microsoft patches its Windows security vulnerabilities monthly if not more often—and sometimes it tells the government about them first—and somewhat shady operatives around the world trade so-called “zero day” exploits that haven’t yet been discovered by the security community. The NSA spends your hard-earned tax dollars purchasing security exploits from firms like the French Vupen. In 2012, the going price for an unrevealed iOS exploit was up to $250,000, according to a Forbes investigation; a Windows exploit would only net you $120,000.
**

The only way to explain the hysteria was that it was badly leaked — not by Google, the discoverers, nor the OpenSSL people, before patches were in place; some saddos wanted to rag on Open Source ( delightfully, some of these called it a virus ); the more famous security experts jumped in on the bandwagon loudly to maintain their cred.
So far very little harm has been reported — perhaps your passwords or certificates were stolen two years ago and you didn’t notice, but were that the case you have bigger problems than passwords or certificates being stolen — other than 600 Canadian social security numbers being stolen by a teenager in the 6 hours after the initial revelation, who was quickly arrested; and a British site called mumsnet being hacked, which was kinda [funny](‘Am I Being Unreasonable to think that the vast majority of you are clearly insane?’): it’s not as if sites haven’t been hacked since the dawn of internet time…
Had it been proprietary code, such as Microsoft or maybe Oracle, it’s less likely the mistake would have been found by scrutineers, and the web infrastructure would become enormously expensive, leading to less sites, the majority being corporate — the latter trend making very little difference to Google search.
As it is the clean-up costs are majorly the enormous changeover in certificates, which is overwhelming the issuers. And the sky will continue falling for some other reason soon enough.

49

Thanks! Ignorance fought.

50

News roundup:

Fallout from the heartbleed bug will be with us for a while. The bad guys have scope for using old certificates (if they have them) even after they have been replaced. The problem as I understand it is that browsers don’t track security certificates that well. IE and Opera are better, Chrome and Firefox are worse. Did I get that wrong? Correct me!
Tech companies pony up $3.9 million over 3 years to fund critical internet infrastructure: first on the list to be considered is OpenSSL. It’s called the Core Infrastructure Initiative and for some reason Yahoo isn’t part of it.

OpenSSL is being forked: LibreSSL will try their hand at the task. OpenSSL is such a mass of spaghetti code, that they are basically starting over. Their fundraising gimmick was to create their webpage in Comic Sans and blinking tags, holding it hostage until goals are reached. Brutal!