MFA fatigue. Gdy powiadomienia push stają się wektorem ataku
Dwuskładnikowe uwierzytelnianie miało być tarczą. W wariancie push bywa też przyciskiem, który da się zbombardować. Atakujący zna hasło albo sesję startową. Serwis wysyła na telefon ofiary prośbę „zatwierdź logowanie”. Prośba wraca. I wraca. W nocy, w pracy, przy obiedzie. W końcu ktoś klika „tak”, żeby hałas ustał, albo bo myśli, że to glitch. To jest MFA fatigue: zmęczenie uwierzytelnianiem jako wektor, nie jako metafora wypalenia zawodowego.
Playbooka ataku tu nie rozpisuję. Opisuję mechanikę znaną z publicznych raportów i z jednego z głośniejszych przypadków korporacyjnych: incydentu w Uberze we wrześniu 2022.
Co się stało w publicznym case Uber
We wrześniu 2022 Uber poinformował o naruszeniu bezpieczeństwa. W późniejszych relacjach i w materiałach branżowych powtarzał się schemat: atakujący zdobył dostęp do konta pracownika, wykorzystał społeczny nacisk i lawinę powiadomień MFA, a następnie poruszał się po wewnętrznych narzędziach. Uber opisał sprawę w oficjalnych komunikatach. Szczegóły taktyczne różnią się między relacjami medialnymi a raportami firm security. Sens dla użytkownika MFA jest prosty: sam fakt posiadania push 2FA nie zatrzymuje kogoś, kto już ma hasło i cierpliwość, by klikać „wyślij ponownie”, aż ofiara się ugnie.
Podobne wzorce opisywano wcześniej i później przy innych celach. Uber nie wymyślił fatigue. Uczynił go zrozumiałym dla ludzi spoza red teamów.
Dlaczego lawina działa
Push MFA jest wygodny. Nie przepisujesz kodu. Dostajesz dzwonek i dwa przyciski. Mózg uczy się, że to rutyna. Atak zamienia rutynę w irytację. Irytacja obniża czujność. Dochodzi kontekst: „może to IT”, „może to ja na innym urządzeniu”, „może przestanie, jak zatwierdzę”. Socjotechnika często idzie równolegle: wiadomość od „helpdesku”, która tłumaczy powiadomienia i prosi o akceptację. Przykładowych skryptów nie cytuję. Wystarczy wiedzieć, że hałas techniczny i nacisk ludzki wzmacniają się nawzajem.
Cel nie musi być CEO. Wystarczy konto z dostępem do VPN, do panelu administracyjnego albo do poczty, która otwiera resztę firmy.
Number matching i inne tarcia
Odpowiedzią dostawców tożsamości stało się m.in. number matching: na ekranie logowania pojawia się liczba, którą trzeba wpisać albo wybrać w aplikacji uwierzytelniającej. Samo kliknięcie „Approve” bez odczytania liczby nie wystarcza. Ataku to nie eliminuje całkowicie. Podnosi poprzeczkę: ofiara musi świadomie przepisać coś z ekranu, którego atakujący nie kontroluje w tym samym stopniu co samo hasło.
Microsoft i inni dostawcy IdP opisywali number matching jako odpowiedź na fatigue właśnie po fali takich incydentów. To nie marketingowa nowinka bez kontekstu. To zmiana UX wymuszona rzeczywistością ataków.
Inne tarcia: ograniczenie liczby pushy w jednostce czasu, alerty o nietypowej liczbie prób, wymuszenie silniejszego czynnika (klucz sprzętowy, passkey) na kontach uprzywilejowanych, zakaz zwykłego push dla VPN adminów.
Dla kont osobistych: jeśli dostajesz serię próśb o zatwierdzenie, których nie inicjowałeś, nie klikaj „tak”. Odrzuć, zmień hasło z zaufanego urządzenia, sprawdź sesje, włącz silniejszy czynnik jeśli jest. Hałas jest sygnałem, nie tłem do wyciszenia akceptacją.
Hasło nadal jest częścią układanki
MFA fatigue zwykle zakłada, że pierwszy czynnik już padł: wyciek, phishing, reuse hasła, malware. Obrona zaczyna się wcześniej: menedżer haseł, unikalne hasła, odporność na phishing (passkeys, klucze). MFA ma być drugą linią, nie jedyną. Gdy druga linia jest tylko przyciskiem „OK”, atakujący optymalizuje pod psychologię, nie pod kryptografię.
Porównaj to z kradzieżą sesji: tam omija się MFA po fakcie. Tu próbuje się wymusić akceptację MFA w trakcie. Oba scenariusze uczą, że „mam dwuskładnikowe” to początek zdania, nie koniec.
Co robić w organizacji
Kontom adminów i VPN nie wystarczy domyślny push. Polityka tożsamości powinna wymagać silniejszego czynnika, limitować powtórzenia challenge i uczyć ludzi, że seria nieproszonych powiadomień to incydent, nie „zrestartuj aplikację zatwierdzeniem”. Helpdesk musi mieć procedurę, która nie prosi o akceptację MFA „żeby sprawdzić, czy działa”.
Szkolenie bez zmiany konfiguracji IdP jest ozdobą. Konfiguracja bez szkolenia też: ktoś i tak kliknie w nocy. Potrzebne są obie warstwy.
Zmęczenie jako funkcja, nie bug
Projektanci wybrali push, bo redukuje tarcie. Atakujący wybrali fatigue, bo tarcie wraca jako irytacja ofiary. Dobry system tożsamości dodaje tarcia po stronie ataku (number matching, limity, klucze), a nie po stronie codziennego użytkownika w sposób, który uczy klikać bez czytania.
Publiczny case Ubera z 2022 nie jest jedynym. Jest wystarczająco dobrze udokumentowany, żeby nie udawać, że to teoria z konferencji. Kiedy firma pisze o naruszeniu, a branża dokłada opis fatigue, użytkownik domowy dostaje prostą regułę: nie zatwierdzaj tego, czego nie zacząłeś.
Ja na kontach, na których stoi praca albo kasa, wolę czynnik, którego nie zatwierdzę przez senny kciuk. Push zostawiam tam, gdzie konsekwencja pomyłki jest mała. To budżet ryzyka, nie estetyka.