Device code flow: waakzaamheid is geboden

In deze blog gaan we verder in op wat de device code flow is en met name wat het zo risicovol maakt.

Achtergrond: hoe werkt de device code flow?

Bij federatieve authenticatie draait het erom dat een applicatie een gebruiker vraagt om in te loggen en daarvoor doorstuurt naar diens eigen Identity Provider. Na succesvolle authenticatie komt de gebruiker terug bij de applicatie met een access token waarmee de applicatie namens de gebruiker toegang heeft tot de applicatie. Dit werkt uitstekend voor applicaties die je in een webbrowser op je eigen computer of telefoon benadert, maar niet zo goed voor apparaten zonder uitgebreide (invoer)interface.

Omdat in bijvoorbeeld een VR-bril de gebruiker niet handig een gebruikersnaam of wachtwoord kan invoeren op een webbrowser, is hiervoor de device code flow (ook bekend als Device Authorization Grant) bedacht. Het apparaat start de inlogprocedure door een verzoek te doen naar de authenticatieserver en krijgt een code terug van een aantal letters en cijfers. Deze toont het apparaat aan de gebruiker. De gebruiker gaat vervolgens in diens eigen webbrowser naar een locatie waar hij ter bevestiging van het juiste apparaat de code invoert, en inlogt om vrijgave van zijn gegevens te bevestigen. De authenticatieserver verstrekt vervolgens direct aan het apparaat het benodigde access token waarna het apparaat geautoriseerd is om namens de gebruiker gegevens op te vragen.

Veel authenticatieplatformen ondersteunden deze flow, die is opgenomen in de OAuth2-standaard. Zoals Microsoft, zodat je bijvoorbeeld kunt inloggen op een videoconferencingsysteem. Maar ook sommige applicaties aangesloten op SURFconext en SURF Research Access Management kunnen gebruik maken van deze methode.

Wat maakt dit nu zo risicovol?

De aanval die in het nieuws was hanteerde de volgende modus operandi. De aanvaller start een login op een applicatie die gebruik maakt van de device code flow en krijgt van Microsoft een code. De gebruiker die het doelwit is van de phishing wordt benaderd met het verzoek deel te nemen aan een vergadering. Hij krijgt hierbij iets wat lijkt op een Teams vergaderuitnodiging met een "vergadercode", wat feitelijk de device code is. Als de gebruiker op de vergaderlink klikt, gaat die niet naar Teams maar naar de link om een device code in te voeren, en wordt gestimuleerd om hierin de "vergadercode" in te voeren - iets wat niet heel raar is om te doen. Hiermee stapt hij dus echter niet een vergadering binnen, maar autoriseert hij feitelijk de aanvragende applicatie voor toegang tot diens account. Daarna wordt de hiermee verkregen access token gebruikt om handelingen namens de gebruiker uit te voeren.

Het enige wat de aanvaller dus hoeft te doen is de gebruiker te overtuigen een gegeven code in te voeren op een legitieme URL. Concreet is dit risicovoller dan andere methoden vanwege de volgende redenen:

• De gebruiker hoeft alleen naar vertrouwde URLs te navigeren. Legitieme URLs van bijvoorbeeld Microsoft, in het voorbeeld. Het is dus heel lastig te detecteren dat het niet in de haak is.
• Het is voor gebruikers lastig te herkennen dat ze een ongewenste actie aan het uitvoeren zijn. Ze worden geregeld al gevraagd codes over te nemen in een webformulier.
• De gebruiker is gewoonlijk al ingelogd op diens eigen vertrouwde device in een bekende browser. Er is single sign on, en MFA en de meeste vormen van conditional access bieden verder geen bescherming.
• De via de code geautoriseerde applicatie kan zich vervolgens echter overal ter wereld bevinden.

Wat kan je er tegen doen?

Uiteindelijk moeten gebruikers kunnen begrijpen wat ze exact aan het doen zijn, en waartoe ze exact op dat moment mee instemmen. Het is dus zaak dat implementaties van de device code flow er alles aan doen om inzichtelijk te maken wat er gebeurt en waar iemand mee instemt. En gebruikers moeten zich ervan bewust zijn dat ze bij twijfel geen toestemming geven. De codes zijn korte tijd geldig, dus een bekend awareness-advies om terughoudend te zijn als een tegenpartij druk uitoefent dat iets "snel" moet gebeuren, is hier dus ook nuttig.

Als beheerder van een identity management systeem kun je device code flow uitschakelen als je zeker weet dat dit niet nodig is voor je organisatie. Bijvoorbeeld in Entra ID kun je authenticaties via method = "device code" opvragen om te zien of er gebruik van gemaakt wordt. Je kunt het indien mogelijk daarna uitschakelen met een conditional access policy, of het alleen toestaan voor een netwerksegment waarin de apparaten zich bevinden die er gebruik van moeten maken.

Diensten die nu de device code flow inzetten moeten zich bewust zijn van de risico's, en alternatieven verkennen.

Wat doet SURF?

SURFconext en SURF Research Access Management ondersteunen de flow, maar schakelen die alleen in voor heel specifieke diensten. Ze zijn daar vanwege de risico's selectief in en doen dat alleen als er geen alternatieven zijn. Dat maakt dat de aanval niet zonder meer ingezet kan worden. Voor bijvoorbeeld inloggen middels SSH op onderzoekssystemen heeft SRAM een eigen methode ontwikkeld die minder phishing-gevoelig is.

Naar aanleiding van de actualiteit hebben beide SURF-diensten hun schermen van de device code flow nogmaals kritisch bekeken en gaan ze hier verdere verbeteringen in doorvoeren. Dit zodat voor gebruikers zo duidelijk mogelijk is waar ze exact mee instemmen, ze niet onnodig ontmoedigd worden om voor "afwijzen" te kiezen, en daarmee ze de juiste afweging maken als ze met een device code-scherm geconfronteerd worden.

Deze blog kwam tot stand in samenwerking met Bas Zoetekouw (SURFconext) en Bart Geesink (SURF Developer Platform).