There has been a lot of coverage over the past week about Anonymous’ Hardcore Charlie releasing some old 2003/2004 code of the VMware ESX Hypervisor on the Internet. The release of the code may not cause anyone any immediate increased risk of attack. If you want to know why keep reading.

The reason I say that it will not likely cause any immediate risk of attack is because even if the code did contain some sort of vulnerability, the chances that your environment would be exposed is very low, provided some basic best practices have been followed. The hackers would have to first understand the code, and then find a weakness that could be exploited. You would have had to not been applying security patches and updates for an extremely long time, be on a completely unsupported version of the ESX Hypervisor, and the hackers would have to first infiltrate your environment. Chances are the security vulnerabilities that did exist in the code are mostly already known, and have already been patched. Just hope or check you’ve implemented the patches or have long since upgraded to a newer version.

One of my good friends Rogan Mallon (CISSP) has a good analogy that I think is appropriate to this discussion. Humans are vulnerable to bullets, you just need to take adequate precautions like Kevlar vests and not hanging out in the wrong part of town (like avoiding the middle of Kabul at night for example). This way you’re unlikely to get shot. The code fits into that category.

Infiltrating an environment is easier said than done, especially if you have a secure design, hardened your configuration, and implemented proper security controls. This could be as simple as having a separate management network for access to vCenter and your VMware hosts, with access limited to only trusted admins, having them log in as themselves, and having all actions go via vCenter. You should always follow the concept of least privilege and separation of duties. You should have the management network protected by firewall and it is a good idea to have a jump box, such as a terminal server or VMware View Desktops, VPN, or other secure mechanism to access it. The mere fact that your entire management infrastructure and access to the hypervisor is secured on a separate part of your internal network and limited to only trusted individuals reduces the chances of attack from any vulnerability that exists now or in the future. Just remember, vulnerabilities in things are found all the time, even in secure software, and you need to be prepared.

The easiest way to attack an environment is from the inside, either through an existing vulnerability, via social engineering, or a disgruntled admin. Attack from all of these things are possibilities at all times. This is why VMware goes to a lot of effort to produce the Security Hardening Guides and putting their software through Common Criteria Certification and other Security Tests, and recommends customers implement common sense security best practices. The impact of attack regardless of the probability could be unacceptably high. So implementing a secure infrastructure management design and following good security practices is of paramount importance.

This leads me to the title of this article. An unbroken chain of trust is of paramount importance when you are building your infrastructure. When you are building your environment, the foundation of your business, it is critical that you ensure the software you are implementing is genuine and hasn’t been tampered with. One of the avenues of attack I didn’t mention in the previous paragraph is through a Trojan or back door implemented in what looks like legitimate code. Fooling people into running Trojans is like a sport for hackers, and if security statistics are anything to go by there are plenty of people who are willing to run their malicious code. If you don’t obtain the version of VMware software from the VMware Website (or any other vendor software from the vendor website), and you don’t compare the md5 or sha hash against the software you obtain, you are putting your organization at unnecessary risk. Having an unbroken chain or trust is of paramount importance to ensure you are installing the genuine article and not a counterfeit or impersonator.

Just in case you hadn’t heard about the code leak here is some of the coverage from the past week.

Anonymous’ Hardcore Charlie disputes downplaying of VMware code
Anonymous’ Hardcore Charlie on the VMware leak and why he did it
Anonymous Hacker Claims Credit For VMware ESX Code Leak
VMware Confirms ESX Server Hypervisor Source Code Leak
VMware Security Note RE Source Code Leak

Final Word

Always remember the three Maxims of Cloud Computing: Hardware Fails, People Make Mistakes, Software has Bugs / Security Vulnerabilities.

Always take measures to protect your environment, it doesn’t have to be difficult or necessarily costly. Take a risk based approach depending on your organization risk profile. Seek advice from independent security professionals. Make sure you design your environment with basic common sense security best practices from day one. If you need help with your design or to review your design and your environment there are plenty of companies you can contact, including my company (via the author page).

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.