W jaki sposób atakujący omijają nowoczesne uwierzytelnianie dwuskładnikowe i jak chronić użytkowników

Ben Balthazar, 4 luty 2020
How Attackers Bypass Modern Two-factor Authentication and How to Protect Your Users

W tym artykule przyjrzymy się przykładowi narzędzi i technik, które atakujący mogą wykorzystać, aby ominąć najbardziej tradycyjne uwierzytelnianie dwuskładnikowe (2FA), od SMS OTP po zaszyfrowane powiadomienia push do aplikacji mobilnej. Metoda ataku może być bardzo skuteczna w przypadku większości typów 2FA wdrożonych obecnie, w tym uwierzytelniania poza pasmem. Omówimy również, jakie środki zaradcze mogą zastosować banki, aby zmniejszyć ryzyko takich ataków i chronić swoich klientów.

Przygotowanie ataku

Aby wykonać ten atak, użyjemy kombinacji dwóch narzędzi, Muraena i Necrobrowser. Muraena jest zwrotny serwer proxy która uruchomi naszą stronę phishingową. Strona phishingowa będzie zastępować oryginalną stronę, z którą ofiara będzie wchodzić w interakcje. Gdy ofiara się uwierzytelni, sesja Muraena przekaże sesję Necrobrowser, co pozwoli napastnikowi przejąć kontrolę nad sesją lub zautomatyzować kolejne kroki ataku. Ponieważ Muraena działa jako zwrotny serwer proxy, nie będzie różnicy między naszą złośliwą witryną a oryginalną witryną oprócz adresu URL. Muraena może być skonfigurowana do używania SSL z certyfikatami uzyskanymi np. Przez LetsEncrypt. Z punktu widzenia ofiary całe doświadczenie wydaje się uzasadnione, ponieważ wygląda na to, że wchodzi w interakcję z oryginalną stroną. Przejdą regularny proces uwierzytelniania, w tym 2FA. Jeśli 2FA składa się ze zwykłego jednorazowego hasła dostarczanego przez SMS, token sprzętowy lub programowy, ofiara wprowadzi je jak zwykle. Jednak nawet nowoczesne metody, takie jak powiadomienie wypychane na urządzenie mobilne lub skanowanie kodu QR na ekranie, zostaną ominięte przez ten atak.

Ilustracja ataku phishingowego na odwrotne proxy.

  1. Użytkownik odwiedza stronę phishingową z włączoną obsługą SSL.
  2. Odwrotny serwer proxy (Muraena) pobiera prawidłową stronę banku i podaje kopię ofierze.
  3. Ofiara próbuje zalogować się na stronie i zostaje poproszony o uwierzytelnienie dwuskładnikowe
  4. Po tym, jak ofiara zakończy proces uwierzytelniania, odwrotny serwer proxy (Muraena) przekazuje sesję atakującemu (Necrobrowser) w celu przejęcia kontroli, odcinając ofiarę.

Na poniższym obrazku widać Muraena hostującą Google w domenie phish.anti. Na potrzeby demonstracji skonfigurowałem lokalny DNS, aby rozwiązać ten problem na mojej maszynie testowej, a także wystawiłem certyfikaty, używając własnego urzędu certyfikacji, któremu ufa przeglądarka. Jednak dokładnie tak by to wyglądało z perspektywy ofiary, gdyby zostało wdrożone we własnej domenie przy użyciu prawidłowych certyfikatów.

Zrzut ekranu przedstawiający Muraenę pośredniczącą w google.com na phish.anti przy użyciu SSL.

Ochrona przed atakiem

Teraz, gdy rozumiemy, jak działa atak, możemy określić, które kroki byłyby skuteczne w identyfikacji lub ochronie przed tego rodzaju atakami.

Dynamiczne linkowanie zapewnia dobrą pierwszą warstwę obrony przed różnymi atakami. Łączenie dynamiczne polega na dwuskładnikowym uwierzytelnieniu wykonywanym w momencie transakcji, które uwzględnia szczegóły transakcji w procesie podpisywania. Często nazywany jest tym, co widzisz, co podpisujesz, ponieważ użytkownik końcowy powinien przedstawić szczegóły transakcji przed zakończeniem procesu podpisywania. Po podpisaniu podpis powinien być ważny tylko dla tej konkretnej transakcji, co utrudnia obejście atakującego. Zazwyczaj dynamiczne łączenie jest realizowane za pomocą tokenów sprzętowych, tokenów programowych lub zintegrowane jako część aplikacji bankowej. Poniżej mamy 2 przykłady dynamicznego łączenia, pierwszy dla legalnej płatności, a drugi, w którym atakujący próbuje zmodyfikować płatność.

Ilustracja dynamicznego linkowania w legalnej płatności.

  1. Użytkownik tworzy transakcję w bankowości internetowej.
  2. Użytkownik przesyła transakcję.
  3. Bank przesyła szczegóły transakcji na telefon komórkowy użytkownika.
  4. Użytkownik weryfikuje szczegóły przelewu i autoryzuje płatność za pomocą danych biometrycznych (lub innego drugiego czynnika).
  5. Aplikacja mobilna generuje hasło jednorazowe na podstawie szczegółów transakcji i klucza tokena w aplikacji mobilnej.

Ilustracja dynamicznego linkowania, w którym atakujący próbuje zmodyfikować płatność.

  1. Użytkownik próbuje utworzyć płatność w bankowości internetowej.
  2. Atakujący modyfikuje płatność, aby mieć nowe konto beneficjenta i / lub kwotę.
  3. Bank przesyła szczegóły transakcji na telefon komórkowy użytkownika.
  4. Użytkownik otrzymuje zmodyfikowane informacje o płatności i odrzuca płatność.

Powyższe przykłady ilustrują również znaczenie szyfrowania typu end-to-end podczas implementowania dynamicznego łączenia. Ponadto pokazuje, że sama aplikacja mobilna powinna być chroniona, ponieważ osoba atakująca może próbować zaatakować aplikację, aby ukryć zmodyfikowane szczegóły płatności przed użytkownikiem.

Innym skutecznym sposobem rozpoznawania i obrony przed różnorodnymi atakami jest wdrożenie ciągłe monitorowanie na wasze platformy cyfrowe. Monitorując sesję od momentu jej rozpoczęcia do końca, możemy wprowadzić więcej kontekstu dzięki działaniom użytkowników i urządzeń lub kont, z którymi się kojarzą. Ciągłe monitorowanie doskonale łączy się z innymi warstwami, takimi jak 2FA lub dynamiczne łączenie, ponieważ pozwala bankowi na kontekst również z tych urządzeń uwierzytelniających.

Przykład ciągłego monitorowania w celu zrozumienia każdej próby operacji, uwierzytelnienia i wyniku.

Bank może następnie monitorować typowe wskaźniki znanych ataków, takich jak nowe urządzenia, lokalizacje, obecność proxy lub inne. Informacje te mogą być skorelowane w całej bazie użytkowników, aby lepiej zrozumieć ryzyko związane z tymi elementami. Następnie możemy również uwzględnić operacje wykonywane przez użytkownika w trakcie samej sesji i profilować to na podstawie ich zwykłego zachowania. Podejście to ustanawia stały profil ryzyka dla sesji, który może się zmieniać z każdym działaniem wykonywanym przez użytkownika końcowego. Nie tylko pozwala to bankowi podejmować zautomatyzowane działania w czasie rzeczywistym po wykryciu anomalii, ale także pozwala bankowi zmniejszyć tarcie podczas legalnych sesji poprzez zmniejszenie liczby uwierzytelnień wymaganych dla prawdziwych sesji.

Wniosek

Chociaż atak w tym artykule wykorzystuje technologie i koncepcje, które istnieją od wieków, widzimy, że ich prawidłowe stosowanie może nadal prowadzić do wielkich sukcesów i pokonać różne metody uwierzytelniania wdrożone dzisiaj. Ważne jest, aby banki stosowały podejście warstwowe, ponieważ większość pojedynczych warstw można nadal atakować lub wykorzystywać. Podczas wdrażania dynamicznego linkowania banki muszą upewnić się, że ustanawiają bezpieczną linię komunikacji z użytkownikiem końcowym. Na przykład poleganie na SMS-ach okazało się już niewiarygodne, ponieważ wiadomości mogą zostać skradzione, sfałszowane lub przechwycone przez atakującego. Jednak przy wdrażaniu aplikacji mobilnych banki powinny mieć świadomość, że aplikacje te stają się celem i powinny chronić swoje aplikacje mobilne przed atakami zewnętrznymi. Celem tego artykułu jest przede wszystkim wykazanie, że ataki phishingowe można zmodernizować, aby wyeliminować uwierzytelnianie dwuskładnikowe podczas logowania, a samo wdrożenie 2FA nie zapewnia pełnej ochrony przed phishingiem. Na koniec wspomnieliśmy o niektórych warstwach, które banki mogą wdrożyć w celu zapewnienia dalszej ochrony użytkownikom końcowym, a także o pułapkach, których należy unikać. Podsumowując:

  • Wprowadzić w życie dynamiczne linkowanie z kompleksowym szyfrowaniem.
  • Wdróż analitykę po stronie serwera w monitor sesje użytkowników końcowych, urządzenia i zachowanie pod kątem potencjalnych ataków.
  • Ochraniać twój telefon komórkowy aplikacje przed złośliwym oprogramowaniem i innymi zagrożeniami zewnętrznymi.
eBook

Oszustwo związane z przejęciem konta: jak chronić klientów i firmę

Pomóż zapobiegać oszustwom związanym z przejęciem konta i zabezpieczyć klientów na każdym etapie ich cyfrowych podróży.

Pobierz teraz

 

Ben Balthazar jest konsultantem ds. Oszustw w OneSpan, pomagając instytucjom finansowym w Europie, na Bliskim Wschodzie i Azji w obronie przed cyberprzestępczością finansową. Ben rozpoczął karierę w OneSpan w 2014 roku i przeprowadził się z Belgii do Dubaju w 2016 roku.