Der Metadaten Endpunkt kann von innerhalb jeder EC2-Maschine aufgerufen werden und bietet interessante Informationen darüber. Er ist unter der URL zugänglich: http://169.254.169.254 (Informationen über die Metadaten hier).
Es gibt 2 Versionen des Metadatenendpunkts. Die erste erlaubt den Zugriff auf den Endpunkt über GET-Anfragen (so kann jede SSRF ihn ausnutzen). Für die Version 2, IMDSv2, musst du ein Token anfordern, indem du eine PUT-Anfrage mit einem HTTP-Header sendest und dann dieses Token verwendest, um mit einem anderen HTTP-Header auf die Metadaten zuzugreifen (es ist also komplizierter auszunutzen mit einer SSRF).
Beachte, dass wenn die EC2-Instanz IMDSv2 durchsetzt, laut den Dokumenten, die Antwort der PUT-Anfrage ein Hop-Limit von 1 haben wird, was es unmöglich macht, auf die EC2-Metadaten von einem Container innerhalb der EC2-Instanz zuzugreifen.
Darüber hinaus wird IMDSv2 auch Anfragen blockieren, um ein Token abzurufen, die den X-Forwarded-For Header enthalten. Dies dient dazu, zu verhindern, dass falsch konfigurierte Reverse-Proxys darauf zugreifen können.
Sie können dann diese Anmeldeinformationen verwenden und sie mit der AWS CLI nutzen. Dies ermöglicht Ihnen, alles zu tun, wozu diese Rolle Berechtigungen hat.
Um die neuen Anmeldeinformationen zu nutzen, müssen Sie ein neues AWS-Profil wie dieses erstellen:
Beachten Sie das aws_session_token, dies ist unerlässlich, damit das Profil funktioniert.
PACU kann mit den entdeckten Anmeldeinformationen verwendet werden, um Ihre Berechtigungen herauszufinden und zu versuchen, die Berechtigungen zu eskalieren.
SSRF in AWS ECS (Container Service) Anmeldeinformationen
ECS ist eine logische Gruppe von EC2-Instanzen, auf denen Sie eine Anwendung ausführen können, ohne Ihre eigene Clusterverwaltungsinfrastruktur skalieren zu müssen, da ECS das für Sie verwaltet. Wenn es Ihnen gelingt, einen Dienst, der in ECS läuft, zu kompromittieren, ändern sich die Metadatenendpunkte.
Wenn Sie http://169.254.170.2/v2/credentials/<GUID> aufrufen, finden Sie die Anmeldeinformationen der ECS-Maschine. Aber zuerst müssen Sie das <GUID> finden. Um das <GUID> zu finden, müssen Sie die environ-Variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI innerhalb der Maschine lesen.
Sie könnten in der Lage sein, dies auszulesen, indem Sie eine Path Traversal zu file:///proc/self/environ ausnutzen.
Die genannte HTTP-Adresse sollte Ihnen den AccessKey, SecretKey und Token geben.
Beachten Sie, dass Sie in einigen Fällen auf die EC2-Metadateninstanz vom Container aus zugreifen können (überprüfen Sie die zuvor erwähnten IMDSv2 TTL-Beschränkungen). In diesen Szenarien könnten Sie vom Container aus sowohl auf die IAM-Rolle des Containers als auch auf die IAM-Rolle der EC2 zugreifen.
SSRF für AWS Lambda
In diesem Fall werden die Anmeldeinformationen in Umgebungsvariablen gespeichert. Um auf sie zuzugreifen, müssen Sie auf etwas wie file:///proc/self/environ zugreifen.
Die Namen der interessanten Umgebungsvariablen sind:
AWS_SESSION_TOKEN
AWS_SECRET_ACCESS_KEY
AWS_ACCES_KEY_ID
Darüber hinaus haben Lambda-Funktionen neben IAM-Anmeldeinformationen auch Ereignisdaten, die an die Funktion übergeben werden, wenn sie gestartet wird. Diese Daten werden der Funktion über die Runtime-Schnittstelle zur Verfügung gestellt und könnten sensibleInformationen enthalten (wie in den stageVariables). Im Gegensatz zu IAM-Anmeldeinformationen sind diese Daten über standardmäßiges SSRF unter http://localhost:9001/2018-06-01/runtime/invocation/next zugänglich.
Beachten Sie, dass Lambda-Anmeldeinformationen in den Umgebungsvariablen enthalten sind. Wenn der Stack-Trace des Lambda-Codes Umgebungsvariablen ausgibt, ist es möglich, sie durch Provokation eines Fehlers in der App zu exfiltrieren.
SSRF-URL für AWS Elastic Beanstalk
Wir rufen die accountId und region von der API ab.
Um das exfiltrierte Dienstkonto-Token zu verwenden, können Sie einfach Folgendes tun:
# Via env varsexport CLOUDSDK_AUTH_ACCESS_TOKEN=<token>gcloudprojectslist# Via setupecho"<token>">/some/path/to/tokengcloudconfigsetauth/access_token_file/some/path/to/tokengcloudprojectslistgcloudconfigunsetauth/access_token_file
# PowershellInvoke-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
Azure App Service
Aus der env können Sie die Werte von IDENTITY_HEADERundIDENTITY_ENDPOINT abrufen. Diese können Sie verwenden, um ein Token zu sammeln, um mit dem Metadatenserver zu kommunizieren.
In den meisten Fällen benötigen Sie ein Token für eine dieser Ressourcen:
# Check for those env vars to know if you are in an Azure appecho $IDENTITY_HEADERecho $IDENTITY_ENDPOINT# You should also be able to find the folder:ls/opt/microsoft#and the filels/opt/microsoft/msodbcsql17# Get management tokencurl"$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2017-09-01"-Hsecret:$IDENTITY_HEADER