TrustSink: jak złośliwy zewnętrzny dostawca MFA może kraść hasła podczas logowania

securitybeztabu.pl 16 godzin temu

Wprowadzenie do problemu / definicja

Mechanizmy uwierzytelniania wieloskładnikowego od lat są przedstawiane jako skuteczna ochrona przed przejęciem kont po wycieku hasła. Najnowsze badania pokazują jednak, iż bezpieczeństwo MFA zależy nie tylko od obecności drugiego składnika, ale również od integralności całego łańcucha zaufania. Technika TrustSink dowodzi, iż w określonych warunkach zewnętrzny dostawca MFA może zostać wykorzystany do przechwytywania haseł w trakcie prawidłowo wyglądającego procesu logowania.

Problem dotyczy środowisk, w których organizacja dopuszcza integrację zewnętrznych metod uwierzytelniania, a napastnik wcześniej uzyskał wysoki poziom uprawnień administracyjnych. W takim scenariuszu legalny mechanizm bezpieczeństwa może zostać przekształcony w narzędzie do cichej kradzieży poświadczeń.

W skrócie

TrustSink to technika nadużywająca relacji zaufania pomiędzy platformą tożsamościową a zewnętrznym dostawcą MFA. Użytkownik najpierw wpisuje poprawne hasło na prawdziwej stronie logowania, a następnie zostaje przekierowany do etapu drugiego składnika.

Zamiast standardowego potwierdzenia MFA ofiara widzi jednak fałszywy ekran proszący o ponowne podanie hasła. Dane trafiają do infrastruktury kontrolowanej przez atakującego, po czym proces logowania kończy się sukcesem. Dzięki temu incydent może pozostać niewidoczny zarówno dla użytkownika, jak i dla części mechanizmów monitorujących.

atak nie służy do uzyskania dostępu początkowego, ale jest techniką post-compromise,
wymaga przejęcia konta z wysokimi uprawnieniami administracyjnymi,
umożliwia przechwytywanie haseł bez klasycznego phishingu poza środowiskiem organizacji,
może działać także po zmianie haseł, jeżeli złośliwa konfiguracja nie zostanie usunięta.

Kontekst / historia

Badacze zademonstrowali tę technikę na platformie Microsoft Entra z użyciem modelu External Authentication Method. Rozwiązanie to pozwala organizacjom integrować zewnętrznych dostawców MFA z procesem logowania, co w normalnych warunkach zwiększa elastyczność wdrożeń i umożliwia dopasowanie uwierzytelniania do potrzeb biznesowych.

Z perspektywy bezpieczeństwa najważniejsze jest jednak to, iż platforma ufa odpowiednio skonfigurowanemu dostawcy zewnętrznemu i akceptuje podpisany token potwierdzający spełnienie wymogu MFA. TrustSink wykorzystuje właśnie ten model zaufania. Po przejęciu uprzywilejowanego konta napastnik może zmodyfikować polityki uwierzytelniania, zarejestrować złośliwą aplikację i włączyć ją do ścieżki logowania wybranych użytkowników.

To oznacza, iż zagrożenie jest szczególnie istotne dla organizacji, które już padły ofiarą kompromitacji kont administracyjnych lub nie mają wystarczającej kontroli nad zmianami w warstwie IAM.

Analiza techniczna

Rdzeniem ataku jest podstawienie złośliwego zewnętrznego dostawcy MFA w miejsce elementu, któremu platforma tożsamościowa ufa jako części legalnego procesu logowania. Użytkownik przechodzi pierwszy etap logowania i podaje poprawne hasło na prawdziwej stronie dostawcy tożsamości. Następnie polityka dostępu wymusza przejście do etapu MFA.

W prawidłowym scenariuszu zewnętrzny dostawca powinien obsłużyć drugi składnik, na przykład potwierdzenie w aplikacji, kod lub inne zabezpieczenie. W wariancie złośliwym użytkownik otrzymuje ekran łudząco podobny do firmowego formularza logowania i zostaje poproszony o ponowne wpisanie hasła. Ponieważ dzieje się to w obrębie legalnie wyglądającej ścieżki uwierzytelniania, ofiara może uznać taki krok za normalny element procedury bezpieczeństwa.

Hasło wprowadzone po raz drugi trafia w postaci jawnej do serwera napastnika. Następnie złośliwy komponent zwraca poprawnie podpisaną odpowiedź wskazującą, iż MFA zakończyło się powodzeniem. System akceptuje wynik, a użytkownik uzyskuje dostęp do aplikacji bez widocznych oznak oszustwa.

Taki model działania utrudnia wykrywanie, ponieważ nie dochodzi do przerwania sesji, błędu logowania ani nietypowego komunikatu. Co więcej, jeżeli złośliwy dostawca pozostaje aktywny w polityce tenantu, może dalej przechwytywać nowe hasła także po ich zmianie. Sama rotacja poświadczeń nie rozwiązuje więc problemu, jeżeli nie usunięto przyczyny na poziomie konfiguracji.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest możliwość cichej kradzieży haseł wielu użytkowników bez prowadzenia tradycyjnej kampanii phishingowej. Atak odbywa się wewnątrz zaufanego procesu logowania, co znacząco podnosi jego wiarygodność i obniża szansę, iż ofiary zgłoszą incydent.

Ryzyko dotyczy również trwałości kompromitacji. o ile organizacja zareaguje wyłącznie resetem haseł, ale nie usunie złośliwego dostawcy MFA oraz powiązanych artefaktów konfiguracyjnych, nowe dane logowania mogą zostać ponownie przechwycone przy kolejnych sesjach. W praktyce prowadzi to do powtarzających się naruszeń i fałszywego przekonania, iż rotacja poświadczeń była nieskuteczna.

W środowiskach korporacyjnych skutki mogą obejmować ruch boczny, przejęcie skrzynek pocztowych, dostęp do aplikacji SaaS, eskalację incydentu oraz długotrwałą obecność napastnika w infrastrukturze tożsamościowej. TrustSink podważa też uproszczone założenie, iż samo wdrożenie MFA automatycznie gwarantuje bezpieczeństwo kont.

Rekomendacje

Organizacje korzystające z zewnętrznych dostawców MFA powinny przeprowadzić szczegółowy przegląd wszystkich skonfigurowanych metod zewnętrznych, aplikacji, certyfikatów, kluczy oraz adresów przekierowań. Każdy nieznany lub nieuzasadniony wpis należy potraktować jako potencjalny wskaźnik kompromitacji.

Kluczowe znaczenie ma również monitorowanie zmian w politykach metod uwierzytelniania, rejestracjach aplikacji, zgodach administracyjnych oraz przypisaniach ról uprzywilejowanych. Z punktu widzenia zespołów bezpieczeństwa warto powiązać telemetrię z platformy tożsamościowej z logami aplikacyjnymi i zdarzeniami audytowymi, aby szybciej identyfikować nietypowe modyfikacje.

ogranicz stałe uprawnienia administracyjne i wdrażaj model least privilege,
stosuj mechanizmy just-in-time dla ról wysokiego ryzyka,
alertuj zmiany dotyczące External Authentication Method i nowych service principal,
w przypadku incydentu najpierw usuń złośliwego dostawcę MFA, a dopiero później resetuj hasła użytkowników,
promuj metody odporne na phishing, takie jak FIDO2 i Windows Hello for Business.

Szczególnie ważna jest adekwatna kolejność działań po wykryciu incydentu. o ile najpierw nastąpi reset haseł, a złośliwa integracja pozostanie aktywna, napastnik może natychmiast przechwycić nowe poświadczenia i utrzymać dostęp.

Podsumowanie

TrustSink pokazuje, iż bezpieczeństwo MFA zależy od zaufania do całego procesu uwierzytelniania, a nie jedynie od obecności dodatkowego składnika. jeżeli przeciwnik zdobędzie wysokie uprawnienia administracyjne, może przekształcić legalną integrację zewnętrzną w trwały mechanizm przechwytywania haseł.

Dla organizacji oznacza to konieczność ścisłego nadzoru nad warstwą IAM, rejestracjami aplikacji i politykami uwierzytelniania. Najważniejsze działania obronne to ochrona kont uprzywilejowanych, monitoring zmian administracyjnych oraz usuwanie złośliwych dostawców MFA przed rozpoczęciem rotacji poświadczeń.