Externally Exposed AMI

About Amazon Machine Image (AMI)

An Amazon Machine Image (AMI) is a template that includes all the information you need to spin up a new Elastic Compute Cloud (EC2) instance. An AMI can be used to launch multiple new instances, all with the same underlying configurations.

An AMI can be generic (e.g., a base Ubuntu AMI) or it can be more specific (e.g., an AMI that contains all the applications and dependencies required to run the Apache web server). There are pre-existing AMIs made available by other AWS users or you can create a custom AMI.

Customized AMIs enable you to pre-install any required packages on an instance, improve boot time (no need to provide user data at launch), implement security controls for all instances at once, and launch production-ready machines quickly when required.

AWS allows you to share your custom AMIs. You have the option of making them  public so anyone can use them or you can restrict access to specific AWS accounts.

Cloud Risk Description

A public AMI becomes a part of Community AMIs, which means that anyone with an AWS account can use it to launch an instance. Since AMIs usually contain application and data snapshots, this can potentially lead to sensitive data exposure. A malicious actor could use the sensitive data in an AMI to carry out a targeted cyberattack on your infrastructure.

How Does Orca Help?

Orca detects sensitive data at-risk across both the workload and control plane, pinpointing the exact location and providing masked samples of the data for quick remediation. In this specific case, Orca helps by looking for “externally exposed AMIs” and will alert on this type of issue as shown in the screenshot above.

• Detect sensitive cloud data at risk Find out more about Externally Exposed AMI.

Related Risks

• S3 bucket allows Public READ access

  This misconfiguration can allow anyone to list the objects within an S3 bucket.

• AMIs that contain known vulnerabilities

  An AMI may contain an older version of a software package that has a known vulnerability.

• Linux AMIs allowing SSH access

  Password authentication should be disabled by default.

Recommended Mitigation Strategies

• Privacy

  As a general rule, never make an AMI public.

• Restrict access

  Restrict access to AMIs to only those AWS accounts that need it.

• Use scanning tools

  Use the self-service AMI scanning tool from AWS to detect any vulnerabilities, malware, or viruses in AMIs.

• Use supported systems and packages

  Only use currently supported operating systems and software packages while creating AMIs.

• Keep it clean

  Disable or remove all the unnecessary packages/dependencies from your AMI.

• Don’t store on an AMI

  Don’t store any secrets, passwords, keys, etc. on an AMI.

Useful Links

• Orca Security 2020 State of Virtual Appliances Security Report: https://orca.security/resources/blog/virtual-appliance-security-report/
• AMIs: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#buy-share-sell
• Creating custom Windows AMIs: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html
• AMI scanning tool: https://aws.amazon.com/marketplace/management/manage-products
• AMI security policies: https://docs.aws.amazon.com/marketplace/latest/userguide/product-and-ami-policies.html
• Best practices for building AMIs: https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html
• AMI-based products: https://docs.aws.amazon.com/marketplace/latest/userguide/ami-products.html
• IAM policies for EC2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html