Outside of entirely open-source resources, AMIs should never be shared publicly.
Amazon Machine Images (AMIs) can be thought of as complete hard disc clones of an underlying server’s root volume. They contain all files and data on the root volume including the operating system and any applications stored on the server at the time the snapshot was taken. This means that an AMI will also include logs, keys, files and any other data present on the file system.
Consequently, publicly shared AMIs also share all this data including potentially exposing sensitive files and data from the server. Sharing an AMI publicly should be considered as an intended use for open-source solutions as all data on the AMI effectively becomes public. Most commercial organisations do not fit this pattern so we detect publicly shared AMIs as a security concern as they’re more often an unintended leak than an intentional openly shared asset.
For Open Source solutions, managing sharing of individual code files is generally more controlled compared to sharing an AMI, which encompasses all data on the server at the time. Hence we would recommend cloning instructions, a system package or a containerised image rather than sharing an AMI.
SkySiege’s AWS Vulnerability Scan automatically detects publicly shared AMIs across all AWS Regions with the report delivered the same day. If you want to know if you have any leaked data get an assessment as soon as possible!
If an EC2 AMI has been shared publicly and is not meant for such use, the first step is to immediately revoke its public sharing permissions. Following that, it is crucial to investigate the data contained within the AMI to understand precisely what has been made publicly available to other AWS customers.
This investigation will require a thorough data analysis to identify what files were included in the AMI, such as logs, Personally Identifiable Information (PII), administrative data, passwords, certificates, private keys and other sensitive data. Depending on the results of this analysis, it may be determined that no sensitive data was shared, in which case no further action would be necessary.
However, if sensitive information is found, this situation could escalate into a significant data breach, depending on the nature of the data and the organisation’s obligations. For example, if private keys that could be used for mutual TLS (mTLS) or third-party server access are exposed, the implications may be serious, potentially leading to regulatory breaches that must be addressed accordingly. Additionally, leaking PII data in the form of database credentials, log files or on-volume databases such as SQLite can raise legal issues and processes that vary across jurisdictions.
The key takeaway is that any data from a publicly shared AMI should be regarded as compromised. Even if the AMI has been removed or shared just once, copies can still exist, making the data vulnerable and accessible in the wild. Measured and sensible recovery from this can be the difference between a business ending event and a minor challenge, therefore it’s best to get experienced guidance to determine the best course forward for your business:
SkySiege Cloud Security Assessments scan for this issue and provide same-day reports..
Available for individual projects or organisations.
