Del 4- Penetrationstestning i Azure – Hanterade Identiteter, eskalering av privilegier och dataläckage från lagringskonton

Del 4- Penetrationstestning i Azure – Hanterade Identiteter, eskalering av privilegier och dataläckage från lagringskonton

I det här inlägget kommer vi att gå igenom  ”Hanterade Identiteter” i Azure.

Vad kan hända om en attackerare får kontroll över en ”Hanterad Identitet” med för frikostigt satta rättigheter.

Hanterade Identiteter är objekt i Azure AD som gör det möjligt för en virtuell maskin (VM) att agera som en användare i Azure-miljön, i den specifika prenumerationen som den finns i. Detta är inte unikt för Azure utan används även t.ex. i Amazon (AWS) och Google Cloud (GCP).  Hanterade Identiteter har inga lösenord, utan är redan autentiserade mot Azure med hjälp av certifikat. Den kod eller de funktioner som körs på en VM kan göra anrop mot Azures Metadata Server och på så vis få access till olika Azure resurser som t.ex. lagring, databaser etc.

Eskalering av privilegier

I detta scenario har vi en ”Hanterad Identitet” som är kopplad till en virtuell maskin (VM) som körs i Azure. Att administrera och konfigurera ”Hanterade Identiteter” i Azure har en viss komplexitet som lämnar utrymme för felkonfiguration och att principen om lägsta behörighet inte följs. I detta scenario har den ”Hanterade Identitet” som använts fått rollen “Storage Account Contributor”, det är en roll med relativt höga rättigheter som vi kommer att se nedan.

En attackerare har lyckats ta sig in på en virtuell maskin som en lågt privilegierad användare och försöker eskalera sina rättigheter. Attackeraren har i detta scenario fått åtkomst till en Windows VM och PowerShell, men attacken fungerar på samma sätt om det hade varit en Linux VM med Bash eller ett annat OS, eftersom den bygger på API-anrop mot Azures Metadata-server. I och med att attackeraren kan göra anrop mot Metadata-servern från maskinen, får denne också tillgång till den ”Hanterade Identitet” som är kopplad till maskinen.

Attackeraren kan antingen hämta in färdig kod som finns tillgängligt externt någonstans, eller så kan denne exekvera de kommandon som behövs direkt från PowerShell.

Vi visar här hur attackeraren läser in färdig kod som finns externt och laddar in den som en PowerShell modul. Med hjälp av modulen exekveras ett antal kommandon som listar alla lagringskonton med tillhörande nycklar för den prenumeration vi befinner oss i.

När attackeraren har fått ut nycklarna till lagringskontona finns många valmöjligheter för vad denne kan åstadkomma härnäst. Vi visar här hur man kan ansluta till lagringskontot med Azure Storage Explorer.
Kontot “sensitivedata-1” ser intressant ut från en attackerares perspektiv.  Det är ett konto som inte används av någon tjänst, utan som endast använts för att lagra känslig data i Azure.

Efter att ha kommit över nyckeln, har nu attackeraren full tillgång till kontot och kan ansluta till det med Azure Storage Explorer.
I och med att attackeraren har fått tag på nyckeln, har han fulla rättigheter till lagringskontot och kan ansluta till det med Azure Storage Explorer:

Attackeraren kan nu gå vidare på olika sätt med sin attack:

• Ladda ner all data från alla lagringskonton
• Ta bort all data på lagringskontona
• Modifiera visst data och lägga in skadlig kod för att attackera användarna och skaffa sig ytterligare privilegier
• Byta ut de två nycklar som finns per lagringskonto till egna nycklar. Eftersom Azure tillämpar kryptering i vila innebär det att ingen, förutom attackeraren, kan dekryptera innehållet och innehållet blir otillgängligt för alla användare. Detta får liknande effekt som en Ransomware-attack.

Hur ser riskerna ut för ett attackscenario, som beskrivs ovan?

En miljö som kan nås antingen via internet eller den interna miljön, konfigurerad enligt den här beskrivningen, där en virtuell maskin är kopplad till en ”Hanterad Identitet” med alltför frikostiga behörigheter. Den löper även stora risker att bli utsatt för en liknande attack.

Hur kan användaren skydda sig?

För att skydda sig mot liknande attacker föreslår vi:

• “Zero trust-tänk”.  Det vill säga, lyckas en attackerare med ett intrång mot ett objekt eller en tjänst i molnet, skall attackeraren inte kunna ta sig vidare därifrån
• Kontinuerlig översyn av konfiguration och privilegier för ”Hanterade Identiteter”
• Härdning av virtuella maskiner
• Pentetrationstester av virtuella maskiner och webapplikationer

Del 4- Penetrationstestning i Azure – Hanterade Identiteter, eskalering av privilegier och dataläckage från lagringskonton

-Slutsats och diskussion

Vi har i detta exempel visat eskalering av privilegier för en ”Hanterad Identitet” med “Storage Account Contributor- rättigheter”. Det kunde lika gärna varit andra rättigheter som attackeraren kom över efter att den virtuella maskinen hade utsatts för intrång. De hade i sådana fall lett till en annan typ av eskalering av rättigheter. Vi kommer att gå igenom olika typer av eskalering av privilegier i kommande inlägg  ”Hanterade Identiteter” är inte heller enbart kopplade till virtuella maskiner, utan kan även appliceras på andra tjänster i Azure såsom “Web App Service” och “Azure Functions”.

Läs mer:

Del 1 – Penetrationstestning i Azure och vikten av säkerhetsgranskning och vaksamhet i molnet
Del 2 – Penetrationstestning i Azure – Användarkonton och lösenordsattacker
Del 3 – Penetrationstestning i Azure och risker med lagrade autentiseringsuppgifter