Skydda dina kakor med hjälp av Device Bound Session Credentials (DBSC)

Ett säkerhetshot som drabbar många användare (och företag) är cookie stealing malware. Alltså skadlig kod vars egentligen enda syfte är att stjäla kakor från våra datorer.

Konsekvenserna av att få sina kakor stulna är att en användare som loggat in med ett jättekomplicerat lösenord, och autentiseringsdosan… ändå inte är skyddad. För trots alla dessa fina åtgärder så finns det i botten en liten jäkla text-fil som innehåller “beviset” på att användaren är inloggad. Jag skrev lite om detta i Mörka Sanningen om MFA .

Och med detta som bakgrund kan vi så förflytta oss till DBSC, eller Device Bound Session Credentials som det egentligen heter. Ett initiativ från Google som syftar till att skydda användare och deras autentiserade surfande.

Vi tar det från början.

Device Bound Session Credentials från Google

För några veckor sedan annonserade¹ Chromium Project (läs: Google) ett spännande initiativ de kallar för Device Bound Session Credentials (DBSC). Detta är ett nytt försök (ja, nytt… jag återkommer till det) att skydda användare från cookie stealing malware som gärna kopierar sessionskakor. DBSC skyddar indirekt kakorna genom att skydda sessionen och knyta kakan till en skyddad session, samt endast använda kortlivade kakor.

Nu blev det kanske krångligt.

Målet, kort och gott, är att knyta aktiva sessioner i webbläsaren till den enhet på vilken den ursprungligen skapades. Detta skulle då innebära, är tanken, att det inte kommer spela någon roll om en angripare kopierar kakorna till en annan enhet eftersom de inte längre befinner sig på den ursprungliga enheten och angriparen inte har möjlighet att bevisa att hen också “äger” sessionen.

För att detta ska fungera behöver vissa tekniska kriterier uppfyllas t.ex. att aktuell enhet har stöd för Trusted Platform Modules (TPMs)² för att kunna skydda de nycklar som enligt förslaget behöver användas för att skydda sessionerna. Dock menar Google att de undersöker möjligheten att också stödja mjukvarubaserade lösningar.

When the browser starts a new session, it creates a new public/private key pair locally on the device, and uses the operating system to safely store the private key in a way that makes it hard to export. Chrome will use facilities such as Trusted Platform Modules (TPMs) for key protection, which are becoming more commonplace and are required for Windows 11, and we are looking at supporting software-isolated solutions as well.

Specifikt pekar Google på hur Microsoft genom virtualiseringsbaserad lagring kan erbjuda en mjukvarulösning för lagring av nycklarna.³

Nytt? Nej, egentligen inte: Token Binding

Det fanns tidigare något som kallades för Token Binding⁴ vilket också ville försöka skydda de känsliga kakorna (bland annat) från att kopieras och användas av angripare. Token Binding tänkte använda sig utav utökningar i Transport Layer Security (TLS). Och även om det egentligen är en ganska fin standard med relativt brett stöd från branschen saknas det ändå stöd i de flesta webbläsare. Dock så fick Microsoft Edge ganska tidigt stöd för detta.

Och i Augusti 2018 menar Chromium projektet att de kommer ta bort stöd för Token Binding i Chrome med hänvisning till att skadlig kod inte ligger inom ramen för deras hotmodell.⁵

Client malware seems to be the most-often cited example in Token Binding discussions, yet this is outside the scope of Chrome’s threat model.

Och sedan 2020 verkar ingenting ha hänt på Token Binding-fronten vilket då tar oss till DBSC.

… hur, fungerar det då?

DBSC introducerar två saker⁶:

1. Ett nytt protokoll
2. Funktioner i webbläsaren

Tillsammans ska dessa möjliggöra för en webbläsare att hantera och bevisa att en viss enhet har tillgång till en given kryptografisk nyckel. För varje session som upprättas mellan webbläsaren och en webbserver skapas det ett unikt asymmetriskt nyckelpar där den publika nyckeln skickas till webbservern. Observera att detta alltså inte görs som en del av TLS utan i tunneln och således direkt mellan webbapplikationen och webbläsaren.

DBSC-protokollet gör så att webbläsaren får möjlighet att kontrollera livstiden på sessionsnycklarna, och bakom den här “sessionsabstraktionen” även möjlighet att periodiskt och automatiskt bevisa att enheten fortfarande har tillgång till nycklarna som skapade sessionen.

Genom dessa periodiska kontroller begränsas den skadliga koden från att flytta kakor och använda dessa från andra enheter. Detta ökar således chanserna att webbläsaren, och webbapplikationen upptäcker den eventuella kakstölden.

DBSC dödar också långlivade sessionskakor genom att istället introducera korta sessionskakor som webbläsaren kontinuerligt behöver kontrollera, och återbegära om de saknas.

Ungefär så här ser flödet ut:

Antagandet är att det finns något som behöver skyddas, t.ex. en inloggning.

1. Användaren begär inloggning.
2. Webbservern skickar med en http-header som innebär start av session.
3. Webbläsaren begär av TPM ett nyckelpar att använda för sessionen.
4. TPM skickar tillbaka en publik nyckel.
5. Webbläsaren skapar en JSON Web Token (JWT) och begär signering.
6. TPM skickar tillbaka signerad JWT.
7. Webbläsaren skickar genom POST och mot en dedikerad http-endpoint den signerade JWT:n innehållandes den publika nyckeln.
8. Webbservern svarar med en kortlivad cookie som innehåller information kakans giltighet och URL:er.

Vid varje ny begäran kontrollerar webbläsaren att det finns en giltig cookie, och om det gör det så genomförs anropet som vanligt.

Den observanta läsaren kanske tycker det känns udda att webbläsaren kontrollerar om det finns en giltig cookie. Och ja, det kan man tycka. Men här är det faktiskt så att webbläsaren behöver kontrollera om den av användaren begärda resursen från webbservern behöver en specifik cookie. Och om den gör det så behöver webbläsaren kontrollera om den fortfarande är giltig, om inte så behöver den fräschas upp.

Men om det inte finns så behöver webbläsaren genomföra en “refresh” vilket innebär att den behöver begära från webbservern viss information, signera med hjälp av TPM och skicka tillbaka “beviset” att den fortfarande har nycklarna. Om servern godkänner detta så skickar den tillbaka nya kakor som innehåller eventuellt nya namn och “krav”.

Webbläsaren kan nu genomföra anropet.

Vilka utmaningar finns med DBSC?

DBSC förhindrar inte missbruk av kakor på en infekterad dator. Antag att nycklarna sparas i en TPM som erbjuder möjligheten att digitalt signera något med de sparade nycklarna. Det finns ingenting som hindrar skadlig kod att kopiera kakorna och använda TPM-signeringen när webbapplikationen begär det.

Detta är dock en fullt rimlig situation då DBSC inte avser helt stoppa cookie-stöld utan snarare göra det svårare att missbruka. DBSC tvingar den skadliga koden (och aktören bakom) att agera direkt på enheten vilket ökar chanserna att antivirus och andra former av skyddsåtgärder kan upptäcka eventuellt missbruk.

Framtiden efter införande av DBSC

Låt oss leka med tanken att DBSC blir en framgång och implementeras brett av samtliga webbläsare. Detta kanske kommer kunna ske tidigast om något eller några år. Därefter behöver applikationer och tjänster implementera möjligheten att utnyttja DBSC vilket i princip innebär att diverse webbapplikationsramverk behöver uppdateras för att implementera stöd för detta. Men låt oss anta att det händer.

Vad har vi uppnått och vad gör angriparna som svar?

Först och främst bör vi ha lyckats med att skydda användare från kapning av sessionskakor vilket tillsammans med Passkeys bör ge oss ett tämligen bra skydd från att angripare kan stjäla våra inloggningsuppgifter och sessionskakor.

Det blir självklart då lite intressant att spekulera i vad angriparna kommer göra som svar på detta. Om vi utgår ifrån att angripare inte längre kommer kunna stjäla cookies eller credentials kommer de att istället behöva leva direkt i den kapade datorn och förlita sig mer på sårbarheter i applikationer och system.

Jag tror att angripare kommer fokusera på att bygga mindre och mer modulära remote access trojans (RATs). Dessa kommer att kommunicera med C2-servrar som finns på populära molntjänster som Azure, AWS och GCP, eller kommunikationssystem som Telegram.

Detta innebär således att vi som försvarare kommer behöva bli bättre på att identifiera avvikande nätverksanrop från klienter.

Referenser