Via InfoWorld comes a report regarding a hack against the openssl.org website. The report identifies a couple of interesting features of the attack.
The headline of the report is:
No hypervisor vulnerability exploited in OpenSSL site breach
This is a good thing. For the non-nerd, the hypervisor is the foundation of modern cloud computing. Instead of your “cloud computer” running directly on hardware, the hypervisor sits in between, allowing the single server on which the cloud is running to look like multiple servers, one for each of the computers that are hosted in the cloud. Were the hypervisor to be compromised, this would allow an attacker to compromise any virtual machine in the cloud, and then “break the hypervisor” to gain control of all of the other machines in the cloud.
From an enterprise perspective, when you outsource a server to a commercial cloud provider, you have no control over what other virtual machines run on the same hypervisor as your machine. If it is possible to break the hypervisor, then your server is only as secure as the weakest server hosted on the hypervisor.
In the openssl.org hack, it seems that the attack was not due to a hypervisor break, but rather “a result of the hosting provider using insecure passwords”. But think about this: having a password is one thing; having access to an interface where it is useful is another. From OpenSSL’s press release about the incident, “Our investigation found that the attack was made through insecure passwords at the hosting provider, leading to control of the hypervisor management console” (emphasis mine). Forget the weak password; why was there external access to the hypervisor management console? Turns out the weak password is the least of their failings.
So what are the lessons learned?
1. Insist on a third-party security audit of your cloud provider: Cloud hosting is a cut-throat business, and by far the most important factor in the outsourcing decision is cost. In this environment, hosting companies are not incentivized to provide any “security extras”. Moreover, even if you ask about security measures…hmm, how to put this delicately…you cannot assume the answer will be truthful. A third-party audit of the provider is your best hope of getting assurance of the provider’s security posture.
2. Don’t have your management interfaces accessible from the Internet: Whenever you have an open management interface, you leave yourself open to a “low and slow” password brute forcing attack. And if they figure out you’re not paying attention, it may stop being low and slow. Of course you could regularly change passwords, but good luck with that. Put the interface behind a firewall if feasible, and if you need external access, allow it through a VPN. If that’s impractical, try to whitelist the network range where you expect access to come from. If nothing else, at least blacklist network ranges from areas with a history of hacking activity.
3. You are a target: Why go after openssl.org? They give away their (very useful) product for free, and according to OpenSSL’s report the only damage was to have their home page defaced. This strongly suggests the hacker’s MO was approximately this:
a.) Find open hypervisor management interfaces. If they were diligent, maybe they scanned. If they were lazy, they probably used Shodan.
b.) Start brute forcing passwords, probably in parallel across multiple targets.
c.) Get lucky.
d.) Get on compromised system, and either identify most prominent client, or just whack ’em all.
There’s no reason at all to think OpenSSL.org was targeted. Most likely they were just the highest-profile server that could be compromised. The hackers did this because they could, and if hacking your server is possible, they’ll do it because they can.