‘Belt and suspenders’ protections added to metadata services

AWS has added additional protection to its metadata services in a development that will eventually make server-side request forgery (SSRF) attacks far more difficult to pull off.

The new Metadata protocol, EC2 Instance Metadata Service (IMDSv2), mandates making a PUT request in order to get a token. This token must be used in all subsequent requests.

AWS bills the enhancements to its EC2 Instance Metadata Service as adding defense in depth against SSRF vulnerabilities and more.

The update also offers protection against misconfigured web application firewalls (WAFs) – a security mistake linked to the high profile breach at Capital One earlier this year.

In a blog post, AWS staffer Colm MacCárthaigh explains: “With IMDSv2, every request is now protected by session authentication.

“The token is never stored by IMDSv2 and can never be retrieved by subsequent calls, so a session and its token are effectively destroyed when the process using the token terminates.”

“Sessions can last up to six hours and a session token can only be used directly from the EC2 instance where that session began,” he added.

Amazon EC2 Instance Metadata Service (IMDS) is a platform that allows developers to build secure applications by managing access to temporary credentials, among other functions.

Four-fold protection

AWS will continue to support its existing instance metadata service (IMDSv1), which although not inherently insecure leaves firms at risk from underlying weaknesses in their infrastructure, such as poorly configured WAFs.

“IMDSv2 adds new ‘belt and suspenders’ protections for four types of vulnerabilities that could be used to try to access the IMDS,” according to AWS.

These vulnerabilities are listed by AWS as misconfigured open Website Application Firewalls, open reverse proxies, open layer 3 firewalls and NATs (Network Address Translation) devices. Unpatched SSRF vulnerabilities are also featured in the quartet.

The bottom line is that exploiting SSRF will become much more difficult, providing companies start to rely on IMDSv2.

Application security engineer Dylan Katz said on Twitter: “This is a solid improvement. It could be better (actually requiring auth or adding support for disabling the APIs would be nice). It also would've been better if this was the default BEFORE incidents like Capital One.”


Read more cloud security news from The Daily Swig


In its blog post, AWS goes on to say it has developed a number of tools to make “transitioning to v2 and disabling v1 seamless.”

“Both IMDSv1 and IMDSv2 will be available and enabled by default, and customers can choose which they will use," it said. "The IMDS can now be restricted to v2 only, or IMDS (v1 and v2) can also be disabled entirely. AWS recommends adopting v2 and restricting access to v2 only for added security."

“IMDSv1 remains available for customers who have tools and scripts using v1, and who are comfortable with the existing security posture of their instances.”

The Daily Swig asked AWS what plans, if any, did it have to depreciate support for IMDSv1 now that it’s introduced a more secure alternative. No word as yet but we’ll update this story as and when we hear more.

AWS’ Mark Ryland will be talking in more detail about IMDSv2, and the transition to it, at the upcoming AWS re:Invent conference next month.


YOU MIGHT ALSO LIKE WAF vendor Imperva issues post-mortem over August data breach