6 ms·

OpenSSL site defacement involving hypervisor hack rattles nerves

59 points by JohnTHaller 13y ago

kyrra 13y ago
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/
throwaway125 13y ago
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 13y ago
  This was a pretty big deal in 2012: http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_...
- aliguori 13y ago
  Technically that was breaking out of QEMU. It was not KVM specific. If you break into QEMU, you should be a non-privileged user. If you are using libvirt, you are in a cgroup based jail (basically a container) with SELinux being enforced too. So after breaking into QEMU, you would still need to break out of the container before you could attack anything. But Nelson's exploit was pretty cool. I initially thought remote code execution wasn't possible and he turned around pretty quickly with the exploit. It's quite impressive.
wmf 13y ago
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.
- meowface 13y ago
  That was my impression, too. It sounds more likely a hosting company admin had malware installed or re-used passwords, which naturally would give attackers full access to all VMs hosted by the provider. Considering the amateurish defacement, I think that's far more likely than some sort of a Xen/KVM breakout exploit. If there was such a zero-day, some group would probably be going after numerous providers in secret, not doing something like this.
- andrewcooke 13y ago
  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 13y ago
    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 13y ago
      Here is a pretty big one from 2012 that was discovered by Rafal Wojtczuk: http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_... 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-privilege-escalation/ http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-pr... http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0217 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0... http://invisiblethingslab.com/itl/About.html http://invisiblethingslab.com/itl/About.html
deleted 13y ago
[deleted]
justincormack 13y ago
There is a suggestion it could be an open admin access http://www.andrewhay.ca/archives/2343 http://www.andrewhay.ca/archives/2343
sneak 13y ago
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.
xSwag 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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?
haberman 13y ago
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.
- ams6110 13y ago
  detecting corruption is pretty much the same thing as detecting changes though right? Git uses SHA-1 hashes (I think). If someone managed to change the code in a way that still properly compiles AND doesn't change the checksum hash, well... pretty unlikely.
  - 0x0 13y ago
    Not at all unlikely. Plenty of places to put adjustment bits to correct into a hash collision, like in comments, firmware blobs, unused files. One of the md5 collision examples from earlier was two postscript files that both parsed fine but had different messages.
    - a-nom-a-ly 13y ago
      You might have a point regarding binary blobs but, IMO, if they can alter text(comments, source, etc.) in such a way that it's not obvious to the human reviewer, then they deserve to succeed. I don't know what `unused files` means. Git used `sha1` last time I checked, so I'm not sure why you mention `md5`.
zurn 13y ago
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_-_saal_6_-_201312292145_-_virtually_impossible_the_reality_of_virtualization_security_-_gal_diskin.html http://media.ccc.de/browse/congress/2013/30C3_-_5445_-_en_-_... Slides from apparently same talk from Defcon Russia: http://www.slideshare.net/DefconRussia/gal-diskin-virtually-impossible http://www.slideshare.net/DefconRussia/gal-diskin-virtually-...
thirdsight 13y ago
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."

59 points by JohnTHaller 13y ago

kyrra 13y ago

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/

throwaway125 13y ago

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 13y ago
This was a pretty big deal in 2012: http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_...
aliguori 13y ago
Technically that was breaking out of QEMU. It was not KVM specific. If you break into QEMU, you should be a non-privileged user. If you are using libvirt, you are in a cgroup based jail (basically a container) with SELinux being enforced too. So after breaking into QEMU, you would still need to break out of the container before you could attack anything. But Nelson's exploit was pretty cool. I initially thought remote code execution wasn't possible and he turned around pretty quickly with the exploit. It's quite impressive.

wmf 13y ago

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.

meowface 13y ago
That was my impression, too. It sounds more likely a hosting company admin had malware installed or re-used passwords, which naturally would give attackers full access to all VMs hosted by the provider. Considering the amateurish defacement, I think that's far more likely than some sort of a Xen/KVM breakout exploit. If there was such a zero-day, some group would probably be going after numerous providers in secret, not doing something like this.
andrewcooke 13y ago
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 13y ago
  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 13y ago
    Here is a pretty big one from 2012 that was discovered by Rafal Wojtczuk: http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_... 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-privilege-escalation/ http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-pr... http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0217 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0... http://invisiblethingslab.com/itl/About.html http://invisiblethingslab.com/itl/About.html

deleted 13y ago

[deleted]

justincormack 13y ago

There is a suggestion it could be an open admin access http://www.andrewhay.ca/archives/2343 http://www.andrewhay.ca/archives/2343

sneak 13y ago

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.

xSwag 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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?

haberman 13y ago

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.

ams6110 13y ago
detecting corruption is pretty much the same thing as detecting changes though right? Git uses SHA-1 hashes (I think). If someone managed to change the code in a way that still properly compiles AND doesn't change the checksum hash, well... pretty unlikely.
- 0x0 13y ago
  Not at all unlikely. Plenty of places to put adjustment bits to correct into a hash collision, like in comments, firmware blobs, unused files. One of the md5 collision examples from earlier was two postscript files that both parsed fine but had different messages.
  - a-nom-a-ly 13y ago
    You might have a point regarding binary blobs but, IMO, if they can alter text(comments, source, etc.) in such a way that it's not obvious to the human reviewer, then they deserve to succeed. I don't know what `unused files` means. Git used `sha1` last time I checked, so I'm not sure why you mention `md5`.

zurn 13y ago

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_-_saal_6_-_201312292145_-_virtually_impossible_the_reality_of_virtualization_security_-_gal_diskin.html http://media.ccc.de/browse/congress/2013/30C3_-_5445_-_en_-_... Slides from apparently same talk from Defcon Russia: http://www.slideshare.net/DefconRussia/gal-diskin-virtually-impossible http://www.slideshare.net/DefconRussia/gal-diskin-virtually-...

thirdsight 13y ago

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."