Del 2 Penetrationstestning i Azure – Användarkonton och lösenordsattacker

Del 2 Penetrationstestning i Azure – Användarkonton och lösenordsattacker

I det första blogginlägget belystes flera säkerhetsrelaterade utmaningar ur en pentestares perspektiv.

Nu fördjupar vi oss inom användarkonton, lösenord och attacker mot dessa, samt hur användaren kan skydda sig. 

Ganska ofta ställs frågan: Hur får vi användarna att välja bra lösenord?

• Hur många tecken ska ett starkt lösenord innehålla?
• Vilken komplexitetsnivå ska det ha? (specialtecken, siffror, gemener/VERSALER, etc.)
• Hur ska användarna komma ihåg lösenorden utan att använda fusklappar…?

Använder de samma lösenord till flera tjänster och plattformar? Om ja, vad händer då om en av dessa tjänster utsätts för en attack!?

MFA (Multi Factor Authentication) är en mekanism som implementeras för att förstärka säkerheten i autentiseringen av användare. Det anses vara ett starkt skydd för att förhindra obehörig åtkomst även om lösenordet skulle hamna i en angripares händer. När säkerhetsmekanismer implementeras har leverantörerna såklart användarvänlighet i åtanke och i vissa fall tar man lite för stor hänsyn till det på bekostnad av säkerheten. Exemplet nedan är ett konfigurationsval som kan påverka säkerheten.

En närmare titt

En närmare titt på den här konfigurationsmöjligeten får en säkerhetsmedveten person att tänka: Vilka är konsekvenserna om plattformen blir utsatt för ett angrepp och den här inställningen är på?

En skicklig angripare som håller sig under radarn kan utnyttja det för att kringgå MFA.

Enligt vår erfarenhet är det en fin balansgång mellan säkerhet och användarvänlighet. Ofta vill utvecklarna av en applikation att den skall vara så användarvänlig som möjligt. Detta ställer samtidigt höga krav på noggrann säkerhetsgranskning så att det därigenom inte öppnas upp oavsiktliga säkerhetsluckor.

Detta är ett exempel, men det är inte svårt att föreställa sig ett flertal scenarier som kan utsätta en organisation för risker, men låt oss gå vidare och titta på när vår testmiljö utsattes för angrepp.

Testmiljön konfigurerades med tillhörande Azure AD-inställningar, webbsidor och webapplikationer, lagringskonton, nätverksinställningar med mera, för att efterlikna en vanlig konfiguration av ett företags cloud-miljö.

Vi skapade en användare som fick heta Chris och givetvis behöver vår användare ett lösenord.

Vi testade om det var möjligt att sätta ett enkelt och mycket vanligt förekommande lösenord, sommar17, men det uppfyllde inte kraven för godkänt lösenord i Azure. Ok, vad händer om användaren insisterar på att försöka hitta ett så enkelt lösenord som möjligt? Istället testades Sommar17 (med stort S) och det ansågs vara starkt nog att användas som lösenord för ett konto. Ett så enkelt lösenord är en mardröm för en pentestare och en ännu större mardröm för användaren Chris som strax kommer att bli utsatt för en attack.

För att ta över användarkontot och utföra en så kallad “Bruteforce” attack, användes ett skript för att enumerera och validera användarkonton (sk Account Enumeration)

Viktigt att notera är att angriparen även måste känna till namnet på plattformens (tenant) namn, vilket går att få fram med hjälp av olika tekniker. Azure erbjuder olika lösningar för att skydda användarkonton. En av lösningarna är “Smart lockout” som beskrivs på följande vis av leverantören:

”Smart utelåsning” hjälper dig att låsa upp dåliga aktörer som försöker gissa dina användares lösenord eller använda råa metoder för att komma igång.  Den kan identifiera inloggningar som kommer från giltiga användare och behandla dem annorlunda än för angripare och andra okända källor.  Smart utelåsning låser angriparna och låter användarna fortsätta att komma åt sina konton och vara produktiva.

Som standard låser Smart utelåsning kontot från inloggnings försök i en minut efter 10 misslyckade försök.  Kontot låser sig igen efter varje efterföljande misslyckad inloggnings försök, i en minut vid första och längre vid efterföljande försök.

Givetvis stämde detta påstående och kontot låstes flera gånger under vår simulerade attack vilket syns på bilden nedan:

Varje gång kontot låstes upp igen fick användaren sätta ett nytt lösenord.

Har ni varit med om att vissa miljöer är riktigt luriga och jobbiga och säger: “Nej det här lösenordet har du använt innan, kom på ett nytt”?
Det upplevdes dock inte i testmiljön, utan det var möjligt att återanvända samma lösenord flera gånger.

Att kunna återanvända samma lösenord är så klart inte bra av säkerhetsskäl. Ett lager av “defense in depth”-principen sätts därmed ur spel.

Om attackeraren redan har kommit över lösenordet eller lösenordshashen och det inte ändras,  kan angriparen ostört arbeta vidare.

Flera studier (exempelvis Många slarvar med sina lösenord)  har gjorts på människors beteende och dessa visar att användare kommer att återanvända gamla lösenord om det är möjligt. De använder också i stor utsträckning samma lösenord på flera olika platser och i flera miljöer.

Låt oss återgå till testmiljön. Nu är vi medvetna om att kontot kommer låsas vid fler än 10 försök per minut. Därför testade vi en annan strategi och ökade tidsintervallet mellan varje försök för att komma under den gränsen.

Detta var möjligt att utföra med verktyget “Burp Suite”. I verktyget finns avancerade inställningar där en angripare kan ställa in olika tidsintervaller mellan försöken:

Resultatet, när tidsintervallet ökade mellan försöken , var att vi lyckades undvika att låsa kontot, vilket kan ses på bilden nedan. Efter flera misslyckade lösenordsgissningar kunde verktyget med anpassade inställningar hitta rätt lösenord:

Med denna gissningsfrekvens kan en angripare testa ca 13 000 lösenord per dygn. Det låter kanske mycket, men en samling standardlösenord kan innehålla 10 miljoner poster. Det skulle ta en attackerare två år att testa igenom en sådan lista. Det är möjligt för en angripare att vidta ett antal åtgärder för att snabba på processen.

En annan vanligt förekommande attack som skulle kunna utföras är Password Spraying. Istället för att testa många lösenord mot en användare, testas istället ett lösenord mot flera användare. Denna attack-teknik minskar risken för upptäckt och att låsa konton. För att kunna genomföra denna attack måste attackeraren känna till användarnamnen och plattforms (tenant)-namnet.

Åtgärder

MFA

Med MFA försvinner till stor del problematiken med svaga lösenord eftersom användaren måste komma över ytterligare en faktor för att kunna autentisera sig. Fast, som med det mesta som gäller säkerhet finns det sätt att komma runt det. Det är dock inte något som är trivialt att göra utan kräver kostsamma och komplexa attacker, och de flesta attackerare som stöter på ett konto som är skyddat med MFA föredrar att gå vidare till ett nytt lättare offer.

Utan MFA implementerat är man också ett lätt mål för Phishing-attacker, vilket är ett vanligt problem idag för många organisationer.

Azure AD Password Protection

Azure har skydd mot Password Sprayingattacker, mer information om det kan hittas här.
Det skyddet verkar dock inte vara heltäckande för vanligt förekommande svenska lösenord eftersom vi kunde använda lösenordet Sommar17. Det innebär att man som administratör bör titta på att förstärka den lösenordspolicy som är satt som standard, om man vill öka sitt skydd mot Password Sprayin-attacker.

Lösenordspolicy

En säkerhetsåtgärd man själv kan vidta för att bemöta Brute Force och Password Spraying attacker är att ändra lösenordspolicyn och implementera en starkare komplexitet än den som är satt som standard i plattformen.

Några bra exempel på lösenordspolicy:

• Minimum 10 tecken
• Minst 2 specialtecken
• Tvinga användare byta förinställda lösenord vid första inloggning
• Implementera lösenordshistorik. Detta innebär att en användare inte kan återanvända ett gammalt lösenord under ett visst antal cykler. Sätt ett relativt högt värde på denna parameter för att undvika att användare försöker kringgå begränsningen.

Ev  Tidsbegränsa åldern på ett lösenord till ett visst antal dagar (t.ex. 90 dagar). Detta är dock något som allt mer börjar att frångås baserat på att det är förknippat med ett äldre tänk, kostnader förknippat med våra beteenden samt en ökad risk. Om det finns intressant läsning här från SANS. Oavsett så är alla överens om att lösenordet längd är helt avgörande för säkerheten.

Som ett komplement till lösenordspolicy, genomför även med jämna mellanrum en audit kring om kontot/lösenordet finns med i läckta databaser. Detta kan förenklas med en prenumerationstjänst.

Utbilda användare/User awareness

Oavsett hur många policies en organisation implementerar i lösningen har dessa ingen effekt om inte användare har rätt kunskap och säkerhetsmedvetenhet.

Varje organisations användare är första linjen i försvaret. Utan rätt kunskap och utbildning hos användarna kan en angripare enkelt ta sig förbi detta hinder.

Öka varje användares säkerhetsmedvetande och kunskap om vad ett svagt lösenord skulle kunna innebära. Konsekvenserna av ett svagt lösenord kan t.ex. visas genom att låta en säkerhetsgranskare demonstrera hur ett enkelt lösenord kan knäckas på kort tid. Detta kan hållas i form av en kort träff där man samlar företagets samtliga anställda för en presentation.

Säkerhetsgranskning

Sist men inte minst, återkommande säkerhetsgranskning av konfigurationen.

En säkerhetsgranskning kan innebära att man t.ex. tittar på några av följande frågeställningar:

• Lösenordspolicy och implementation av MFA
• Vem/vilka har admin-behörighet?
• Följs principen om lägsta behörighet, eller har vissa användare fått för frikostiga rättigheter? Vilka risker kan detta i så fall innebära?
• Används rätt krypteringsverktyg? Krypteras data i rörelse och i vila?
• Har regelbunden säkerhetsuppdatering utförts på plattformen?

• Har känsligt data identifierats och hanterats korrekt?

Del 2 Penetrationstestning i Azure – Användarkonton och lösenordsattacker – Slutsats

Vi har i denna artikel visat att det är möjligt för en attackerare att verifiera fram användarkonton och genomföra långsamma, systematiska attacker mot dessa för att komma över lösenorden. Azures inbyggda skydd går att kringgå och är ett lager i “defense in depth”-strategin som man bör följa när man hanterar lösningar i molnet.

Utan MFA (Multi Factor Authentication) eller en stark lösenordspolicy är man sårbar för ovan nämnda attacker. Som administratör bör man alltså se över dessa bitar. Vi rekommenderar också att genomföra löpande säkerhetsgranskningar för att säkerställa att miljön har en god säkerhetsstatus.

I kommande artikel kommer vi att visa hur en angripare, som har kommit över autentiseringsuppgifter, kan missbruka användarens behörigheter när dessa inte följer principen om lägsta behörighet.

Håll utkik efter nästa del i denna blogg-serie.

Läs mer:
Del 1 – Penetrationstestning i Azure och vikten av säkerhetsgranskning och vaksamhet i molnet
Del 3 – Penetrationstestning i Azure och risker med lagrade autentiseringsuppgifter
Del 4 – Penetrationstestning i Azure – Hanterade Identiteter, eskalering av privilegier och dataläckage från lagringskonton