Here is the latest (and hopefully last) update on the Openssl.org breach that I covered here and here.

Roughly 5 hours ago Mark Cox, Senior Director, Product Security at Red Hat and Founder/Core Team Member at The OpenSSL Group, commented on one of my earlier blog posts. In his comment, Mark pointed me to the updated version of the Openssl.org breach disclosure which now reads:

Website defacement: final details.
==================================

Last updated: 3rd January 2014

On Sun 29th December 2013 at around 1am GMT the home page of www.openssl.org was defaced. We restored the home page just after 3am GMT and started forensics, investigation, and recovery.

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.

The source repositories were audited and they were not affected.

Other than the modification to the index.html page no changes to the website were made. No vulnerability in the OS or OpenSSL applications was used to perform this defacement.

Steps have been taken to protect against this means of attack in future.

As I suspected, insecure passwords at the hosting provider were to blame and not some crazy 0day.

Summary: Better access control and clear breach details required.

Case closed.

Earlier today I published a blog post entitled Openssl.org breached via…the provider’s hypervisor? Luckily, Iain Mulholland, a “Software Security Guy at VMware” reached out to me via Twitter.

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.

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.

So it looks like we’re not talking about a hypervisor-popping or virtualization container-breaking 0day after all.

Based on the disclosures by both involved vendors, I’m leaning towards the VMware account at this time. However, I reserve the right to flip-flop back as new information is made available 🙂

Today, Openssl.org posted the following note about its recent breach:

Website defacement: provisional details.
==========================================

Last updated: 1st January 2014

On Sun 29th December 2013 at around 1am GMT the home page of www.openssl.org was defaced. We restored the home page just after 3am GMT and started forensics, investigation, and recovery.

Initial investigations show that the attack was made via hypervisor through the hosting provider and not via any vulnerability in the OS configuration. Steps have been taken to protect against this means of attack in future.

The source repositories have been checked and they were not affected. Other than the modification to the index.html page no changes to the website had been made.

More details to follow.

What bothers me, and the rest of the Internet-using security people, is the fact that they stated the attack vector was via the provider’s hypervisor. No details, no mention of the hosting provider, no mention of which hypervisor was being used, and no mention of the attack vector. That’s it. That’s all.

What about the provider’s other customers that may have also been breached but don’t yet know about it? Well, here is some info:

• openssl.org has address 194.97.152.144
• This IP address falls into the following range: 194.97.128.0/19 (verfied by using bgp.he.net and subnetmask.info)




• That IP is tied to German hosting provider SpaceNet AG (again, according to the results of bgp.he.net but also corroborated with the results from MaxMind



• SpaceNet AG is a VMWare vCloud partner (Note: in German)
• A quick search on the SpaceNet website shows that many of the technical job postings require VMWare and Hyper-V experience – but the desirable requirement is a VMWare certification (example 1 | example 2 | example 3)
• A quick scan (using Zmap) shows that port 902, the vCenter Server / VMware Infrastructure Client – UDP for ESX/ESXi Heartbeat (UDP and TCP), is open on a number of hosts
• The following banner is shown upon a port 902 telnet to one of the active hosts:

220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported, NFCSSL supported

So is this a hypervisor breach that allowed an attacker to deface a website? I’m willing to bet that this wasn’t the case. Why would an attacker waste such a valuable exploit (assuming it was a previously undisclosed 0day) just to deface a website?

If I were a betting man, and I am, I think this breach is more than likely associated with weak configuration settings. Whether the settings are fault of the provider or Openssl.org remains to be seen, however.

I hope this information helps others hosting with this provider…or at least makes them pick up the phone to call and get details on the scope of the breach.