If you work in any virtual or cloud environments, how many times have you heard that statement as soon as any kind of problem surfaces? Way back when during the twentieth century, as a problem deflection, the network would immediately be blamed. As we got into the twenty-first century, virtualization quickly became the go-to area for any and all problems. As part of the virtualization and cloud computing teams, we would have to prove that a problem was not caused by virtualization before any other teams would really dig in and troubleshoot the issue. Even after the fourteen years since the turn of the century and the mainstream acceptance of virtualization technology as a whole, I still see that kind of blame mentality today. And just when I thought I’d heard it all when it comes to virtualization blame, a news story comes out that takes this immediate blame game to a whole new level.
It has been reported that on December 29, 2013, the official website for the OpenSSL code library was compromised in an incident that caused great concern among security professionals. Although the actual code repositories were untouched, the breach left defacement on the OpenSSL home page. Upon discovering the defacement, OpenSSL immediately restored the index.html file from backup and then started the forensics, investigation, and recovery process. So far, so good, right? Well, by New Year’s Day, OpenSSL had issued an advisory stating that “the attack was made via hypervisor through the hosting provider and not via any vulnerability in the OS configuration.” This advisory, which lacked any real details, immediately raised the question of whether the attack could be exploited to target other sites that utilize the same service. Without finishing the forensic investigation, OpenSSL had jumped the gun and deflected blame to the hypervisor. Once the advisory placed the blame on the hypervisor, it did not take long before people started to realize that the hypervisor under suspicion appears to have been VMware’s ESXi server.
As a result of the advisory, the VMware Security Response Center started to actively investigate the incident in order to understand if and how any VMware products were involved and whether VMware needed to take any action to ensure customer safety.
