Sponsored

Omijanie 2FA/MFA/OTP

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Przejrzyj pełny katalog HackTricks Training.

Wesprzyj HackTricks

Zaawansowane techniki omijania uwierzytelniania dwuskładnikowego

Bezpośredni dostęp do endpointu

Zobacz Proxmox VE, aby zapoznać się z przykładem specyficznym dla produktu, dotyczącym stanu TFA wybieranego przez klienta.

Spróbuj bezpośrednio wywołać endpoint dostępny po zalogowaniu i sprawdź, czy serwer — a nie tylko interfejs użytkownika — wymaga ukończenia procesu MFA. Jeśli aplikacja nieprawidłowo ufa metadanym nawigacji, sprawdź też poprawnie zapisaną nazwę nagłówka HTTP Referer; bezpieczna implementacja nie może używać go jako dowodu przejścia MFA.[2][5]

Ponowne użycie tokenu

Ponowne użycie wcześniej wykorzystanych tokenów do uwierzytelniania na koncie może być skuteczne.[2]

Użycie niewykorzystanych tokenów

Sprawdź, czy niewykorzystany token wygenerowany dla własnego konta testowego jest nieprawidłowo akceptowany dla innego autoryzowanego konta testowego. Pozwala to sprawdzić, czy OTP jest powiązany z właściwym kontem, sesją, przeznaczeniem i transakcją.[2][5]

Ujawnienie tokenu

Sprawdź, czy token nie jest ujawniany w odpowiedzi aplikacji webowej.[2]

Wykorzystanie linku weryfikacyjnego

Użycie linku weryfikacyjnego wysłanego e-mailem podczas tworzenia konta może umożliwić dostęp do profilu bez 2FA, jak opisano w szczegółowym poście.[3]

Manipulacja sesją

Rozpocznij sesje dla dwóch autoryzowanych kont testowych, ukończ MFA w jednej z nich i sprawdź, czy stanu ukończenia MFA nie można przenieść do drugiej sesji. Backend musi powiązać wynik MFA z tym samym kontem i sesją sprzed uwierzytelnienia.[5]

Mechanizm resetowania hasła

Warto sprawdzić, czy funkcja resetowania hasła, która po resecie loguje użytkownika do aplikacji, pozwala wielokrotnie użyć tego samego linku. Zalogowanie się przy użyciu nowo ustawionych danych uwierzytelniających może ominąć 2FA.[2]

Przejęcie platformy OAuth

Sprawdź, czy federacyjna ścieżka logowania OAuth/OIDC wymaga poziomu wiarygodności równoważnego ścieżce logowania hasłem i MFA w aplikacji. Kontrola nad zewnętrznym kontem tożsamości może ominąć lokalne MFA aplikacji tylko wtedy, gdy strona ufająca akceptuje słabszą sesję federacyjną.[5]

Brute Force

Brak limitu szybkości

Brak limitu liczby prób wpisania kodu umożliwia ataki Brute Force, choć należy uwzględnić możliwość cichego ograniczania liczby prób.[1][2]

Pamiętaj, że nawet jeśli limit szybkości jest włączony, warto sprawdzić, czy odpowiedź różni się po przesłaniu prawidłowego OTP. W tym poście łowca błędów odkrył, że mimo uruchomienia limitu szybkości po 20 nieudanych próbach i zwracania odpowiedzi 401, po przesłaniu prawidłowego kodu otrzymał odpowiedź 200.[4]

Powolny Brute Force

Powolny atak Brute Force jest możliwy, gdy limity szybkości dotyczą poszczególnych przepływów, ale nie ma ogólnego limitu szybkości.[1]

Reset limitu ponownego wysyłania kodu

Ponowne wysłanie kodu resetuje limit szybkości, umożliwiając kontynuowanie prób Brute Force.[1]

Omijanie limitu szybkości po stronie klienta

Jeśli ograniczanie liczby prób jest zaimplementowane wyłącznie w JavaScript, odtwórz żądanie bezpośrednio i sprawdź, czy serwer niezależnie egzekwuje limity dla konta, sesji oraz ogólne limity zapobiegające nadużyciom.[1][5]

Brak limitu szybkości dla działań wewnętrznych

Limity szybkości mogą chronić próby logowania, ale nie wewnętrzne działania na koncie.[1]

Koszty ponownego wysyłania kodów SMS

Nadmierne ponawianie wysyłki kodów SMS generuje koszty dla firmy, ale nie omija 2FA.

Nieograniczone generowanie OTP

Nieograniczone generowanie OTP z prostymi kodami umożliwia Brute Force poprzez ponawianie prób z niewielkim zestawem kodów.[1]

Wykorzystanie Race Condition

Wyślij równocześnie ten sam OTP lub kod odzyskiwania i sprawdź, czy jego weryfikacja i zużycie są atomowe. Race Condition występuje, jeśli więcej niż jedno żądanie może wykorzystać tę samą wartość jednorazową.[5]

Luki CSRF/Clickjacking

Badanie luk CSRF lub Clickjacking, które pozwalają wyłączyć 2FA, jest skuteczną strategią.[1][2]

Wykorzystanie funkcji “Remember Me”

Zgadnięcie wartości cookie “remember me” może ominąć zabezpieczenia.[1]

Podszywanie się pod adres IP

Podszywanie się pod adres IP ofiary za pomocą nagłówka X-Forwarded-For może ominąć zabezpieczenia.[1]

Użycie starszych wersji

Subdomeny

Sprawdź, czy subdomeny udostępniają starsze aplikacje lub ścieżki uwierzytelniania, w których nie obowiązuje obecny wymóg MFA.[1]

Endpointy API

Starsze wersje API, wskazywane przez ścieżki katalogów /v*/, mogą być podatne na metody omijania 2FA.[1]

Obsługa wcześniejszych sesji

Kończenie istniejących sesji po włączeniu 2FA chroni konta przed nieautoryzowanym dostępem z przejętych sesji.[1]

Błędy kontroli dostępu związane z kodami zapasowymi

Natychmiastowe generowanie kodów zapasowych po włączeniu 2FA oraz możliwość ich nieautoryzowanego pobrania, zwłaszcza przy błędnej konfiguracji CORS lub lukach XSS, stanowią zagrożenie.[1][2]

Ujawnienie informacji na stronie 2FA

Ujawnienie poufnych informacji (np. numeru telefonu) na stronie weryfikacji 2FA stanowi zagrożenie.[1]

Wyłączenie 2FA przez resetowanie hasła

Potencjalna metoda obejścia polega na utworzeniu konta, włączeniu 2FA, zresetowaniu hasła, a następnie zalogowaniu się bez wymogu 2FA.[2]

Żądania-wabiki

Wykorzystanie żądań-wabików do zamaskowania prób Brute Force lub wprowadzenia w błąd mechanizmów ograniczania liczby prób stanowi dodatkową metodę omijania zabezpieczeń. Tworzenie takich żądań wymaga dokładnego zrozumienia zabezpieczeń aplikacji i mechanizmów ograniczania liczby prób.

Błędy konstrukcji OTP

Jeśli OTP jest wyprowadzany wyłącznie z przewidywalnych lub dostarczanych przez klienta danych, użytkownik może być w stanie go odtworzyć. Sprawdź, czy kody są generowane na podstawie kryptograficznie bezpiecznego sekretu, są krótkotrwałe i jednorazowe oraz powiązane z właściwym kontem i działaniem.[5]

Brak wymuszania uwierzytelniania step-up (acr, amr, auth_time)

Niektóre aplikacje pozwalają użytkownikom logować się słabą metodą, a następnie wymagają MFA lub ponownego logowania dopiero przed wrażliwym działaniem (zmianą adresu e-mail, dodaniem odbiorcy płatności, eksportem danych, otwarciem panelu administratora). Nazywa się to uwierzytelnianiem step-up. W przypadku OpenID Connect lub OAuth działa to zazwyczaj tak:

  • Klient prosi dostawcę tożsamości o silniejsze uwierzytelnienie, przekazując acr_values=<level> i/lub max_age=<seconds> w żądaniu autoryzacji.[6]
  • Token ID lub profil tokenu dostępu zawierający kontekst uwierzytelnienia może określać, co się wydarzyło: acr (spełniony poziom uwierzytelnienia), amr (użyte metody, np. ["pwd","otp"]) i auth_time (czas uwierzytelnienia użytkownika). Nie wszystkie te claims występują w każdym tokenie.[6]
  • API wymagające silniejszego uwierzytelnienia odpowiada kodem 401 i nagłówkiem WWW-Authenticate: Bearer error="insufficient_user_authentication", acr_values="...", max_age=..., a następnie musi sprawdzić acr i auth_time w otrzymanym tokenie.[7]

acr_values to tylko żądanie. Klient (lub API) musi sprawdzić otrzymane claims. OIDC Core zaleca klientowi sprawdzenie, czy wartość acr jest odpowiednia, oraz sprawdzenie auth_time i zażądanie ponownego uwierzytelnienia, jeśli upłynęło zbyt dużo czasu.[6] Jeśli tego nie zrobi, można pominąć step-up.

Testy black-box z użyciem konta testowego, dla którego włączono MFA:

  1. Przechwyć żądanie autoryzacji step-up i usuń acr_values / max_age albo zmień acr_values na słabszą wartość (na przykład z mfa lub urn:...:loa:2 na wartość widoczną podczas zwykłego logowania). Dokończ logowanie bez MFA i użyj uzyskanego wyniku do wykonania wrażliwego działania.
  2. Bezpośrednio wywołaj wrażliwy endpoint przy użyciu tokenu lub sesji ze zwykłego logowania (niska wartość acr, amr bez otp/mfa). Żądanie musi zostać odrzucone i wywołać step-up.
  3. Użyj tokenu, którego auth_time jest starsze niż wymagane max_age (zaloguj się, odczekaj, a następnie spróbuj wykonać działanie).
  4. Po jednym udanym step-up (np. wyświetleniu klucza API) użyj ponownie tej samej „podwyższonej” sesji lub tokenu do innych wrażliwych działań oraz do tego samego działania po dłuższym czasie. Sprawdź, czy podwyższony stan jest ograniczony do jednego działania i wygasa.
  5. Jeśli aplikacja przechowuje wynik step-up we fladze po stronie klienta ("mfaVerified": true, cookie elevated=1, pole w niepodpisanym tokenie), zmień ją ręcznie.

Podatność występuje, gdy wrażliwe działanie udaje się bez silniejszego acr/amr albo z auth_time starszym niż dozwolony. W przypadku ponownego użycia flagi podwyższonej sesji w niezwiązanych funkcjach zobacz też ponowne użycie stanu autoryzacji w zakresie sesji.

References

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Przejrzyj pełny katalog HackTricks Training.

Wesprzyj HackTricks
Sponsored