{ "id": "fbb5aa80-9c14-4b60-a34b-4cdd8e048616", "created_at": "2026-04-06T03:35:35.114043Z", "updated_at": "2026-04-10T13:12:33.963773Z", "deleted_at": null, "sha1_hash": "12054d235b771dda70e3935596e674ad486678ed", "title": "Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service | Amazon Web Services", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 59366, "plain_text": "Add defense in depth against open firewalls, reverse proxies, and\r\nSSRF vulnerabilities with enhancements to the EC2 Instance\r\nMetadata Service | Amazon Web Services\r\nPublished: 2019-11-19 · Archived: 2026-04-06 03:14:38 UTC\r\nJuly 27, 2021: We’ve updated the link to the 2019 re:Invent session on this topic.\r\nSince it first launched over 10 years ago, the Amazon EC2 Instance Metadata Service (IMDS) has helped\r\ncustomers build secure and scalable applications. The IMDS solved a big security headache for cloud users by\r\nproviding access to temporary, frequently rotated credentials, removing the need to hardcode or distribute\r\nsensitive credentials to instances manually or programatically. Attached locally to every EC2 instance, the IMDS\r\nruns on a special “link local” IP address of 169.254.169.254 that means only software running on the instance can\r\naccess it. For applications with access to IMDS, it makes available metadata about the instance, its network, and\r\nits storage. The IMDS also makes the AWS credentials available for any IAM role that is attached to the instance.\r\nWhen you run applications in the cloud, application security is as critical as instance security; if the applications\r\nrunning on an instance have vulnerabilities or misconfigurations, there can be serious consequences. While\r\napplication security plays an important role in a layered defense, AWS also constantly evaluates where to add\r\nlayers, even within the instance, to minimize the damage that can occur when these situations occur.\r\nToday, AWS is making v2 of the EC2 Instance Metadata Service (IMDSv2) available. The existing instance\r\nmetadata service (IMDSv1) is fully secure, and AWS will continue to support it. But IMDSv2 adds new “belt and\r\nsuspenders” protections for four types of vulnerabilities that could be used to try to access the IMDS. These new\r\nprotections go well beyond other types of mitigations, while working seamlessly with existing mitigations such as\r\nrestricting IAM roles and using local firewall rules to restrict access to the IMDS. AWS is also making new\r\nversions of the AWS SDKs and CLIs available that support IMDSv2.\r\nWhat’s new in IMDSv2\r\nWith IMDSv2, every request is now protected by session authentication. A session begins and ends a series of\r\nrequests that software running on an EC2 instance uses to access the locally-stored EC2 instance metadata and\r\ncredentials. The software starts a session with a simple HTTP PUT request to IMDSv2. IMDSv2 returns a secret\r\ntoken to the software running on the EC2 instance, which will use the token as a password to make requests to\r\nIMDSv2 for metadata and credentials. Unlike traditional passwords, you don’t need to worry about getting the\r\ntoken to the software, because the software gets it for itself with the PUT request. The token is never stored by\r\nIMDSv2 and can never be retrieved by subsequent calls, so a session and its token are effectively destroyed when\r\nthe process using the token terminates. There’s no limit on the number of requests within a single session, and\r\nthere’s no limit on the number of IMDSv2 sessions. Sessions can last up to six hours and, for added security, a\r\nsession token can only be used directly from the EC2 instance where that session began.\r\nhttps://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/\r\nPage 1 of 4\n\nFor example, this curl recipe retrieves a session token that’s valid for the full six hours (21600 seconds) and then\r\nuses that token to access the EC2 instance’s profile metadata:\r\nTOKEN=`curl -X PUT \"http://169.254.169.254/latest/api/token\" -H \"X-aws-ec2-metadata-token-ttl-seconds: 21600\"`\r\ncurl http://169.254.169.254/latest/meta-data/profile -H \"X-aws-ec2-metadata-token: $TOKEN\"\r\nPlain text\r\nIf you need to write code against the IMDSv2 directly, you can get more detail on the new scheme in the EC2\r\nUser Guide.\r\nHow these changes add defense in depth\r\nIMDSv2’s changes are easy to use, and you’ll start using it automatically if you’re using the updated AWS SDKs\r\nand CLIs. These changes go beyond other types of mitigations to protect against misconfigured-open website\r\napplication firewalls, misconfigured-open reverse proxies, unpatched SSRF vulnerabilities, and misconfigured-open layer-3 firewalls and network address translation.\r\nProtecting against open Website Application Firewalls\r\nSome Web Application Firewall (WAF) services, such as AWS WAF, can’t be configured to act as open WAFs.\r\nHowever, some third-party WAFs can be misconfigured to allow attackers unauthorized access to the network\r\nbehind the WAF, including the EC2 IMDS.\r\nMany WAFs are designed to act invisibly, so that they can protect websites and applications without\r\nadministrators having to change or reconfigure the applications that are behind the WAF. To be transparent, WAFs\r\nusually pass on all of the headers that come with a request, and do not add their own headers, such as the standard\r\nX-Forwarded-For header that other kinds of proxies add. In other words, applications behind a WAF get requests\r\njust as the requester sent them.\r\nThe AWS approach is to block open WAFs by using a type of request that open WAFs very rarely support, HTTP\r\nPUT requests. Although web services such as Amazon S3 use PUT requests for object storage, they’re an\r\nuncommon type of request for websites and browsers to use. Our analysis of third-party WAF products and open\r\nWAF misconfigurations found that the vast majority do not permit HTTP PUT requests. We’re using this PUT\r\nrequest to provide a new layer of defense that goes beyond any existing capabilities – we’ve architected the\r\nIMDSv2 service to require a PUT request at the beginning of a session, which will prevent open WAFs from being\r\nabused to access the IMDS in the vast majority of cases.\r\nProtecting against open reverse proxies\r\nAs it happens, it’s also very rare for open reverse proxies to allow PUT requests, but IMDSv2 has another layer of\r\ndefense against open reverse proxies. Reverse proxies, such as Apache httpd or Squid, can also be misconfigured\r\nhttps://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/\r\nPage 2 of 4\n\nto allow external requests that reach internal resources, but it’s still normal for these proxies to send an X-Forwarded-For HTTP header. That header itself is used to pass on the IP address of the original caller. IMDSv2\r\nwill also not issue session tokens to any caller with an X-Forwarded-For header, which is effective at blocking\r\nunauthorized access due to misconfigurations like an open reverse proxy.\r\nProtecting against SSRF vulnerabilities\r\nSSRF vulnerabilities allow attackers to make unauthorized requests from web applications. Since these requests\r\ncome from the application itself, they can be used to access internal resources that the application has access to but\r\nthat were not intended to be accessible to outsiders. SSRF vulnerabilities vary in their severity, and some are\r\nimmune to other types of mitigations. For instance, blocking SSRFs through static headers in instance metadata\r\nrequests is effective only when the vulnerability merely allows the attacker to control the URL that is being\r\nrequested; however, AWS analysis found many SSRF vulnerabilities that allow attackers to set arbitrary headers\r\nbecause the SSRF vulnerability impacts the application’s own header processing.\r\nIMDSv2’s combination of beginning a session with a PUT request, and then requiring the secret session token in\r\nother requests, is always strictly more effective than requiring only a static header. AWS analysis of real-world\r\nvulnerabilities found that this combination protects against the vast majority of SSRF vulnerabilities.\r\nProtecting against open layer 3 firewalls and NATs\r\nLast, there is a final layer of defense in IMDSv2 that is designed to protect EC2 instances that have been\r\nmisconfigured as open routers, layer 3 firewalls, VPNs, tunnels, or NAT devices. With IMDSv2, the PUT response\r\ncontaining the secret token will, by default, not be able to travel outside the instance. This is accomplished by\r\nhaving the default Time To Live (TTL) on the low-level IP packets containing the secret token set to “1,” much\r\nlower than a typical value, such as “64.” Hardware and software that handle packets, including EC2 instances,\r\nsubtract 1 from each packet’s TTL field whenever they pass it on. If the TTL gets to 0, the packet is discarded, and\r\nan error message is sent back to the sender. A packet with a TTL of “64” can therefore make sixty-four “hops” in a\r\nnetwork before giving up, while a packet with a TTL of “1” can exist in just one. This feature allows legitimate\r\ntraffic to get to an intended destination, but is designed to stop packets from endlessly running around in circles if\r\nthere’s a loop in a network.\r\nWith IMDSv2, setting the TTL value to “1” means that requests from the EC2 instance itself will work because\r\nthey’re returned to the caller (on the instance) before the subtraction occurs. But if the EC2 instance has been\r\nmisconfigured as an open router, layer 3 firewall, VPN, tunnel, or NAT device, the response containing the token\r\nwill have its TTL reduced to zero before leaving the instance, and the packet containing the response will be\r\ndiscarded on its way out of the instance, preventing transport to the attacker. The information simply won’t make\r\nit further than the EC2 instance itself, which means that an attacker won’t get the response back with the token,\r\nand with it the ability to access instance metadata, even if they’ve been successful at getting past all other\r\ndefenses.\r\nMaking the transition\r\nhttps://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/\r\nPage 3 of 4\n\nBoth IMDSv1 and IMDSv2 will be available and enabled by default, and customers can choose which they will\r\nuse. The IMDS can now be restricted to v2 only, or IMDS (v1 and v2) can also be disabled entirely. AWS\r\nrecommends adopting v2 and restricting access to v2 only for added security. IMDSv1 remains available for\r\ncustomers who have tools and scripts using v1, and who are comfortable with the existing security posture of their\r\ninstances.\r\nA number of tools are available to make transitioning to v2 and disabling v1 seamless. Starting today, a new\r\nCloudWatch metric is available that provides visibility into the number of v1 calls that are being made on any\r\ngiven instance. Customers can use this metric to monitor how often v1 is still being accessed as Amazon Machine\r\nImages, the AWS SDKs, CLIs, cloud-init, and other software accessing the IMDS is updated, released, and\r\nupgraded. When you can see that an instance can be launched, activated, used for service, and the metric is zero, it\r\nis safe to require v2 of the IMDS, disabling v1. For more information on transitioning to IMDSv2, see the user\r\nguide.\r\nSecurity can also be further enhanced while this transition is happening. AWS credentials provided by the IMDS\r\nnow include an ec2:RoleDelivery IAM context key. Credentials provided by the older IMDSv1 have an\r\nec2:RoleDelivery value of “1.0,” and credentials using the new scheme will have an ec2:RoleDelivery value of\r\n“2.0.” This context key makes it easy to enforce use of the new scheme on a service-by-service or resource-by-resource basis by using those context keys as conditions in IAM policies, resource policies, or AWS Organizations\r\nservice control policies. For example, if all of the software accessing an S3 bucket has been upgraded to use\r\nIMDSv2, then that S3 bucket can be safely restricted to only allow access to role-account credentials that have the\r\n“2.0” value (or greater) for the context key. The effect is that credentials retrieved using IMDSv1 will be\r\nprevented from accessing the bucket. AWS CloudTrail is also being updated to record the new ec2:RoleDelivery\r\nparameters.\r\nHear about IMDSv2 at re:Invent\r\nMark Ryland spoke in more detail about IMDSv2, and the transition to it, at AWS re:Invent in December 2019. To\r\nwatch a recording of the session, see Security best practices for the Amazon EC2 instance metadata service on\r\nYouTube.\r\nWant more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.\r\nSource: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-ser\r\nvice/\r\nhttps://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/" ], "report_names": [ "defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service" ], "threat_actors": [ { "id": "dfee8b2e-d6b9-4143-a0d9-ca39396dd3bf", "created_at": "2022-10-25T16:07:24.467088Z", "updated_at": "2026-04-10T02:00:05.000485Z", "deleted_at": null, "main_name": "Circles", "aliases": [], "source_name": "ETDA:Circles", "tools": [], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775446535, "ts_updated_at": 1775826753, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/12054d235b771dda70e3935596e674ad486678ed.pdf", "text": "https://archive.orkl.eu/12054d235b771dda70e3935596e674ad486678ed.txt", "img": "https://archive.orkl.eu/12054d235b771dda70e3935596e674ad486678ed.jpg" } }