Slashdot Mirror
One Month Later: 300,000 Servers Remain Vulnerable To Heartbleed
DavidGilbert99 writes: "The Heartbleed Bug cause widespread panic from internet users around the world worried their sensitive information was being targeted. While system administrators were warned to patch their systems, a security researcher notes that 300,000 servers remain vulnerable to the heartbleed flaw a full month later. He said, 'Last month, I found 1-million systems supporting the "heartbeat" feature (with one third patched). This time, I found 1.5-million systems supporting the "heartbeat" feature, with all but the 300k patched. This implies to me that the first response to the bug was to disable heartbeats, then later when people correctly patched the software, heartbeats were re-enabled. Note that only OpenSSL supports heartbeats, meaning that the vast majority of SSL-supporting servers are based on software other than OpenSSL.' A developer at Vivaldi Technologies AS also pointed out that a significant number of server administrators botched their response, going from safe to vulnerable."
What would help is if there were some certificate system that didn't rely on extortion or exorbitant prices. I know several admins that mitigated the hole but couldn't replace their certificates either because the signer charges a ridiculous revocation fee (I'm looking at you, StartSSL), or because the cost of cutting and signing new certificates was too high. We need a better trust system.
"Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
I am not a systems administrator (I am a software designer, when I do administration it requires a lot of trail and error.), I do however have to setup an SSL site once every few years. And because of the rarity of this action this is one of those jobs that are difficult to do, compared to other jobs. Sure if your web browser is installed via an Apt-get you are good. However there are times where you need to install it manually, and then you fight and tinker until SSL works, when it does work, your tendency is not to tinker with it anymore.
The issue with Heart Bleed is that it effects open SSL, one of the trouble maker libraries, that require more then just the Basic make config & make & make install.
Now there are a lot of sites setup my armature system admins, many who are less technical then I am, who will get it going and let it run. There isn't any enterprise architecture, the web site is running on a single PC with a single hard drive, chances are the hard drive had already died, and the site is just running from active memory.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
As I understand this, a vulnerable server can expose its private SSL key to an attacker. With this private key, I can decrypt all of its encrypted SSL traffic.
This correct so far?
Now, as I understand this so far, having the private key is great, but I need to be able to MITM the connection to decrypt anything.
How hard is this? At the transport layer, this would require snooping the network connection of the server; someplace locally on the LAN (easiest, port mirror, maybe) or at the ISP (harder, maybe less likely).
The other option would be some kind of DNS spoofing/vulnerability/cache poisoning, redirecting all the server traffic to a system I controlled and then piping it back out. How likely is this?
...because we're waiting for vendors to issue patches.
1) who is the "we" you refer to? 9 times out of 10, there are workarounds, ranging from shutting off the heartbeat feature in OpenSSL to parking an SSL proxy host or load-balancer (depending on application) in-between your affected box and the rest of the planet. And yes, it's that fucking important.
2) The "new, latest security hole" in this instance can turn your company's reputation and sales into rancid mush should you get compromised, and in this case, there's no easy way to catch it before they get in. Oh, and don't ask about the potential for lawsuits that a data breach can generate from pissed-off customers.
3) If a vendor hasn't coughed up a fix by now? Stop using the product, and/or learn enough about it to wedge in your own fix until you can replace the product with something whose vendor is more responsive.
4) Sibling isn't entirely flamebait... a competent sysadmin is more than just a keyboard button actuator - he/she should have enough technical mojo to cook up a means to help protect his career and his company in cases like this. If one of my admins told me what you just wrote without providing solid proof that no workaround exists, I'd sit him down and ask him if he really wants to continue his career as a sysadmin.
Quo usque tandem abutere, Nimbus, patientia nostra?