Ataki typu post-authentication – czym są i jak się przed nimi chronić?

kapitanhack.pl 1 miesiąc temu

Dobrze znamy ataki, które próbują naruszyć nazwy użytkowników i hasła. Słabe hasła można złamać. Ponownie użyte hasła są podatne na ataki typu credential-stuffing i password-spraying. Oszustwa phishingowe próbują wprost ukraść nazwy użytkowników i hasła. Wszystkie powyższe to ataki typu pre-authentication – przed uwierzytelnieniem. Próbują uzyskać dane uwierzytelniające, aby atakujący mogli zalogować się do usługi/aplikacji jako inny użytkownik.

Istnieją jednak również sposoby, aby dostać się na konto ofiary już po zalogowaniu. Większość z nich polega na kradzieży lub złamaniu tokenów sesji, które są przyznawane prawowitym użytkownikom po pomyślnym zalogowaniu. Nazywamy je atakami typu post-authentication – po uwierzytelnieniu.

Ataki post-authentication mogą ominąć uwierzytelnianie wieloskładnikowe (MFA) i pozostać niewidoczne dla prawowitego użytkownika i usługi, do której uzyskuje się dostęp. Są one w stanie pokonać choćby najnowocześniejsze formy uwierzytelniania, w tym klucze sprzętowe i hasła. Nie ma znaczenia, jak silna jest forma uwierzytelniania lub ile czynników jest używanych, jeżeli token sesji po uwierzytelnieniu może zostać skradziony.

Pochylmy się na chwilę nad kilkoma najpopularniejszymi scenariuszami używanymi w atakach post-authentication.

Passing the Token

Gdy logujemy się do konta online, czy to w przeglądarce internetowej, czy w aplikacji mobilnej, serwer usługi online przypisuje naszemu urządzeniu token sesji. Jest on wykorzystywany w każdej kolejnej interakcji z usługą, aby przypomnieć serwerowi, iż jesteśmy autoryzowanym użytkownikiem. W przeciwnym razie witryna internetowa może poprosić o zalogowanie się za każdym razem, gdy klikniemy inną podstronę czy wyślemy formularz.

Token sesji to zwykle długi, istotny tymczasowo ciąg losowych cyfr i liter. Gdy wylogowujemy się z usługi, token jest usuwany zarówno z naszego urządzenia, jak i z serwera, z którym urządzenie wchodzi w interakcję.

Jednak niektóre tokeny sesji są ważne przez bardzo długi czas. Na przykład, jeżeli często korzystasz z Twittera/X, być może zauważyłeś, iż prawie nigdy nie musisz się ponownie logować, chyba iż używasz nowego komputera. Dzieje się tak, ponieważ tokeny sesji mediów społecznościowych są zasadniczo nieokreślone i często żyją bardzo długo.

Jednak są to skrajne przykłady. W zakładach pracy polityka firmy zwykle nakazuje, aby użytkownik logował się ponownie do służbowych usług i aplikacji znacznie częściej, czasami więcej niż raz dziennie. Wylogowanie „czyści” tokeny, dzięki czemu można zacząć sesję od nowa.

W przeglądarkach internetowych tokeny przybierają formę „plików cookie”, tego samego rodzaju tymczasowego identyfikatora, który może być również używany do śledzenia użytkowników i analizowania ich zachowań. Aplikacje mobilne przechowują z kolei tokeny w wewnętrznych bazach danych.

Istnieją również inne znane formy tokenów uwierzytelniających, z których nie wszystkie mogą być tymczasowe:

Tokeny OAuth – często używane przez „społecznościowe” metody logowania, które umożliwiają logowanie się do witryn przy użyciu danych Google, Facebooka czy Microsoftu.

Certyfikaty – używane do weryfikacji tożsamości urządzenia podczas nawiązywania bezpiecznych połączeń HTTPS lub VPN.

Klucze API – używane do uwierzytelniania komunikacji w zautomatyzowanych interakcjach między procesami i urządzeniami w sieci, a choćby w Internecie.

Kradzieże tokenów

Wraz ze wzrostem popularności uwierzytelniania wieloskładnikowego, biometrii, kluczy sprzętowych i innych form silnego uwierzytelniania, atakujący zaczęli kraść i nadużywać tokenów uwierzytelniania jako obejścia tych wszystkich zabezpieczeń.

Niestety niemal każdy rodzaj tokena może zostać skradziony. jeżeli w procesie uwierzytelniania nie jest używana całkowicie bezpieczna komunikacja, token może zostać „podsłuchany” przez oprogramowanie monitorujące ruch sieciowy. Podobnie, jeżeli do przechowywania danych nie jest używane silne szyfrowanie, tokeny mogą zostać skradzione przez złośliwe oprogramowanie, które zainfekowało urządzenie. Najbardziej znanym atakiem po uwierzytelnieniu jest przejęcie sesji (ang. session hijacking), które obejmuje kradzież i niewłaściwe wykorzystanie plików cookie sesji przeglądarki. Oprócz podsłuchiwania pakietów sieciowych atakujący mają kilka sposobów na kradzież plików cookie sesji:

Złośliwe wtyczki lub rozszerzenia przeglądarki: miniaplikacje, które można dodać jako dodatkowe funkcje przeglądarki, często mogą szpiegować aktywność użytkownika, w tym przesyłanie i przechowywanie tokenów sesji do i z usług stron trzecich. (Nawet rozszerzenia i wtyczki znajdujące się w Chrome Web Store lub bibliotece dodatków Firefox mogą być złośliwe. Warto na to uważać).

Ataki typu cross-site scripting i cross-site request forgering: te dwa rodzaje ataków na przeglądarki i aplikacje internetowe można połączyć w jedną technikę. Atakujący najpierw wstrzykuje złośliwy kod do przeglądarki klienta lub aplikacji internetowej, a następnie wysyła złośliwe żądania do witryny w celu kradzieży plików cookie sesji. Ataki typu cross-site scripting mogą również same w sobie kraść pliki cookie.

Infekcje malware: złośliwe oprogramowanie, które wykracza poza przeglądarkę, aby zainfekować sam komputer, może skanować lokalną pamięć przeglądarki w poszukiwaniu plików cookie oraz próbować przechwytywać pakiety danych między przeglądarką a portami sieciowymi.

Jak się przed tym chronić?

Na szczęście istnieje kilka sposobów, aby zabezpieczyć się przed kradzieżą tokenów uwierzytelniających, jeżeli nie całkowicie jej zapobiec.

  • Ograniczenie okresu ważności tokenów – jeżeli administrujesz wewnętrzną witryną internetową lub aplikacjami internetowymi, ustaw tokeny sesji i tokeny OAuth dla zwykłych użytkowników tak, aby wygasały co 12 lub 24 godziny. Upewnij się również, iż certyfikaty maszyn i klucze API nie są wieczne – również powinny mieć krótki okres ważności.
  • Wykorzystanie systemów typu PAM – jeżeli to możliwe, zarządzaj tokenami uwierzytelniającymi administratorów za pośrednictwem platformy zarządzania dostępem uprzywilejowanym (PAM) i rozważ użycie uwierzytelniania just-in-time dla kont administratorów.
  • Wymuszenie wylogowania użytkownika – regularni użytkownicy aplikacji i witryn wewnętrznych powinni codziennie się wylogowywać, aby wyczyścić tokeny sesji ze swoich przeglądarek i aplikacji internetowych.
  • Silne szyfrowanie transmisji sieciowych – sesje aplikacji internetowych powinny być w całości oparte na protokole HTTPS, aby certyfikaty używane do nawiązywania bezpiecznego połączenia nie mogły zostać skradzione podczas „uścisku dłoni” klienta i serwera.
  • Silne szyfrowanie przechowywanych tokenów – trzeba mieć pewność, iż złośliwe oprogramowanie nie będzie mogło odczytać przechowywanych tokenów w bazie danych lub w pamięci operacyjnej.
  • Ograniczenie rozszerzeń przeglądarki – zablokuj użytkownikom możliwość instalowania niezatwierdzonych rozszerzeń w zarządzanych przeglądarkach w miejscu pracy i wyjaśnij im, dlaczego jest to niebezpieczne.
  • Wymuszenie aktualizacji przeglądarki – upewnij się, iż przeglądarki na stacjach roboczych pracowników są aktualne i w pełni załatane.
  • Monitorowanie wykorzystania tokenów sesji – jeżeli administrujesz witryną lub aplikacjami internetowymi, możesz śledzić, skąd pochodzą tokeny sesji i próbować blokować te używane z nieoczekiwanych lokalizacji lub poza godzinami pracy.

Teraz zarówno Microsoft, jak i Google próbują powiązać tokeny sesji z modułami Trusted Platform Modules (TPM) znajdującymi się w większości nowoczesnych komputerów z systemem Windows, ale protokoły są przez cały czas w fazie rozwoju.

Idź do oryginalnego materiału