Is Your Amazon Machine Image Vulnerable to SSH Spoofing Attacks?

On the 23rd June, Amazon quietly rolled out a security fix for an issue originally discussed in the Amazon developer forums. Amazon documentation was revised to reflect the change as follows:

“Amazon EC2 public AMIs (Amazon Machine Image) generate unique SSH (Secure Shell) host keys each time you launch an instance. This enables you to get the host SSH keys from the console output and verify the host to which you are connecting.”

Important note: SSH host keys enable clients to verify the server identity (“are you really my server?”) and are separate from SSH user keys that allow the user to prove their identity to the server (“he really is Jeff”).

What does this mean?

It means that EC2 instances created from a public AMI after June 23rd have unique SSH host keys and thus are not vulnerable to a man-in-the-middle attack against the SSH protocol, but only if you manually verify the host SSH key during your initial SSH connection.

OK, but I created my AMI before June 23rd - am I vulnerable?

According to Amazon, yes. Every EC2 instance copied from a public AMI will have the same SSH host keys as the original AMI. The only exception to this is if the original AMI creator spotted this problem and used a hook to force SSH host key regeneration upon first boot. This means that an attacker who, say, uses a DNS cache poisoning attack, can intercept the communication between your SSH client and your AMI.

How can I fix my pre-June 23rd AMIs?

Regenerate the SSH host key. The exact commands will depend on your operating system (hint: ssh-keygen).

Who is to blame?

Either the creators of the original AMI or Amazon – depends how you look at it. If Amazon created the public AMI, then it could be argued they are responsible. However, anyone can submit a public AMI, and Amazon makes no guarantee they are fit for use (Amazon does review the AMI listing according to their documentation).

Amazon can in fact make the argument they are acting in the interests of their users by implementing a shared solution to key regeneration (rather than requiring each user to manually regenerate the SSH host keys after booting an image). That’s fine going forward, but what of potential exposure to customers using the pre-June 23rd public AMI copies?

Just to be clear, it’s not the fault of SSH – ‘secure channels’ require proper key management, and the need for unique host keys is well documented.

Are there any mitigating factors?

Yes, if you have used security groups to limit SSH access to your AMI from IP ranges you trust (rather than the entire Internet). You’ll still want to regenerate the SSH host keys sooner rather than later.

Is the Amazon environment vulnerable to man-in-the-middle attacks?

I don’t know. But that isn’t the real question – is the path between you and your AMI immune to MITM attacks? The answer is most definitely no. If SSH on your AMI is only accessible from another AMI, then it’s a fair question, but it’s unlikely Amazon is going to show you their network diagrams ;-). From experience performing MITM attacks, I would assume most networks are vulnerable (one of the reasons why we use SSH).

Why didn’t Amazon tell me I’m vulnerable? They know from their logs what AMIs I use!

Didn’t they? Whoops – naughty Amazon :P.

But seriously, Amazon is not responsible for the configuration of the public AMIs you use. It’s important not to confuse the AMI selection and cloning mechanism that Amazon provides, with the content of an AMI itself.

Does Amazon have a mailing list for customers to learn about new security problems (even if it’s not Amazon’s fault)?

Not that I know of. Right now, you have to search forum posts and monitor documentation updates – which is time-consuming and makes it easy to miss something. I also can’t find an area on the AWS website where they collect security-related items together (e.g., best practices, advisories, key management). In my view, this is a shame as it probably undermines the effort that Amazon is putting into their security (for some customers, if they don’t “see it,” it doesn’t “exist”).

A ‘Security’ link on the main AWS homepage pointing to those resources would go a long way to improving the visibility of the AWS security-related information.