Goal

In the fourth installment of our BlackHat video series, we turned our attention to Amazon’s cloud platform and focused on their Elastic Compute Cloud (EC2) service specifically.

Theft of resources is the red-headed step-child of attack classes and doesn’t get much attention, but on cloud platforms where resources are shared amongst many users these attacks can have a very real impact. With this in mind, we wanted to show how EC2 was vulnerable to a number of resource theft attacks and the videos below demonstrate three separate attacks against EC2 that permit an attacker to boot up massive numbers of machines, steal computing time/bandwidth from other users and steal paid-for AMIs.

Background

EC2 enables users to boot and run virtual machines that are custom-configured by the user but execute within Amazon’s cloud. Each virtual machine or Amazon Machine Instance (AMI) has its own IP, non-persistent storage, CPU and network connection. The service is full-featured and we won’t go into all details here, more info is available from the EC2 site. With that said we’ll point out three key facts that shaped our testing:

1. The service is controlled via a web interface so sign-up obviously occurs in a browser. Sign-up requires minimul information, essentially just an email and credit card info.
2. When booting an AMI, users can either create their own image from scratch or they can choose from a list of pre-built AMIs which are overwhelmingly supplied by other EC2 users.
3. Amazon provide a facility called DevPay by which users can create AMIs for leasing to other users; when a non-free AMI is run then the user running the instance is charged a fixed rate and the proceeds are split between the creator of the instance and Amazon.

Video 1: AMIBomb

For this video we wanted to consider a DoS on the EC2 from within, by running as many AMIs concurrently as possible.

Since sign-up for the sevice occurred in a browser, it was possible to script this process (using Twill for the most part). The first attack would be to boot hundreds or thousands of instances under one Amazon account, however an upper bound of 20 running machines per account is enforced by Amazon. Our approach was one step removed from this; we created multiple accounts and then ran the 20 machines. Each new account would also create multiple accounts and then run 20 machines. One iteration of the create-accounts-and-boot-AMIs cycle took three minutes; by the ninth iteration the projected number of running instances is ridiculous. It’s apparent that this recursive registering of accounts and booting machines means that the number of running machines grows exponentially and this could continue until the system can’t handle the machine load.

Our approach was effective because the registration process took no steps to prevent automated sign-up. In testing a single credit card was used to create our accounts which is an immediate anomaly however a malicious attacker would use stolen CC data to ensure that CC checks did not prevent new account registration.

Video 2: AMI Registration Race

As has been mentioned, users can choose AMIs from a list of machines that is mostly user-generated (out of 2700 odd machines, 47 were built by Amazon and the remainder by other users.) It is easy to add a machine to this list; simply create a new AMI and in its properties mark it as ‘public’.

Our idea was to create a malicious AMI and add it to the public listing, with the goal being to show that users will run AMIs without any consideration for who built it or whether nasties were included. We quickly created an AMI, uploaded it and… nothing. No one ran the image and it seemed that people weren’t so easily fooled.

Digging a little deeper, however, revealed that when our image was created, it was dumped on the second last page of the AMI listings and so users would have to surf through more than 50 pages of images before coming across our AMI. If Google has taught us anything, it’s that ranking counts and so we needed to boost our machine up the AMI listing.

It turns out that the AMI listing is ordered by the AMI ID, which is a random id string that is generated when the AMI is created. Our process was then slightly modified as follows: we scripted the AMI registration process so that it was trivial to register an image. We then looped the registration script to create and register an AMI, and tested to see whether the randomly assigned AMI ID was low enough such that our AMI was listed on the first page.

Our first attempt took about 4000 iterations and landed us a top 5 spot in under 12 hours. A subsequent attempt took less than 4 hours to land a top 5 spot.

This was great, but our image was unattractively named ‘qscanImage’ runing on the ‘Other Linux’ platform, which didn’t say much about it.

It turned out that we had a great degree of freedom in naming images. Images were stored in Amazon S3 buckets and the buckets had globally unique names. We tried buckets with names such as ‘fedora’, ‘fedora_core’ and ‘redhat’, but all these were taken, however with a small degree of evilness the bucket ‘fedora_core_11’ was available and so registered. The registration race was repeated with the better named machine, and after a little while we landed the AMI on the front page as shown in the screnshot below:

What’s funny is that the machine was the highest listed ‘Fedora’ AMI, so a user who was specifically looking for a Fedora image would come across our evil image first.

In reality our image did not have anything malicious except a call-home line in ‘/etc/rc.local’ that would ‘wget’ a file on our webserver, to show the image had been booted. The screenshot below shows the logline from our webserver which proved the image had been booted; this occurred in a little under four hours after the instance had been made public.

Video 3: AMI Stealing

Our final Amazon video shows how it is possible to remove ancestry information from AMIs. When a paid-for machine is created, Amazon stores information about the owner of the machine in its manifest (which is an XML document) in order to pay the creator of the image. Our attack works as follows:

1. Purchase a paid-for image
2. Use Amazon’s tools to create a bundle from the running AMI
3. Download the manifest for the bundle
4. Modify the manifest by removing the associated product code and owner information
5. Resign the manifest using Amazon’s tools
6. Upload the manifest
7. Register a new AMI using the bundle that was copied from the paid-for AMI, along with the edited manifest
8. Stop using the original paid-for AMI

Using this attack, it is possible to pay once for an AMI, create a copy and never pay the creator again.

Conclusion

In this set of three videos, we showed attacks against the Amazon EC2 platform that do not target specific weaknesses in technologies; rather the processes by which complex actions took place were abused to our benefit. In doing so, we managed to sketch a scenario by which a local DoS might be effected against EC2, successfully showed how easy it was to have users run untrusted AMIs and lastly described a method by which non-free AMIs may be stripped of owner information, thereby foregoing income to the AMI creator and allowing the attacker to continue using the paid-for AMI without cost.