Device code phishing działa, ponieważ ofiara loguje się na prawdziwej stronie Microsoft. Nie ma więc fałszywego formularza logowania, który można rozpoznać, ani domeny łudząco podobnej do oryginału, którą można zablokować. Praktyczna obrona to wyłączenie tego flow dla wszystkich, którzy go nie potrzebują. Zalecenie samego Microsoft brzmi: zbliż się jak najbardziej do jednostronnej blokady device code flow, a jedna polityka Conditional Access to załatwia.
Do czego służy device code flow
Flow powstał z myślą o urządzeniach bez przeglądarki lub takich, na których trudno cokolwiek wpisywać. RFC 8628 wymienia smart TV, konsole multimedialne, ramki na zdjęcia i drukarki. Urządzenie nie wyświetla strony logowania. Prosi użytkownika, aby na innym urządzeniu, na przykład telefonie, wszedł pod wskazany adres URL i wpisał krótki kod.
Klient wysyła do serwera autoryzacji swój identyfikator i dostaje w odpowiedzi device_code, user_code, verification_uri oraz wartość expires_in. Gdy użytkownik loguje się na drugim urządzeniu, klient odpytuje endpoint tokenów z użyciem device_code, aż otrzyma access token, błąd albo polecenie dalszego oczekiwania.
W Microsoft identity platform endpointy to /devicecode i /token. Dokumentacja Microsoft domyślnie daje użytkownikowi 15 minut na zalogowanie, a refresh token jest wydawany, jeśli żądany zakres obejmował offline_access.
Dlaczego to działa jako phishing
Kod żąda klient. Loguje się natomiast ten, kto ten kod posiada. Protokół nie wymaga, by była to ta sama osoba, a RFC 8628 wymienia "Remote Phishing" wśród zagrożeń bezpieczeństwa (sekcja 5.4).
Atakujący może więc wcielić się w urządzenie. Żąda kodu, podając client_id (oraz scope, którego endpoint Microsoft wymaga), a następnie wysyła user_code celowi, dodając wiarygodny pretekst. Cel otwiera prawdziwą stronę weryfikacji, loguje się i wpisuje kod. Klient atakującego, który cały czas odpytuje endpoint, odbiera tokeny.
Hasło nigdy nie trafia na stronę kontrolowaną przez atakującego. Dlatego mechanizmy oparte na domenach i adresach URL, takie jak nasz sprawdzacz linków, nie mają tu czego oznaczyć.
Atakujący nadal jest jednak zależny od ofiary. Cel musi zalogować się i wpisać kod, zanim upłynie expires_in (domyślnie 15 minut), inaczej odpytywanie zakończy się błędem expired_token. Użytkownicy kont osobistych są ponadto proszeni o ponowne zalogowanie i zgodę na żądane uprawnienia.
Jest jedna wskazówka przydatna w szkoleniach. Microsoft nie obsługuje verification_uri_complete, czyli opcjonalnego pola, które przenosi kod w samym adresie URL. Wzorzec, którego warto uczyć, brzmi: "ktoś przysłał mi kod do wpisania na stronie logowania Microsoft".
Wykrywanie logowań z użyciem device code
Microsoft zaleca politykę, która audytuje dotychczasowe użycie flow, a tryb report-only daje dokładnie to. Utwórz opisaną niżej politykę w trybie Report-only i przejrzyj wyniki policy impact, aby zobaczyć, kto i co zostałoby zablokowane.
Do bieżącego threat huntingu przefiltruj logi logowań Entra pod kątem logowań z device code i pogrupuj je według użytkownika oraz aplikacji. To wskazówka praktyków, dokumenty Microsoft cytowane tutaj jej nie opisują. Logowanie użytkownika, który nie ma żadnego urządzenia ani narzędzia korzystającego z tego flow, albo logowanie z aplikacji, której nikt nie potrafi nazwać, wymaga rozmowy. Zapytaj użytkownika, jaką wiadomość otrzymał.
Blokada flow za pomocą Conditional Access
Ścieżkę klikania opisuje wytyczne Microsoft dotyczące Conditional Access. Zaloguj się jako co najmniej Conditional Access Administrator, przejdź do Entra ID > Conditional Access > Policies i utwórz nową politykę. Uwzględnij wszystkich użytkowników i All resources. W sekcji Conditions > Authentication Flows ustaw Configure na Yes i wybierz Device code flow. W sekcji Grant wybierz Block access, a Enable policy ustaw na Report-only. Przełącz na On po przejrzeniu wyników.
Ta sama strona omawia także blokowanie authentication transfer, które pozwala użytkownikom przenieść logowanie z komputera na urządzenie mobilne. Używa tego samego warunku Authentication Flows, więc zdecyduj o nim przy okazji.
Microsoft radzi dopuszczać to flow tylko w dobrze udokumentowanych i zabezpieczonych przypadkach użycia, jak starsze narzędzia, których nie da się zaktualizować.
Dla tego, co musi zostać, utwórz dedykowaną grupę wyjątków z nazwą mówiącą, do czego służy. Zapisz właściciela i powód dla każdego członka oraz regularnie audytuj listę, jak radzi Microsoft. Pozostaw też wykluczone konta awaryjne (break-glass), aby uniknąć blokady dostępu w razie błędnej konfiguracji polityki.
Osobno Microsoft zwraca uwagę, że wywołania wykonywane przez service principals nie są blokowane przez polityki przypisane do użytkowników, i sugeruje zastąpienie kont usługowych używanych w skryptach lub kodzie przez managed identities.
Jeśli phishing z kodem już się udał
Załóż, że atakujący ma tokeny, a nie tylko hasło. Refresh token pozwala uzyskiwać nowe access tokeny, więc najpierw unieważnij sesje użytkownika, a dopiero potem zresetuj hasło. To wskazówka praktyków, nie pochodzi z powyższych źródeł.
Następnie przejrzyj aplikacje enterprise i udzielone zgody (consent grants) powiązane z kontem i usuń wszystkie, których nie rozpoznajesz. Sprawdź skrzynkę pocztową pod kątem reguł, których nie utworzył użytkownik, zwłaszcza reguł przekierowania lub usuwania.
Rozszerz poszukiwania poza jednego użytkownika: uruchom opisany wyżej filtr device code dla innych kont i szukaj tej samej aplikacji. Jeśli zagrożone może być więcej niż jedno konto, skorzystaj z właściwego procesu reagowania. Nasz zespół reagowania na incydenty poprowadzi go razem z Tobą, a nasz blog zawiera materiały o reagowaniu na incydenty i phishingu, przydatne w szkoleniach.
Od czego zacząć
- Wypisz każde urządzenie, skrypt i narzędzie, które może logować się za pomocą kodu: drukarki, telewizory, urządzenia IoT, narzędzia wiersza poleceń. Zapytaj każdego właściciela, czy tak robi.
- Utwórz politykę Conditional Access z wybranym Device code flow, wszystkimi użytkownikami w zakresie i wykluczonymi kontami break-glass, w trybie Report-only. Jednocześnie zdecyduj o warunku authentication transfer.
- Przejrzyj wyniki report-only oraz logowania z device code w logach. Napraw lub wycofaj każde legalne użycie, a to, co zostanie, umieść w nazwanej grupie wyjątków z przypisanym właścicielem.
- Przełącz politykę na On i wpisz audyt grupy wyjątków do kalendarza.
- Spisz kroki reakcji (unieważnienie sesji, przegląd aplikacji enterprise i consent grants, sprawdzenie reguł skrzynki). Poinformuj pracowników, że kod, o który sami nie poprosili, pochodzący z urządzenia, którego nie trzymają w ręku, to próba phishingu.
