EC2's most dangerous feature

Re:EC2's most dangerous feature by 0x0 on Sunday October 09, 2016 @06:23AM (#12670626)

This is interesting! Can this be abused with AWS-hosted services that reach out to fetch URLs? For example, image hosts that allow specifying an URL to retrieve, or OAuth callbacks, etc? Are there any tricks to be played if someone were to register a random domain and point it to 169.254.169.254 (or worse, flux between 169.254.169.254 and a public IP in case there is blacklisting application code that first checks to resolve the hostname but then passes the whole URL into a library that resolves again?)

[ Parent | on HN ]

Re:EC2's most dangerous feature by pfg on Sunday October 09, 2016 @08:58AM (#12670992)

That's a fairly common vulnerability. A good approach for services that need to fetch arbitrary URLs is roughly:

1. Resolve hostname and remember the response

2. Verify that the response does not contain any addresses in a private IP space, or any other IP that is only accessible to you

3. Use the IP from step 1 when establishing a connection

With other solutions, you might end up being vulnerable to DNS rebinding attacks.

Bonus points for doing all your URL fetching in some sort of sandbox that enforces these access rules.

[ Parent | on HN ]

Re:EC2's most dangerous feature by jamiesonbecker on Sunday October 09, 2016 @10:50AM (#12671432)

This is accurate.

Remember that even ELB's in AWS have IP's that change all the time, and this itself is actually a source of vulnerabilities from apps that don't respect DNS TTL's (as has been seen in the forums repeatedly -- apps get connected to the previous IP instead of the new one). It's probably safer to retrieve and verify the IP for each request, and just cache if the IP is 'safe'. (And just doing IP subnet calculations is non-trivial in most less-common languages.)

Also, request throttling should be maintained and HTTP verb checking, to prevent being turned into a proxy for other attacks.

Actually, any decision to accept an arbitrary URL should be carefully examined in light of how hard it is to do safely.

[ Parent | on HN ]

Re:EC2's most dangerous feature by the_arun on Sunday October 09, 2016 @12:53PM (#12672011)

What if we just check whether target host is 169.254.169.254 before allowing an HTTP call?

[ Parent | on HN ]

Re:EC2's most dangerous feature by BraveNewCurency on Sunday October 09, 2016 @02:05PM (#12672413)

As long as you manually get the IP for every domain. I.e. if they ask for "blah.com" you have to get the IP, check it, then turn it into "curl -H 'Host: blah.com' http://IP". (Otherwise, it may be a race condition that allows the DNS server to resolve to a different IP address the 2nd time. See https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use )

[ Parent | on HN ]

Re:EC2's most dangerous feature by cperciva on Sunday October 09, 2016 @06:28AM (#12670642)

The EC2 documentation specifically warns against allowing yourself to be tricked into loading your metadata for someone else.

So yes, there are probably lots of services which get this wrong; but they did at least get a warning about that particular failure mode.

[ Parent | on HN ]

Re:EC2's most dangerous feature by idunno246 on Sunday October 09, 2016 @07:13AM (#12670753)

Yes, one project I've worked on required a crawling bot, and you could crawl the metadata service...(until fixed). dont even need a domain in most cases, either the ip or instance-data DNS I bet works in a bunch of places.

We redid all our policies to be extremely restrictive in response, if the instance did anything based on user input. Anything more admin happened on a different machine.

[ Parent | on HN ]

Re:EC2's most dangerous feature by tptacek on Sunday October 09, 2016 @03:08PM (#12672814)

For real-world, complicated applications, that's virtually always a game-over vulnerability no matter what cloud you're deployed on. Be extraordinarily careful with backend code that generates HTTP requests based on user inputs.

Pentesters have been using this trick to pivot from unexpected backend web proxies to (e.g.) management consoles, LOM servers, JBoss interfaces, &c for 15 years or so already.

[ Parent | on HN ]