5 ms·

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

by 0x0 10y ago

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?)

cperciva 10y ago
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.
idunno246 10y ago
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.
pfg 10y ago
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.
- jamiesonbecker 10y ago
  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.
  - the_arun 10y ago
    What if we just check whether target host is 169.254.169.254 before allowing an HTTP call?
    - BraveNewCurency 10y ago
      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" 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 https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use )
tptacek 10y ago
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.

by 0x0 10y ago

cperciva 10y ago

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.

idunno246 10y ago

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.

pfg 10y ago

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.

jamiesonbecker 10y ago
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.
- the_arun 10y ago
  What if we just check whether target host is 169.254.169.254 before allowing an HTTP call?
  - BraveNewCurency 10y ago
    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" 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 https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use )

tptacek 10y ago

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.