Private AWS AMIs are temporarily being exposed publicly

The AMI community catalog is where people can publish Amazon Machine Images (AMIs) publicly. AMIs are used to create EC2 instances. While working with the AMI community catalog, using the `aws ec2 describe-images` command, I found multiple images that all have the same prefix that keep getting published to this public community catalog, but then shortly after discovery, they get removed from the catalog. The Description for all images is: `█████` In summary, I was able to manually create an EC2 instance in my own account using one of these AMIs during the short window it was public, and I believe that this AMI is supposed to be for internal AWS use only, and is never supposed to be public. I found multiple binaries on this AMI (chronicled & chroniclectl) that are not mentioned anywhere else on the internet and pull imports from ████████ (an internal golang package repo), and they contain references to internal AWS environments, like gamma/beta/dev. I did not find anything really critical here - no private internal AWS credentials or anything like that. Also noteworthy is that these AMIs are being made public by hundreds of unique AWS account IDs. My assumption is that there is a bug in some internal processes that is accidentally making these AMIs public during some type of job execution, but there is also some type of clean-up action that either makes the AMI private when the job is finished, or maybe the AMI is simply just deleted. ## Steps To Reproduce: (Add details for how we can reproduce the issue) 1. Search for the AMI either for one region like this: `aws --profile ███ ec2 describe-images --filters "Name=name,Values=ib-lifecycle-basic-ami*" --region us-west-2`, or in a loop like this: `for region in `aws ec2 describe-regions --query "Regions[].RegionName" --output text`; do; echo "$region"; aws ec2 describe-images --filters "Name=name,Values=ib-lifecycle-basic-ami*" --region $region; done` or in the console 2. Create an EC2 with the AMI ID 3. Connect to the EC2 4. Find AWS private binaries ████████ 5. Find references to internal resources such as █████, public pgp key from the ███ <█████████> team, etc. ## Impact An attacker can access an AMI that is intended to be used internally at AWS. The attacker can learn about the existence of AWS systems, private AWS binaries and their endpoints. An attacker could attempt to reverse engineer the binaries to see if they expose any additional information or lead to other vulnerabilities in the endpoints the binaries interact with. Additionally, an attacker can monitor these AMIs and create a list of unique AWS accounts that appear to be for internal AWS use (as opposed to customer accounts)