MFA fatigue

MFA fatigue (po polsku opisowo „zmęczenie MFA”) to atak na uwierzytelnianie wieloskładnikowe, w którym napastnik znający już hasło ofiary wywołuje serię próśb o zatwierdzenie logowania, aż ofiara jedną z nich zaakceptuje. MITRE ATT&CK opisuje go w technice T1621: powtarzane logowania zasypują użytkownika powiadomieniami push, SMS-ami i połączeniami, dopóki nie zatwierdzi dostępu ^[1]. Atak nie łamie drugiego składnika. Wykorzystuje to, że użytkownik sam może go użyć, przez pomyłkę albo po to, by powiadomienia ustały ^[5].

Jak działa

Punktem wyjścia są prawdziwe dane uwierzytelniające, zdobyte na przykład przez phishing, credential stuffing albo infostealer. Hasło przechodzi, a serwis wysyła powiadomienie do aplikacji uwierzytelniającej na telefonie ofiary. Napastnik ponawia logowanie wiele razy. W najprostszej postaci powiadomienie ma tylko przyciski „Zatwierdź” i „Odrzuć”, więc jedno przypadkowe dotknięcie wystarcza.

RYS. 1Pętla ataku MFA fatigue

Cisco Talos definiuje MFA fatigue jako wysyłanie dużej liczby żądań push na urządzenie celu, dopóki użytkownik ich nie zaakceptuje, przypadkiem albo po to, by uciszyć powtarzające się powiadomienia ^[5]. Presję często wzmacnia rozmowa: vishing, w którym napastnik podaje się za dział IT i obiecuje, że powiadomienia ustaną po zatwierdzeniu ^[6].

Odmiany

MITRE wymienia różne kanały, którymi napastnik może zalewać ofiarę ^[1].

W WordPressie

Drugi składnik w WordPressie dodaje się zwykle wtyczką. Popularna wtyczka Two Factor oferuje kody TOTP z aplikacji, kody wysyłane e-mailem i kody zapasowe ^[7]. Żadna z tych metod nie wysyła powiadomień push do zatwierdzenia jednym dotknięciem ^[7], więc sam panel z taką konfiguracją nie jest typowym celem MFA fatigue. Metody z przepisywaniem kodu mają jednak inną słabość: NIST nie uznaje ich za odporne na phishing ^[3], co wykorzystuje phishing AiTM (adversary-in-the-middle).

MFA fatigue dotyczy za to kont wokół strony. Jeśli administrator loguje się do WordPressa przez SSO z zatwierdzaniem push albo jeśli push chroni skrzynkę, na którą przychodzą linki resetu hasła, zatwierdzenie jednego fałszywego powiadomienia otwiera drogę do panelu. Dlatego przy ocenie ochrony strony warto sprawdzić, jakim drugim składnikiem są chronione poczta administratora, panel hostingu i dostawca tożsamości.

Zagrożenia i skutki

Skutkiem udanego ataku jest pełne przejęcie konta z ważnym drugim składnikiem. W przypadku Cisco napastnik po uzyskaniu dostępu zarejestrował serię nowych urządzeń do MFA i zalogował się do firmowej sieci VPN ^[5]. Talos powiązał sprawcę z brokerem początkowego dostępu związanym z grupami UNC2447, Lapsus$ i operatorami ransomware Yanluowang ^[5].

MITRE wymienia jako grupy stosujące tę technikę między innymi APT29, LAPSUS$ i Scattered Spider ^[1]. Takie wejście często jest pierwszym etapem ataku ransomware. Talos ocenił, że działania w sieci Cisco odpowiadały przygotowaniom do takiego ataku, choć ransomware nie został uruchomiony ^[5].

Jak się bronić

Dopasowanie numeru. CISA zaleca dopasowanie numeru (number matching) jako rozwiązanie przejściowe: użytkownik musi wpisać w aplikacji liczbę widoczną na ekranie logowania ^[2]. Microsoft Authenticator stosuje je we wszystkich powiadomieniach push, także przy samoobsługowym resecie hasła, a użytkownik nie może go wyłączyć ^[4]. CISA podaje dla MFA fatigue drugą nazwę, push bombing, i opisuje je jako zasypywanie użytkownika powiadomieniami, aż zatwierdzi prośbę przypadkiem albo ze zniecierpliwienia ^[2]. Zaznacza też, że dopasowanie numeru jest słabsze od uwierzytelniania odpornego na phishing i pozostaje środkiem przejściowym ^[2]. Zaleca ponadto uczyć użytkowników zgłaszania nieznanych próśb i badać każde odrzucone powiadomienie ^[2]. NIST wymaga, by uwierzytelniacz pozapasmowy zatwierdzający logowanie przyjmował sekret przeniesiony z kanału głównego, co wiąże zatwierdzenie z konkretną transakcją ^[3].

Uwierzytelnianie odporne na phishing. CISA zachęca wszystkie organizacje do wdrożenia uwierzytelniania odpornego na phishing ^[2]. NIST zalicza do niego metody wiążące wynik z nazwą weryfikatora ^[3], czyli w praktyce FIDO2 / WebAuthn. NIST dla najwyższego poziomu wymaga potwierdzenia zamiaru uwierzytelnienia ^[3]. Na co dzień taką ochronę zapewnia passkey.

Ograniczenia i reguły. MITRE zaleca ograniczenie liczby próśb MFA w danym czasie, zastąpienie prostego push wpisywaniem kodu albo tokenem sprzętowym oraz blokowanie logowań z podejrzanych lokalizacji w ramach dostępu warunkowego ^[1].

Użytkownicy. Nieoczekiwane powiadomienie oznacza, że ktoś zna hasło. MITRE zaleca szkolić użytkowników, by sprawdzali źródło logowania i zgłaszali podejrzane prośby MFA ^[1]. Właściwą reakcją jest odrzucenie, zgłoszenie i zmiana hasła.

Historia i przykłady

• Maj 2022, Cisco. 24 maja firma dowiedziała się o możliwym włamaniu; napastnik połączył vishing z MFA fatigue ^[5]. Talos opisał sprawę 10 sierpnia 2022 roku ^[5].
• Wrzesień 2022, Uber. Według Sekuraka napastnik przez ponad godzinę zasypywał pracownika powiadomieniami push, a potem napisał do niego na WhatsAppie jako członek zespołu IT ^[6].