How to Embezzle Money Using Amazon AMIs

Do you restrict which Amazon Machine Images (AMIs) your users can deploy within your AWS accounts? Why does it matter?

What is an Amazon Machine Image?

An AMI contains all the information to deploy an instance within Amazon.

Amazon Web Services (AWS) allows vendors to provide their software preinstalled on AMIs. An organisation can then deploy these virtual machines then provide their own software licenses (BYOL) or pay an extra fee to Amazon to rent the software license.

Palo Alto AMI

How could an adversary use this for their own gain? How can this functionality be abused?

CloudFormation Templates

Amazon provides the ability to setup infrastructure quickly in the form of templates, these are called CloudFormation templates. They allow administrators to define the resources they need in an easy format. The internet has hundreds of thousands of CloudFormation templates. Templates that can be used to implement all kinds of applications. Templates to deploy data analytics tools, DevOps pipelines, ElasticSearch, Redis, whatever you need. Some of these templates deploy EC2 instances as part of their deployment, it makes sense. You have to run Wordpress somewhere.

Let’s look at this one to deploy Wordpress within AWS:

https://github.com/aws-samples/aws-refarch-wordpress

This CloudFormation template specifies the AMIs that will be used in this deployment.

AWS CloudFormation with AMIs Source

But what do CloudFormation templates and AMIs have to do with

Risk Scenario

If a malicious entity, let’s call him Lawrence was to:

If people then started using it, Lawrence would make $0.02/hour for each of the instances deployed by his CloudFormation templates. That is approximately $14 per month. This could go completely undetected on some bills and even if it was detected, the account owners would have no recourse to get a refund. They chose to use Lawrence’s template (and AMI). There is nothing illegal happening here.

I know you have security controls in place to avoid this, such as encouraging your team members to check templates and vet them for security issues, right?

Insider Threat

Let’s change the malicious entity, instead of Lawrence it is one of your team members. Let’s call him, Matt. Matt is disgruntled. Matt has management access to the company AWS account, as he is a cloud engineer and deploys new infrastructure from time to time. Say Matt performs the following:

This would deposit hundreds of dollars a month into Matt’s personal bank account, that could potentially appear as normal billing. Matt would be depositing around $3,600 into his bank account per month. Thankfully, this would be illegal and something would hopefully happen if Matt were caught.

Registering on the AWS Marketplace

What is the likelihood of someone being able to perform this attack?

They would need to register as an AWS Marketplace Seller. I initially thought this might be an easy task, but apparently it is harder than it sounds.

Requirements

To summarize, you would need to be:

Its not as easy as a quick overnight registration, but it is not impossible.

Solutions

What are some controls that can be utilised to treat this risk?

Ensuring you have a documented process for how you deploy AMIs and a list of approved AMIs is a valuable starting point.

AWS IAM Policies can then be configured to support your processes, ensuring only procurement or management can approve new subscriptions to software within the Amazon Marketplace. Also restricting access to deploy certain AMIs to certain team members:

Securing Access to the Marketplace

But what about your instances that are already deployed? How do you know that these can be trusted, having already been deployed before the IAM policies existed?

AWS Config can perform checks to ensure all instances deployed are utilising approved AMIs.

Approved AMIs by ID

If you have any further questions, feel free to contact me through LinkedIn.