There has been quite a bit of discussion between myself, Tim Pierson, and others with respect to SSL man-in-the-middle attack possibilities within the virtual environment. But what are the chances that such an attack will happen, or that someone would know how to perform the attack? What does the attack depend upon?
First let me explain what an SSL MiTM attack does, and why it is an insidious five year old well understood attack. Did I say insidious? Yes, because the attack possibility is propagated by ‘experts’ all the time, when they do demos, and other such items. They causally click any ‘ignore’ button that pops up while telling people they should not do this, or not saying anything at all. But that is not the sole reason this attack exists today.
In effect the SSL MiTM attack is a certificate injection attack, where the attacker interprets the opening communication between a client and an SSL enabled server and injects their own certificate into the returning stream instead of the target servers actually certificate, which the MiTM software keeps for its use.
How probable is this type of attack within your environment?
That depends entirely on how the virtual environment is managed more than anything. Currently, SSL MiTM is used in the wild at internet cafe’s and other ‘public’ locations. In effect, for this to take place the attacker must either be on the network where your workstation is located or on the network where your servers are located which includes all management servers. This is the one reason why VMware and other security specialists recommend you have a tightly controlled management network with no parts of it outside your management network. In other words, the clients also live within this network and you use some secure mechanism to access them.
However, if your management environment for virtual environments are spread throughout your network, they are harder to control and could lead to this type of attack. Specifically, anything that allows direct access to your virtualization management tools and virtualization hosts from the Internet is immediately suspect and very much at risk. VMware Go’s approach to remote management tries to get around this by using a local proxy through which the remote management works. Even so, this is still a juicy target.
Is the risk worth the extra effort?
I think so. However, others may state, my bastions are safe, no one can get in and therefore no one can attack my systems with this type of attack. To me this is a false security footing, unless you have also done the necessary penetration testing to back this up. Penetration testers look at physical as well as cyber security measures. If it is trivially easy to plug a laptop into your network, then that may be all an attacker needs to beat your ‘bastions’. The idea behind defence-in-depth is to ensure that if one layer if broken, there are other layers to keep the bad guys at bay. The virtualization management network needs to be one of the innermost bastions.
The attacks could come from the wild, partners, fellow employees, etc. If you allow laptops from home on your networks, then they could be compromised at nearly any time. These are the types of systems that need to be protected. For several years the Verizon Breach Reports also mentioned items like unknown networks and unknown machines which are synonymous with sprawl.
These attacks are allowed due to ARP Cache poisoning and DNS redirection attacks. ARP Cache poisoning in effect convinces a system that their MAC address is the appropriate one for the intended IP, and a DNS redirection attack redirects to a compromised IP using a given name.
Incidently, such attacks also take less than 30 seconds to implement with the proper tools.
The Fallacy
The fallacy is that these issues are all brought about by the use of self-signed certificates. Basically, the theory is that using an untrusted, by the rest of the world or a well known, certificate source you are at risk. However, if you trust the source you still should not be at risk. Increasingly, attacks are against well known certificates either by using just revoked certificates, or by using attacks that currently work against these certificates. The famous NULL or \0 attack.
The other fallacy is that standard web based SSL used by browsers is sufficient. This is the least safe method of SSL to use. Instead, software must use all the SSL controls built into SSL software instead of using the defaults.
The answers?
There are several answers to this question, of whether SSL MiTM or other attacks are probably against your networks and systems. They are possible, but will they be probable? That depends on the value of your data to an attacker.
You can do any of the following to fix the current issues:
- Verify that you are not susceptible by performing Penetration Tests
- Limit exposure by limiting location of all virtual management products to a network with extremely tight controls on who and what can run within it
- Limit exposure by not providing juicy targets or targets of opportunity outside your normal bastions.
- Talk to the vendors about implementing better SSL Hygiene and SSL Certificate verification
- Train your employees to not trust just any SSL Certificate, have them query electronic fingerprints and verify the certificates visually.
- Require software that performs mutual authentication.
- Use software that only allows the use of pre-shared fingerprints or certificates.
- Audit everything, ensure you have a way to audit all accesses to a remote safe location.
The key here is that the real solution to this problem is for the software to not adopt the mechanisms used by a web browser but to insist on tighter security controls that are built into every SSL package but hardly used as most people do not understand that they NEED to be used, they assume the defaults contain everything necessary. This is actually one of the 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them.
There are many tools that can help here with auditing including Altor Networks, HyTrust, VMsafe, Catbird, and Reflex Systems, but not many currently help with the actual problem. For that we need better software and better implementations of SSL using pre-shared certificates as well as educated users who know who to verify certificate fingerprints and contents. In addition, no virtualization vendor is exempt from this type of attack all we can do is limit our exposure and risk!