Regular listeners to BBC Radio 4 may be familiar with the “Evil Genius” series, in which Russell Kane, assisted by a panel of expert and celebrity guests, weighs iconic figures in the balance to establish whether they were truly evil or truly genius.

I would like to pick up that idea and run with it for a while, but apply it to something a little closer to home for your run-of-the-mill IT folk — the metadata available in an AWS EC2 instance. Before delving into the technical ins and outs of EC2 metadata, let us first look at what metadata is, in general terms. The prefix ‘meta-‘ is derived from the Greek word meaning ‘after’ or ‘beyond’, and came to prominence in terms such as ‘metamathematics’ and ‘metaphysics’ to denote a field of study of the underlying base subject.

Meta- has sprawled impressively into many parts of the English language to mean anything that is ‘about’ something else, giving us meta-rules (rules about the application of rules), metaprogramming (where programs feed on other programs), but not Metaxa, which is a half-decent Greek brandy. Metadata then, is data about data; the author and date of publication of a book, for example, with the contents of the book being the data itself, or is that themselves what with data being a plural? Hello, fellow nit-pickers.

Enough of these amuse-bouches, let us get our teeth into the main course — EC2 metadata, what is it, what can we use it for and most importantly, is it evil or genius?

What is it?

It’s data about your EC2 instances (of course, we guessed that from the long-winded explication above, right?), accessible inside each instance and provided by the instance metadata service (IMDS). You can access the metadata by “browsing” to http://169.254.169.254/latest/metadata/ from within your instance. This will return a list of categories that you can drill down into to reveal all sorts of interesting stuff about your instance that is not immediately available from within the operating system itself. With that in mind let us move on to look at…
What can we do with it?

Want to know the public IP address of your instance without looking it up on the console?
curl http://169.254.169.254/latest/metadata/public-ipv4 will tell you what you want to know.

What AMI did I use to launch this instance?
curl http://169.254.169.254/latest/metadata/ami-id is your friend.

Did I really launch my instance in Bahrain?!
curl http://169.254.169.254/latest/metadata/placement/availability-zone will set your mind at rest.

“That seems like a lot of information to have lying around”, I hear you say. “Is it secure?”. Well, the answer is yes and no, which might have been anticipated from the tone of this post.

Evil or Genius?

It might be assumed that a URL that is only accessible on a private, local address would be secure, however, if we imagine a scenario where the instance is running a service which is presented to the outside world, things become a little less clear-cut. Enter … Server-Side Request Forgery, or SSRF for short. SSRF is a means of forcing an application to make a call to a system or service that it was not designed to, usually with undesirable consequences. It is often exploited in connection with a web application carrying out import or export operations, such as sending a printable report in PDF or uploading an image. If the application does not carry out sufficient checks on the type and endpoint of such transfers, then they can be exploited to retrieve information that should not normally be visible.

In mid-2019, just such an exploit was carried out against Capital One, resulting in the leakage of personal details for 100 million existing customers and prospective cardholders. The attacker, who had a bona fide Capital One online account, noticed that the process to upload and preview a custom image for printing to your new credit card made use of an AWS S3 bucket, the URL of which was specified as a sub-component of the upload-image URL. By crafting a new “sub-URL” which pointed instead to the application instance’s metadata source, she was able to siphon off the instance’s IAM Role access keys and then use these to access and scan a large number of S3 buckets, downloading personal information on millions of people. This breach has been modelled by Kontra as an instructional exercise: Capital One SSRF | Kontra, allowing you to step into the shoes of the hacker responsible and gain a better understanding of how the vulnerability was discovered and exploited.

In and of itself then, Instance Metadata seems reasonably secure and is demonstrably useful. Add a sloppily-constructed application into the mix, one which does not check its inputs and outputs thoroughly, and suddenly metadata is sliding into a dark place.

Depending on how secure you want things to be, a number of options present themselves.

At the most extreme, the instance metadata service can be simply disabled.

If you still have a requirement for metadata, a newer, more secure flavour, cunningly called IMDSv2 is available. Using it allows you to block access to the older, less secure version and use a time-bound, token-based access method. Essentially you ‘unlock’ an instance metadata session for a fixed period of time (between one second and six hours), do what you need to do, and IMDS access stops working when the token expires. For details, see Configure the instance metadata service — Amazon Elastic Compute Cloud
Or stick with good old IMDSv1 and use an application with no security flaws. Simple.

About the Author

Alex Collier is currently a DevOps Cloud Engineer at Version 1.

About Version 1

Version 1 is a leader in Enterprise Cloud services and was one of the first AWS Consulting Partners in Europe. We are an AWS Premier Partner and specialise in migrating and running complex enterprise workloads in Public Cloud. Version 1 is a leader in Enterprise Cloud services and was one of the first AWS Consulting Partners in Europe. We have a policy of continuous investment in technology solutions that benefit our customers and are in the small number Amazon Web Services Partners to have achieved advanced partner status. Our team works closely with AWS to help our customers navigate the rapidly changing world of IT.