
OpenSSL site defacement involving hypervisor hack rattles nerves - JohnTHaller
http://arstechnica.com/security/2014/01/openssl-site-defacement-involving-hypervisor-hack-rattles-nerves/
======
haberman
_Fortunately, the attackers didn 't, or weren't able to, use their access to
slip backdoor code into the OpenSSL software, which websites around the world
use to provide HTTPS encryption for the pages they serve. That assurance is
possible because the code is maintained and distributed through Git, a source-
code management system that allows developers and users to maintain
independent copies all over the Internet. Since the cryptographic hashes found
on OpenSSL matched those elsewhere, there is a high degree of confidence the
code hasn't been altered._

A few days ago I posed the question of whether Git's crypto is an example of
dangerous amateur cryptography, since Linus isn't (AFAIK) a crypto expert:
[https://news.ycombinator.com/item?id=6961683](https://news.ycombinator.com/item?id=6961683)

The general answer I got was that Git isn't really crypto, because it isn't
using the hash to guarantee integrity, but simply as a checksum to detect
corruption.

I didn't find this argument very convincing at the time, and I would now offer
the above quotation as evidence that people do in fact treat Git's hashes as a
security mechanism that can withstand an adversarial attack.

~~~
Karunamon
Indeed. Assuming the rest of the code is implemented without any
vulnerabilities (and that's one hell of an assumption about any code), SHA1,
which Git uses as its hashing algorithm, has been completely broken as early
as _2005_ [1].

That said, I'm not sure how you'd go about crafting source code in such a way
as to collide with a known hash without it being amazingly obvious. You could
change history to make it appear as if your crocked code was always there or
had been for a long time, but then you don't have to figure just one hash,
then you have to figure every single hash down to the parent. Depending on the
number of commits, that's a hell of a lot of work, even with an algorithm to
break SHA1.

And even then if you change the hashes, since Git is distributed, the
developers will quickly figure out that what's in one repo doesn't match all
the others when patches start breaking..

[1] -
[https://www.schneier.com/blog/archives/2005/02/cryptanalysis...](https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html)

~~~
insaneirish
Your definition of "completely broken" is misleading.

While it makes complete sense to use SHA-256 and beyond, a collision of two
carefully constructed plaintexts is not indicative of a general break in
SHA-1. It is much more difficult to find a collision against a fixed plaintext
and hash and ridiculously more difficult for that collision to produce non-
gibberish, working code that compiles and creates a vulnerability.

~~~
darklajid
I'm no expert, at all.

Reading your list of complications though I wonder if the last one is really a
problem? Hiding a vulnerability that doesn't look suspicious on first sight?
Agreed. But hiding a vulnerability at all - if compiled without reading the
source? Isn't that 'just' appending /* garbage */ or even code in IFDEFs? In
other words: Is the last point really an issue or is it 'just' a collection
against a fixed plaintext/hash?

------
throwaway125
Have there been recent public disclosures of vulnerabilities in hypervisors?

Breaking out of virtual machines is a really interesting process but it's
important to remember that a hypervisor can be attacked with pretty much the
same techniques you can attack any other program. Virtual machines aren't a
magic contain-all-the-hackers solution. There was an interesting talk on
DEFCON 19 about breaking out of KVM:
[http://www.youtube.com/watch?v=tVSVdudfF8Q](http://www.youtube.com/watch?v=tVSVdudfF8Q)

~~~
res0nat0r
This was a pretty big deal in 2012:
[http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_...](http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php)

------
wmf
There may be some alarmism getting started here. "The attack was made via
hypervisor through the hosting provider" can be interpreted in several ways
and (to me) doesn't necessarily indicate a hypervisor exploit. It sounds like
it could be similar to the Linode admin access hack.

~~~
andrewcooke
i may be misunderstanding (there seem to have been at least two famous hacks
on linode), but why would you use the word "hypervisor" to explain that
someone had hacked your host's admin account? isn't the presence of that word
(the h word) what makes this (potentially) scary?

also, will htp ever come back from exile? (not that it seems too unhappy where
it is).

~~~
wmf
There have been pretty much no hypervisor exploits seen in the wild but plenty
of admin hacks. (This is basically the same as Andrew Hay's argument.) I want
to give the OpenSSL people the benefit of the doubt when they say they saw
Bigfoot, but... are they experts in virtualization? Or are they using loose
terminology (e.g. considering dom0 or vCenter to be the "hypervisor")?

(HTP is stuck in the scarcity trap, so I should probably block off a weekend
to work on it.)

~~~
res0nat0r
Here is a pretty big one from 2012 that was discovered by Rafal Wojtczuk:
[http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_...](http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php)

It didn't get a huge press release and media coverage but it was a pretty big
deal. Probably because there weren't any 0day exploits floating around at the
time so this flew under the radar of the mainstream.

[http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-
pr...](http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-
escalation/)

[http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2012-0...](http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2012-0217)

[http://invisiblethingslab.com/itl/About.html](http://invisiblethingslab.com/itl/About.html)

------
xSwag
No.

Simple logic: The defacement was amature at best. If the group has a 0-day in
a hypervisor they would have gone to multiple hosting companies and multiple
attacks would have taken place, there are many more targets that are worth
much more than openSSL.

Most likely, the administration panel of the hosting company was comprimised
through malware/phishing. Seriously, if a group like this had a 0-day in
hypervisor then they would be doing much much more damage.

~~~
beambot
Defacing OpenSSL's website might be low-value, but backdooring OpenSSL code
(trusting-trust style!) would be about as high-value a target as I could
imagine.

~~~
jonah
If they were smart enough to backdoored the code, I'd hope they were smart
enough to be as stealth as possible and not deface the site too.

~~~
spenvo
There's no way to know that there was only one party involved.

In other words, who's to say that the NSA (/GHCQ,etc) was the same party that
ultimately defaced the website?

------
thirdsight
This doesn't surprise me one bit if its a hypervisor hack. You have to design
in this stuff from day one rather than tack it on as an afterthought. To quote
Theo de Raadt on virtualization, who I agree with:

 _" x86 virtualization is about basically placing another nearly full kernel,
full of new bugs, on top of a nasty x86 architecture which barely has correct
page protection. Then running your operating system on the other side of this
brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide
collection of software engineers who can't write operating systems or
applications without security holes, can then turn around and suddenly write
virtualization layers without security holes."_

------
kyrra
may as well link directly to OpenSSL's post on it (which says the same thing)
[0]. Also, assuming the traceroute on www.openssl.org is correct, this[1] is
their webhost.

[0]
[http://www.openssl.org/news/secadv_hack.txt](http://www.openssl.org/news/secadv_hack.txt)

[1] [http://www.indithosting.se/](http://www.indithosting.se/)

------
zurn
Related:

"Virtually Impossible: The Reality Of Virtualization Security" talk video from
30C3 a few days ago:
[http://media.ccc.de/browse/congress/2013/30C3_-_5445_-_en_-_...](http://media.ccc.de/browse/congress/2013/30C3_-_5445_-_en_-
_saal_6_-_201312292145_-_virtually_impossible_the_reality_of_virtualization_security_-
_gal_diskin.html)

Slides from apparently same talk from Defcon Russia:
[http://www.slideshare.net/DefconRussia/gal-diskin-
virtually-...](http://www.slideshare.net/DefconRussia/gal-diskin-virtually-
impossible)

------
sneak
I think it's common to use "hypervisor" to refer to "hypervisor host" (and
usually not "hypervisor software").

I've been hearing this usage more often these days.

------
justincormack
There is a suggestion it could be an open admin access
[http://www.andrewhay.ca/archives/2343](http://www.andrewhay.ca/archives/2343)

