Kringgå 2FA? Lika lätt som 1,2,3!

Tvåfaktorsautentisering, eller 2FA, har ofta lyfts fram som lösningen som ska rädda oss från phishing-angrepp. Medan det mycket riktigt stämmer att dessa attacker försvåras så kvarstår frågan

Är det möjligt att kringgå 2FA?

I detta blogginlägg kommer jag besvara den frågan och med fritt tillgängliga verktyg visa hur vem som helst kan kringgå 2FA via phishing-angrepp. Det är trots allt lika lätt som 1,2,3.

Dagens stjärna

Innan vi hoppar in i själva ”huret” tänkte jag först viga lite tid åt dagens stjärna. Låt mig introducera:

Modlishka
Modlishka är i grund och botten en väldigt simpel applikation. Det kan närmast beskrivas som en omvänd proxy som hanterar förfrågningar från en server som ägs av angriparen fram till den legitima tjänsten. Applikationen är perfekt för oss som är lata (eller effektiva) och inte vill hantera allt det tråkiga med att upprätta en omvänd proxy. Det finns även stöd för funktioner så som att lägga till ett TLS-certifikat för att få din sida att se mer legitim ut (tyvärr inte demonstrerat i den här bloggen) och identifiering och routing av subdomäner.

Modlishka hittar ni på https://github.com/drk1wi/Modlishka

Steg 1: Prep Time

Innan vi kan påbörja vår attack måste vi först förbereda våra verktyg. Vårt mål blir en Nextcloud plattform, vilket är en vanligt förekommande plattform för att distribuera filer och dokument. Nextcloud har bland annat stöd för s.k. Time-based One Time Passwords eller TOTP för att sköta tvåfaktorsautentiseringen men som vi snart kommer lära oss så spelar valet av andrafaktor oftast inte någon större roll.

För våra tester så har vi två domäner. Simovits och Simovits elaka kusin Simovuts.
Under subdomänen nextcloud.lab.simovits.com kommer vi hysa den legitima instansen av Nextcloud som i ett riktigt scenario skulle vara uppsatt av användaren som vi ska lura eller bolaget som användaren jobbar för. Domänen Simovuts är däremot registrerad av angriparen och kommer tjäna som en mellanhandsproxy som presenterar användaren med samma legitima applikation som finns på domänen Simovits. Skillnaden är att vi som angripare loggar allt som skickas från vår mellanhandsproxy vilket inkluderar sessionstoken.

Innan vi kan starta Modlishka måste vi först konfigurera applikationen till att peka på vår legitima Nextcloud plattform sådant att Modlishka vet vad den ska framföra förfrågningar till. Detta utförs enkelt genom att peka Modlishka på en Json-fil med färdiga inställningar eller själv mata in inställningarna när Modlishka körs. Jag valde att konfigurera Modlishka via den tillhörande Json-fil då jag anser att det är snäppet smidigare än att ange parametrar vid exekvering av programvaran.

Nu när allting är konfigurerat, felsökt och klart så kör vi igång Modlishka.

Efter en snabb titt i Modlishkas output så ser det ut som allting fungerar som det ska.
Testar vi nu att gå mot vår Modlishka-domän, http://nextcloud.lab.simovuts.com så möts vi av samma innehåll som på den legitima sidan. Skillnaden är att alla förfrågningar går genom Modlishkas proxy.

Modlishka sköter allt jobb gällande navigering till index-sidan och login-prompten vilket gör det hela till en väldigt trevlig upplevelse för vår ovetande användare.

Steg 2: Inväntar respons…

Nu kommer vi till den jobbiga delen. Väntan.
Vi väntar nu på att användaren navigerar till vår server, som i ett riktigt fall skulle kunna distribueras via en länk i ett phishing-mejl, och hoppas att användaren loggar in.

Plötsligt rasslar det till i Modlishka-konsolen och vi ser följande

Nu har vi allt vi behöver för att logga in på den Nextcloud-plattformen och ta över den aktiva sessionen.

Steg 3: Redo att köra!

Nu när vi har en sessionstoken så är allting som kvarstår att ändra sessionstoken för Nextcloud i vårt val av webbläsare. Därefter uppdaterar vi sidan och Voilá! Vi har kringgått 2FA och är nu redo att åstadkomma kaos och förstörelse.

Jag lämnar det upp till läsaren att avgöra vad för kaos och förstörelse som bäst är lämpad målet men i vanlig ordning är det viktigt att agera inom lagens gränser och aldrig angripa en person eller organisation utan explicit tillåtelse. 

Hur ska vi se på tvåfaktorsautentisering i framtiden?

2FA har många gånger lyfts fram som en lösning som ska rädda oss när användare råkat ge ifrån sig sina inloggningsuppgifter i ett phishing-angrepp. Det bakomliggande syftet med den här bloggen är att visa på att vi inte blint kan förlita oss på 2FA. Det finns fritt tillgängliga verktyg, ett flertal guider och andra resurser som angripare kan använda för att själva konstruera attacker liknande den som demonstrerats ovan.

Då majoriteten av alla 2FA-lösningar resulterar i en sessionstoken så spelar det heller ingen större roll vilken typ av tvåfaktorsautentisering som har använts eller hur komplext lösenordet är. Vi har en giltig sessionstoken oavsett vilken lösning användaren använt för att logga in.

Så är 2FA trasigt? Svaret är nej. 2FA är ett utmärkt skydd som förhindrar majoriteten av alla phishing-angrepp som sker i dagsläget. Vi som säkerhetsexperter bör däremot vara uppmärksamma på att det inte är en silverkula mot kontokapning och att vi inte bara kan aktivera 2FA på alla våra tjänster och därefter luta oss tillbaka. Vi måste fortsätta arbeta aktivt och försvåra arbetet för angriparna och upplysa våra användare om riskerna som de kan stöta på i vardagen.

Slutligen tänkte jag komma med lite tips på hur ni kan undvika dessa typer av attacker.

Registrera domäner med närliggande namn: Typo-squatting, likt exemplet ovan, ökar sannolikheten till en lyckad phishing-attack markant. Våra ögon lurar oss ofta och även en vaksam användare kan missa ett extra O i Google eller ett extra I i Poliisen.

Glöm inte förnya registreringen av subdomäner: Subdomäner som löpt ut kan tas över av en angripare och agera som en ypperlig plattform för phishing-angrepp.

Informera och utbilda användare. Ständigt: Ja, jag vet att detta är ett generiskt och tråkigt tips men faktum är att det också är en av de mest effektiva metoderna för att förhindra attacker mot din organisation/bolag. Det räcker däremot inte att ha ett utbildning- eller informationstillfälle. Meddelandet som ska framföras måste repeteras med jämna frekvenser för att det inte ska falla ur minnet.