STE WILLIAMS

OpenSSL, the widely-used open source cryptographic library, has been all over the news lately.

At the end of 2013, the project announced a flaw – actually, an unreconstructed bug – that caused a formally-approved part of the software not to work at all.

Normally, that would cause the wringing of hands, and perhaps even the gnashing of teeth.

But on this occasion, the dysfunctional algorithm was one that is now widely considered to be tainted by the machinations of the NSA, which allegedly tried to weaken it on purpose, for its own cryptanalytic advantage.

So this ended up as a “good bug” that attracted a lot of interest, ultimately leading to a curious paradox.

The main page of the OpenSSL website was hacked and defaced – by cybervandals who left an oxymoronic message of support:

TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _

This, of course, immediately raised the question, “Did the crooks get at the official repository of the OpenSSL source code?”

The answer is, almost without doubt, “No.”

There are many copies of the OpenSSL source tree scattered liberally around the internet, not least because the project makes use of a distributed source code control sytem.

So any anomalies inamongst the source code in the project’s official repository would, almost without doubt, be obvious.

But how did a high-profile web site like OpenSSL’s get hacked at all?

That’s where the story gets confusing.

Unfortunately, with 6/6 hindight, it seems that OpenSSL didn’t choose its words terribly wisely over New Year, when it said:

Tthe attack was made via hypervisor through the hosting provider and not via any vulnerability in the OS configuration.

A hypervisor is a software component that allows multiple VMs (virtual machines – software computers, if you like) to coexist and be managed on a single physical computer.

Each VM runs not merely as a separate operating system process, but almost as if it were a separate server.

You don’t just run an application inside a VM – you boot it up like a real server and install a fresh operating system of your choice, followed by the software you plan to use.

A service provider can use a hypervisor to split a physical server between several customers, with the hypervisor taking care of the configuration and management of each VM, or “guest.”

A “attack via hypervisor,” then, could be something as simple as a fault in the management interface causing it to report the status of a VM incorrectly.

Or it could be something as potentially catastrophic as a security hole allowing one VM to access and manipulate reources – memory contents, processes and files, for example – belonging to another.

Many news sources chose the latter explanation – it makes a better story, to be sure! – with a raft of credulous headlines trumpeting “facts” that turned out to be misleading at best, and untrue at worst.

Ars Technica’s Dan Goodin, for example, led with:

OpenSSL site defacement involving hypervisor hack rattles nerves

Crowdsourced techie newsfest Slashdot offered:

OpenSSL.org site defaced – subverted hypervisor suspected

Reddit had the accurate but only slightly less dramatic:

OpenSSL website hack was conducted via hypervisor

The overarching implication in all of these was that the defacement was due to an exploitable vulnerability in the hypervisor, allowing some sort of “VM escape.”

That’s where a guest VM is able to trick the hypervisor into letting it meddle in another guest VM on the same hardware, or to meddle with the hypervisor, or even to subvert the so-called host operating system that controls the physical hardware and runs the hypervisor itself.

A bug like that would be serious, because it might be an exploit that could affect thousands, or even millions, of virtual servers around the world.

Good news.

Stand down from puce alert.

OpenSSL has now adapted its notification slightly, offering a clearer explanation:

Our investigation found that the attack was made through insecure passwords at the hosting provider, leading to control of the hypervisor management console, which then was used to manipulate our virtual server.

The joys of cloud computing, eh?

And the woes of poor password hygiene.

As I suspect my colleague Chester Wisniewski would say, “Where was the two-factor authentication?“

Interested in how two-factor authentication could have helped?

(Audio player above not working for you? Download to listen offline, or listen on Soundcloud.)

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/2CMfKkaTR8Q/