Instance Metadata Abuse

What Is Instance Metadata Abuse?

The instance metadata service answers any request made from inside the instance, and one of the things it hands back is the instance role's temporary credentials. It authenticates nothing, which turns an ordinary server-side request forgery bug into cloud credential theft. You'll point an import feature's source_url at 169.254.169.254, read the access key, secret and session token, and use them to reach data the application never could. The fix is IMDSv2: require a session token so a single forged GET cannot complete, and set the response hop limit.

What You'll Learn in Instance Metadata Abuse

• The metadata service vends role credentials to anything that can make a request from inside the instance, with no authentication of its own.
• A request-forging bug in the application becomes a cloud credential theft, and then a control-plane pivot.
• Requiring a session token turns a single forged request into a two-step exchange most forging bugs cannot complete.
• Fix it in the instance configuration, because that covers every request-forging bug rather than the one that was found.

Instance Metadata Abuse — Training Steps

1. A server that fetches for you

   Bob is working Vurloch, a company whose software runs building inspections: schedules, reports, and the access details inspectors need to get into properties. One feature stands out to him, because it does the fetching itself. Inspectors can import a report by pasting a URL. Vurloch's server retrieves it. That means Bob can make Vurloch's server request things Bob cannot reach directly.

2. What the feature actually does

   Before touching it, Bob reads what the page is offering. It is an import tool: paste a link to an inspection report and Vurloch files it against the property. The interesting part is who does the downloading.

3. Use the feature as intended

   He starts by using it the way an inspector would: paste a partner's report URL and let Vurloch fetch it. What he is really doing is getting the request on the wire so he can look at it.

4. The URL is just a parameter

   The import worked. Bob opens the network panel and looks at what the page actually sent, because a feature that fetches URLs is only interesting if he controls the URL.

5. Point it at the metadata service

   There is one address that only answers from inside a cloud instance: the metadata service, on a fixed link-local IP. It vends the instance's own role credentials to anything on the instance that asks. Bob edits the captured request, replacing the partner URL with that address, and resends it.

6. It fetched the credentials

   The server did exactly what it was asked, and handed back what came out the other end.

7. Whose credentials are these

   Bob saves the three values into a profile and asks the cloud who he now is.

8. What the server could reach that the app never exposed

   The application can file a report against a property. The role behind it can do far more, and Bob goes looking for the data the app keeps but never hands out. He streams the inspection archive straight to his terminal.

9. Where the credentials came from

   Bob has physical access details for tens of thousands of properties, taken through a feature that just fetches URLs.

10. The server's identity, used like a person

    Vurloch's monitoring flags the app instance's role reading storage it has no reason to touch.