homepage
Open menu
Go one level top
  • Train and Certify
    • Overview
    • Get Started in Cyber
    • Courses
    • GIAC Certifications
    • Training Roadmap
    • OnDemand
    • Live Training
    • Summits
    • Cyber Ranges
    • College Degrees & Certificates
    • Scholarship Academies
    • NICE Framework
    • Specials
  • Manage Your Team
    • Overview
    • Group Purchasing
    • Why Work with SANS
    • Build Your Team
    • Hire Cyber Talent
    • Team Development
    • Private Training
    • Security Awareness Training
    • Leadership Training
    • Industries
  • Resources
    • Overview
    • Internet Storm Center
    • White Papers
    • Webcasts
    • Tools
    • Newsletters
    • Blog
    • Podcasts
    • Posters & Cheat Sheets
    • Summit Presentations
    • Security Policy Project
  • Focus Areas
    • Cyber Defense
    • Cloud Security
    • Digital Forensics & Incident Response
    • Industrial Control Systems
    • Cyber Security Leadership
    • Offensive Operations
  • Get Involved
    • Overview
    • Join the Community
    • Work Study
    • Teach for SANS
    • CISO Network
    • Partnerships
    • Sponsorship Opportunities
  • About
    • About SANS
    • Our Founder
    • Instructors
    • Mission
    • Diversity
    • Awards
    • Contact
    • Frequently Asked Questions
    • Customer Reviews
    • Press
  • SANS Sites
    • GIAC Security Certifications
    • Internet Storm Center
    • SANS Technology Institute
    • Security Awareness Training
  • Search
  • Log In
  • Join
    • Account Dashboard
    • Log Out
  1. Home >
  2. Blog >
  3. Cloud Instance Metadata Services (IMDS)
370x370_Ryan-Nicholson.jpg
Ryan Nicholson

Cloud Instance Metadata Services (IMDS)

A misunderstood but deeply important feature to lock down when deploying workloads in cloud.

May 11, 2022

What is IMDS?

When cloud instances/virtual machines require access to data about itself or the cloud environment, it can query its Instance Metadata Service (IMDS) that typically listens on the IPv4 address of 169.254.169.254 as well as, in the case of Amazon Web Services (AWS) the IPv6 address of fd00:ec2::254. But what kind of information can be had? It depends on the vendor, but typically things like:

  • What region the instance/VM is running in
  • What subnet the instance/VM is a part of
  • What image was used to launch the system
  • What security groups are used to control network access to the system
  • Which public SSH key was injected into the authorized_keys file when spawned

The IMDS endpoints are in a tree-like structure that you can drill into to retrieve the data of interest. For example, if you were looking for the current AWS security group names tied to this instance, you can issue the following curl command in the Linux instance:

Picture1.png

You may think, “what’s the big deal?”, but there are some more sensitive items that can be retrieved as well, like:

  • User-data passed to the system at boot time (could contain secrets)
  • IAM role credentials (could allow access to the greater AWS cloud account)
  • Managed identity credentials (could allow access to the Azure account)
  • Service account tokens (allowing access to the GCP account)

We will focus on AWS specifically since it has a default deployment that is vulnerable (as you will see shortly). For example, this pair of curl commands can retrieve not only the name of the role attached to the EC2 instance, but also the current credentials that can be used by the instance (and attacker) to access parts of AWS:

Picture2.png

Now, when we say access to the above cloud accounts, that means that the attacker would be able to access the cloud environment with the exact permissions tied to the role, identity, or service account. This is where an attack abusing IMDS is more likely to focus.

How can attackers leverage it?

Theft

Up to this point, you may be assuming that, to get access to IMDS, you need to have a shell session on the cloud-based system, but that is certainly not the only way to access IMDS. Attacks like the Capital One breach in 20191 can leverage a flaw in the virtual system’s software to “trick” the application into querying IMDS instead of retrieving a legitimate resource. This is an example of a Server-Side Request Forgery.

Here is an example code snippet that would be susceptible to an SSRF attack which would allow an attacker to gain access to IMDS:

Picture3.png

This seemingly harmless code block (which will simply provide source code of the requested URL sent in as a url GET variable) will allow an attacker to retrieve IMDS data relatively easily. The attacker could craft a request to the URI of ?url=http%3A%2F%2F169.254.169.254%2Flatest%2Fmeta-data%2Fiam%2Fsecurity-credentials on this web application as shown here:

Picture4.png

This would be followed up by another request to ?url=http%3A%2F%2F169.254.169.254%2Flatest%2Fmeta-data%2Fiam%2Fsecurity-credentials/EC2S3FullAccess.

Picture5.png

Oh no! Exposed cloud credentials!

Pivot

Once the attacker has access to the cloud credentials, it’s trivial to pivot into the cloud account and access whatever the instance/VM would normally have access to. Assuming that the attacker has the AWS CLI tools installed on their local system, they could either create an entry in their .aws/credentials file or provide the credentials as environment variables (as shown below).

Picture6.png

After the credentials are set, the attacker can then execute AWS commands at will. Some may fail if the instance role does not have the appropriate permissions which may lead to some trial and error. But eventually, the attacker may stumble upon some requests that will work.

Picture7.png

Uh oh! An S3 bucket that looks enticing!

Picture8.png

And now the crown jewels are gone!

You really... REALLY should not go to that link (you’ve been warned)!

How Can Defenders Protect IMDS?

Latest Versions

Since the above attack’s initial access was due to some vulnerable PHP web code, an obvious place to start would be to fix the code. The web application developer would start by adding input sanitization to the web code (e.g., not allowing 169.254.169.254 to be entered) or adding defense-in-depth measures like a Web Application Firewall (WAF) to thwart these suspicious web requests before they reach the web server.

There is however, another approach we can take from a cloud configuration perspective. IMDS version 1 is in place and running by default in AWS to this day which allows for these simple GET requests to be used to retrieve information. However, we can change this by enforcing IMDS version 22 instead. IMDSv2 differs in a few ways:

IMDSv2 Change

Why this change matters

Requestor must first request a token from IMDS before making any subsequent requests

This changes the attacker’s requirements from two simple GET requests to acquire the role name and role credentials to now needing to first request a token

When requesting the token, the HTTP method is not a GET, but a PUT

Attacker must somehow change not only the URL being requested, but the HTTP method that is used—this is often times not possible when conducting a SSRF attack

PUT request must also include an additional HTTP header of X-aws-ec2-metadata-token-ttl-seconds: <seconds> where <seconds> signifies how long the returned token will be valid

Another requirement that the attacker likely does not have the power to influence when conducting a SSRF attack

A new HTTP header, X-aws-ec2-metadata-token: <TOKEN> must be included (where <TOKEN> is the value of the returned token from the previous request)

Once more, the attacker likely does not have the ability to add HTTP headers to their request during a SSRF attack

This is what an IMDS version 2 request would look like from the command line:

Picture10.png

And here is how to require IMDSv2 on an already deployed EC2 instance (of course, you should be deploying these from the start with only IMDSv2 enabled):

Picture11.png

No more SSRF accessing IMDS!

Picture12.png

Restricting which local users/groups can submit the request

Now that most SSRF attacks are taken care of, there is still the issue of an exploit which allows remote code execution. In other words, instead of just providing a URL to the web application, the web application is exploited by malicious code—allowing the attacker to execute code of their choosing (like they were on the command-line of that system) or gain shell access to the system and having direct command-line access.

In any case, the attacker can easily run the necessary curl commands to access IMDS—even with version 2 enabled. So... what else can be done?

There is one more trick up our sleeves to add as a defense-in-depth measure: host-based firewall tweaks. Since most Linux instances have iptables installed by default, we can apply a few rules restricting which user account can make an outbound request to 169.254.169.254. Let’s assume that the only user on the system that should have access to IMDS is the root user to pull the latest and greatest web code from an S3 bucket to this web server (hence the original intention of the instance role). The following iptables rules3 will prevent all other users from initiating an outbound request to the IMDS service:

Picture13.png

The first rule allows any process that is running as the root user to reach 169.254.169.254 and the second rule prevents all other requests to IMDS.

With those rules in place, let’s test them out. Here is a request from a non-root user:

Picture14.png

And one from the root user:

Picture15.png

If the web application user (which should not be root) is now executing attacker-controlled commands, they should be blocked from accessing IMDS until they are able to somehow either remove the iptables rule or escalate to root. Of course, if the compromised user account is the one that requires access to IMDS, this additional work does us no good here, but would prevent other users from accessing IMDS that have no business doing so.

Takeaway

As course author for SANS SEC488: Cloud Security Essentials and co-author (along with Shaun McCullough) of SEC541: Cloud Security Attacker Techniques, Monitoring, and Threat Detection, I’ve found that IMDS is a major blind spot for many organizations’ security teams. If you learned anything from this, hopefully it is to at least migrate all of your current and future AWS EC2 instances to IMDS version 2. Please see the below references for even more details on this service.

References

[1] Stella, J. (2019, August 1). A Technical Analysis of the Capital One Cloud Misconfiguration Breach. Fugue. https://www.fugue.co/blog/a-technical-analysis-of-the-capital-one-cloud-misconfiguration-breach

[2] Amazon Web Services. (2022). Use IMDSv2. Amazon Elastic Compute Cloud.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

[3] Nicholson, R. (2021, August 4). Neat little trick to block IMDS access from everyone except the root user. Unlike just moving to IMDS version 2. Twitter. 

https://twitter.com/ryananicholson/status/1422906718783254532

ABOUT THE AUTHOR

Ryan's passion for information technology started in 2001 when he found himself constantly trying to make his high school's computers and even calculators do things that they weren't exactly intended to do. They lacked games, so he learned how to create some. Yes, some may call this hacking. Ryan called it "fun", which led to attending college with intentions of becoming a software engineer. During school, Ryan obtained an internship with a very cybersecurity-minded organization -- the Defense Information Systems Agency (DISA). Ever since then, he’s been hooked on cybersecurity. Ryan is the author for SANS SEC488: Cloud Security Essentials, co-author of SEC541: Cloud Security Attacker Techniques, Monitoring, and Threat Detection, and an instructor for SEC530: Defensible Security Architecture and Engineering. Learn more about Ryan here.

Share:
TwitterLinkedInFacebook
Copy url Url was copied to clipboard
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kingdom of Saudi Arabia
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia (Slovak Republic)
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe

Tags:
  • Cloud Security

Related Content

Blog
CloudSecNext_Summit_Visual_Summary.png
Cloud Security, DevSecOps
May 3, 2022
A Visual Summary of SANS CloudSecNext Summit 2022
On May 3-4, thousands from around the globe tuned in for the SANS CloudSecNext Summit. We invited Ashton Rodenhiser to create graphic recordings of our Summit presentations. If you missed a talk or are looking to view the SANS CloudSecNext Summit through a visual lens, take a look at the recordings...
No Headshot Available
Alison Kim
read more
Blog
Untitled_design-43.png
Digital Forensics and Incident Response, Cybersecurity and IT Essentials, Industrial Control Systems Security, Purple Team, Open-Source Intelligence (OSINT), Penetration Testing and Ethical Hacking, Cyber Defense, Cloud Security, Security Management, Legal, and Audit
December 8, 2021
Good News: SANS Virtual Summits Will Remain FREE for the Community in 2022
They’re virtual. They’re global. They’re free.
Emily Blades
read more
Blog
Blog_teaser_images_(12).png
Digital Forensics and Incident Response, Cloud Security
April 9, 2021
NEW FOR509: Enterprise Cloud Forensics & Incident Response
The new Enterprise Cloud Forensics course brings examiners up to speed with the rapidly changing world of enterprise cloud
Viv_Ross_370x370.png
Viviana Ross
read more
  • Register to Learn
  • Courses
  • Certifications
  • Degree Programs
  • Cyber Ranges
  • Job Tools
  • Security Policy Project
  • Posters & Cheat Sheets
  • White Papers
  • Focus Areas
  • Cyber Defense
  • Cloud Security
  • Cyber Security Leadership
  • Digital Forensics
  • Industrial Control Systems
  • Offensive Operations
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kingdom of Saudi Arabia
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia (Slovak Republic)
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe
  • © 2022 SANS™ Institute
  • Privacy Policy
  • Contact
  • Careers
  • Twitter
  • Facebook
  • Youtube
  • LinkedIn