Când discutăm despre atacuri la adresa identității digitale, compararea modului în care doi uriași tehnologici implementează același mecanism poate fi la fel de instructivă precum o lecție de istorie: același principiu, consecințe foarte diferite. Azi examinăm cum este utilizat, corect sau abuziv, fluxul Device Code din OAuth 2.0 la Microsoft și Google și ce implică asta pentru riscul de phishing și securitatea organizațiilor.
Fluxul Device Code a fost creat pentru dispozitive conectate la internet care nu dispun de o interfață obișnuită pentru introducerea datelor: televizoare smart, imprimante IoT sau alte gadgeturi fără browser sau tastatură. Procedura e simplă: dispozitivul obține un cod, utilizatorul accesează un browser pe alt dispozitiv, introduce codul și se autentifică, iar dispozitivul primește un token de acces. Funcțional este foarte util pentru scenarii legitime, imaginați-vă un smart TV care vrea acces la contul de streaming, dar, ca multe funcții de securitate, poate fi deturnat prin inginerie socială pentru a servi atacurilor.
Phishing-ul prin Device Code transformă această funcționalitate: un atacator solicită de la furnizor un device code, trimite victimei o înșelătorie convingătoare pentru a introduce codul pe pagina legitimă de autentificare, iar în timp ce victima își validează identitatea (inclusiv MFA), atacatorul interoghează API-ul și obține token-urile generate. Practic, atacul folosește API-urile și paginile oficiale ale furnizorului, nu site-uri malițioase, ceea ce îl face greu de detectat chiar și pentru utilizatorii atenți la linkuri suspecte: https://microsoft.com/devicelogin este un URL complet legitim, dar poate fi folosit în înșelătorie.
La Microsoft Azure, situația este ilustrativă și, din păcate, periculoasă. Atacatorul poate specifica în cererea inițială client_id și resource, parametri care determină exact ce tip de token se va genera. Azure dispune de un set de client IDs denumit Family of Client IDs, care include identificatori publicați și care pot genera token-uri cu privilegii ridicate. Practic, asta înseamnă că un device code phishing bine pus la punct poate conduce la obținerea unui refresh token principal sau a altor token-uri puternice care permit citirea emailurilor, acces la calendar, fișiere, înregistrarea de dispozitive în tenant sau înregistrări MFA, instrumente suficiente pentru a obține acces inițial și a pivota în rețea. Atacul nu valorifică un bug tehnic, ci exploatează un mecanism legitim și încrederea utilizatorului care se autentifică pe o adresă oficială.
Google Cloud abordează lucrurile altfel. Documentația Google indică încă de la început că nu toate scope-urile sunt disponibile pentru device code flow; lista de scope-uri suportate este foarte restrânsă, concentrată în principal pe Google Drive și YouTube. În practică, asta reduce semnificativ suprafața de atac: token-urile generate prin device code în Google nu oferă acces împrăștiat la email, administrare de tenant sau alte resurse critice. Totodată, pentru a folosi un client ID în Google, de regulă trebuie creată o aplicație OAuth, iar permisiunile mai puternice cer publicare și verificare, ceea ce complică obținerea anonimă a unui client exploatabil la scară. În concluzie practică, device code phishing în Google are un impact mult mai restrâns decât în Azure, cel puțin pe baza informațiilor publice disponibile.
Diferențele esențiale: în Azure, atacatorul poate controla resource și client_id în cererea inițială, iar anumite client IDs publice permit generarea de token-uri cu privilegii ridicate; în Google, scope-urile permise pentru device code flow sunt foarte limitate, iar procedurile de publicare/verificare a aplicațiilor reduc posibilitatea abuzului anonim. Aceasta nu înseamnă că Google este imun; pot exista client IDs sau scope-uri nepublicate, dar datele disponibile indică o suprafață de atac mai mică comparativ cu Azure.
Un exemplu concret din practică: cererea curl folosită pentru Azure a solicitat client_id d3590ed6-52b3-4102-aeff-aad2292ab01c și resource https://graph.microsoft.com, iar după autentificare API-ul a returnat un set de token-uri care pot oferi permisiuni extinse (lista de scope-uri din token include, între altele, Mail.ReadWrite, Files.ReadWrite.All, Directory.Read.All). În Google, aceeași abordare generează token-uri cu scope-uri precum https://www.googleapis.com/auth/drive.file sau youtube.readonly, mult mai limitate ca impact.
Acest contrast spune ceva mai amplu despre proiectarea securității: două implementări ale aceluiași standard pot crea riscuri foarte diferite, în funcție de ce scope-uri sau comportamente permit. Microsoft, printr-un design permisiv al device code flow și prin existența unor client IDs recunoscute, a creat involuntar un vector exploatabil la scară. Google a optat pentru o abordare mai restrictivă a acestui flux, orientându-l către scenarii specifice (TV, dispozitive cu input limitat) și reducând astfel potențialul de abuz.
Deciziile de implementare au consecințe practice: echipele de securitate care administrează medii Microsoft ar trebui să considere device code flow un risc real, auditul permisiunilor, monitorizarea cererilor device code, educarea utilizatorilor privind codurile primite și limitarea client IDs necontrolate pot diminua expunerea. În ecosistemul Google, recomandările rămân valabile, dar prioritizarea riscurilor poate fi diferită, având în vedere că device code phishing pare mai puțin capabil să producă takeover-uri complete.
Exemplul concret: client_id d3590ed6-52b3-4102-aeff-aad2292ab01c și resource https://graph.microsoft.com au fost folosite pentru a genera token-uri cu scope-uri extinse în Azure; în schimb, în Google device code flow rămâne limitat la scope-uri precum drive.file sau youtube.readonly. Această discrepanță ilustrează cum același mecanism poate fi fie periculos, fie relativ benign, în funcție de implementare. Cum vă adaptați politicile de securitate în funcție de providerul de identitate?
Fii primul care comentează