Amazon AWS – The risk of using a cooked AMI

Straight from the horses mouth; I no longer use this AMI – but the only ones I’ve used are Debian EBS and SLES … Fortunately I already went through authorized_keys on the one I do keep around.

People take AWS services seriously – but the AMI sharing always set off a flag for me. “Community AMI?” – No thanks! (Unfortunately the only choice for people who don’t want to – or do not have the time to make their own AMI they can trust).


Dear AWS Customer,

We are aware that a public Amazon Machine Image (AMI) in the Amazon EC2 US East (Virginia) region includes a public SSH key that could allow the AMI publisher to log in as root. Our records indicate that you have launched instances of this AMI.

AWS Account ID:  [REMOVED]

AMI(s)
==========
ami-0c638165

Instance ID(s)
==========
i-[REMOVED]

We are taking steps to remove the affected AMI within the next 24 hours. This will prevent launching new instances of the affected AMI, though existing instances of this AMI will continue to function normally.  For existing instances you may have of this AMI, we recommend that you migrate services to new instances based on a different AMI.

While you are migrating your services to a new instance, we also recommend that you identify and disable unauthorized public SSH keys. To do so, you will need to remove any unrecognized keys from your running instance(s). Note that public SSH keys are not guaranteed to be in the ‘/root/.ssh/authorized_keys’ file. The following command will locate all of the “authorized_keys” files on disk, when run as root:
       find / -name “authorized_keys” -print -exec cat {} \;

This command will generate a list of all known “authorized_keys” files, which you can then individually edit to remove any unrecognized keys from each of the identified files. To ensure that you do not inadvertently remove your authorized keys, we recommend that you initiate two SSH sessions when starting this process for each instance. You should keep the second session open until you have confirmed that all unrecognized / unauthorized keys are removed and that you still have SSH login access to the instance using your authorized key.

If you do not use SSH to connect to your Amazon EC2 instances, we recommend that you check the security groups associated with the above instance(s) to ensure that port 22 inbound is closed to all unknown IPs. This can be done via the AWS Management Console. For detailed instructions, please check the “Using Security Groups” section of the Amazon EC2 User guide:

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-network-security.html

We hope this information is helpful.

Best regards,

Amazon Web Services Support

This message was produced and distributed by Amazon Web Services LLC, 410 Terry Avenue North, Seattle, Washington 98109-5210

3 thoughts on “Amazon AWS – The risk of using a cooked AMI

  1. I am also running a copy of this image. Amazon's message is woefully short on details. Is the image known to be hostile? I'm going to change it but how concerned do I need to be?

  2. Well that's the thing – technically you don't really know – since everything from /etc/motd to the ssh key are things that aren't “default” in that AMI. How concerned is a question of how much you value what's on your instance.

    The quickest thing you could do is set PermitRootLogin to “no” in /etc/sshd_config – setup sudo, and strip existing keys and regernerate new ones; check your apt sources. Unfortunately any pre-existing binaries are suspect;

    Longer term:
    – Setup strict iptables rules depending on your services exposed.
    – Remote syslog everything

    I'm still collecting my thoughts on other details – need time to investigate.

Leave a Reply

Your email address will not be published. Required fields are marked *