The session was fun, well attended, and received good ratings. However, our time management left something to be desired and we ran out of time before we could take audience questions. As promised, we'll answer them here.
Q: How in a VM deployment model, do you manage binding the "right" VM image to a "known" hypervisor? In other words, how do you lock a VM image to a specific H/W server via the hypervisor so a VM image cannot be abducted and re-used outside an enterprise or hosting provider?A: Interesting question. We see two options here.
- You could 'sign' the VM, and configure the hypervisor to only boot a VM after first validating the signature. This helps you keep unauthorized VM's from running in your infrastructure, but would do little to stop an attacker with access to your VM from booting it on a hypervisor they control.
- You could encrypt your VM to a public key presented by a hypervisor, cluster, etc. At boot time the hypervisor would use the private key to decrypt the VM just before boot. Either of these scenarios introduce key management issues. Also, at this time we are not aware of any commercial or open source solutions which incorporates any of these strategies out of the box.
After demonstrating the SSL MITM attack on the vCenter admin, we received this question:
Q: It appears that multi-factor authentication would help with these issues. Can we implement multi-factor authentication to resolve using default certificates? Can we use "user-level" authentication to prevent these issues... going beyond PKI certs for the host but actually authenticating to the VMware Vcenter?A: In short, no. See http://www.schneier.com/essay-083.html for info about how multi factor authentication systems are still vulnerable to man in the middle attacks. For example: a Windows enterprise using smartcard based two factor authentication for domain logon, and using Windows auth for vCenter login would *still* be vulnerable to man in the middle attacks for as long as the vSphere client continues to negotiate TLS (SSL) with an untrusted third party. Multi factor authentication is great, but in this case replacing the self signed certificates presented by vCenter by default is the proper mitigation to SSL MITM threats.
After demonstrating the browser exploit leading to an attacker compromising an EC2 admin's EC2 ApiTools keypair, we received the following question:
Q: If the manager accesses EC2 management using multi-factor authentication, is it not the case that this attack is mitigated?A: In our demonstration the attacker used a browser exploit to run arbitrary code on the victim's workstation. This code allowed the attacker to download credentials from the victim (an X.509 certificate and private key in .PEM format) which were used to nefariously administer the victim's EC2 infrastructure in the cloud using the EC2 API Tools.
Amazon recently began offering a multi factor authentication system based on a Gemalto Ezio token which is used to provide two factor auth for login to the EC2 management console (web interface). We doubt that this new 2FA service extends to the EC2 API Tools, which is what we exploited in the demo. However, this piqued our interest, and we will find out! UPDATE: Our hunch was correct. AWS MFA provides two factor auth ONLY for the web management console, not the API Tools.
Another method for protecting the private key used with the EC2 API Tools is to encrypt the private key, using a command such as "openssl rsa -des -in pk.pem -out pk_encr.pem". It appears that the EC2 API Tools do *not* presently support encrypted private keys though, as instead of prompting for the passphrase when the key was needed, the API Tools bombed out.
