OpenSSL site defacement involving hypervisor hack rattles nerves (updated)

The official website for the widely used OpenSSL code library was compromised four days ago in an incident that is stoking concerns among some security professionals.

Code repositories remained untouched in the December 29 hack, and the only outward sign of a breach was a defacement left on the OpenSSL.org home page. The compromise is nonetheless rattling some nerves. In a brief advisory last updated on New Year's Day, officials said "the attack was made via hypervisor through the hosting provider and not via any vulnerability in the OS configuration." The lack of additional details raised the question of whether the same weakness may have been exploited to target other sites that use the same service. After all, saying a compromise was achieved through a hypervisor vulnerability in the Web host of one of the Internet's most important sites isn't necessarily comforting news if the service or hypervisor platform is widely used by others.

Update: About 12 hours after this brief was published, OpenSSL updated the advisory to say: "The OpenSSL server is a virtual server which shares a hypervisor with other customers of the same ISP. 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."

Shortly after this brief was published, VMWare posted an advisory saying that there's no evidence any of its products were involved in the compromise.

"The VMware Security Response Center has actively investigated this incident with both the OpenSSL Foundation and their Hosting Provider in order to understand whether VMware products are implicated and whether VMware needs to take any action to ensure customer safety," VMWare Senior Software Security Leader Iain Mulholland wrote. "We have no reason to believe that the OpenSSL website defacement is a result of a security vulnerability in any VMware products and that the defacement is a result of an operational security error."

It wouldn't be surprising to learn that the authors of the OpenSSL post were using the term "hypervisor" when they meant something closer to the host on which OpenSSL's virtual private server guest was located. Based on data returned from trace route commands, several observers have speculated that OpenSSL's provider is IndIT Hosting. The company's website indicates it uses both ESXi and KVM virtualization platforms.

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.

Still, it wasn't that long ago that OpenSSL used a source code management system that didn't provide as much anti-tampering assurance. Hackers who were able to access OpenSSL servers during that time may have had more room to do something considerably more malicious and stealthy than a simple homepage defacement. OpenSSL has pledged to provide more details in the future. Users should demand a thorough autopsy. And while they're at it, they should demand that the official maintainers of both the PHP Web scripting language and the Linux operating system kernel make good on promises to provide autopsies of serious compromises on their own servers.