Podejście programowe do ochrony tożsamości w architekturze ZTA

 

Poniższy artykuł powstał na podstawie transkrypcji wystąpienia Marcina Paciorkowskiego z CyberArk podczas konferencji Trecom Security 360. Omawiane kwestie skupiają się przede wszystkim na zagadnieniu ochrony tożsamości – jak do niej podejść, na co zwrócić uwagę, jakiego typu narzędzia wykorzystać, aby uzyskać założony poziom ochrony tożsamości i jak wszystkie te elementy wpasować w program. Ponieważ ochrona tożsamości w wydaniu punktowym po prostu się nie sprawdza. Dodatkowo po krótce omówiony zostanie sam model Zero Trust Access oraz wspomniane konkretne rozwiązania produktowe firmy CyberArk odpowiadające na wspomniane wyżej potrzeby.

Wektory ataków

 

 

Marcin Paciorkowski - podejście platformowe do architektury ZTA wektory ataków

Współczesne środowisko teleinformatycznie znacznie różni się od tego, z którym mieliśmy do czynienia 10 lat temu. Obecnie jest to zazwyczaj olbrzymim ekosystemem technologii, platform i aplikacji, które ze sobą współpracują, aby dostarczyć dynamicznie rozwijającemu się biznesowi narzędzia, umożliwiające jego sprawne funkcjonowanie i dalszy rozwój.  

Z punktu widzenia bezpieczeństwa i potencjalnych punktów, które atakujący może wykorzystać do wejścia do organizacji, liczba elementów, które należy objąć ochroną jest zdecydowanie większa niż w przeszłości. Ich liczba rośnie wykładniczo w stosunku do liczby technologii, które wykorzystujemy w środowisku teleinformatycznym. Równolegle, co chwila pojawiają się nowe techniki i taktyki atakujących umożliwiające złamanie zabezpieczeń.

10 lat temu sytuacja była dosyć prosta – atakujący wchodzący do organizacji starał się wykraść poświadczenia, korzystając z exploit lub malware, którymi infekował system operacyjny, aby korzystając z niego móc podszywać się pod użytkownika. Jeszcze niedawno, atakujący najczęściej dążył do tego, aby pozyskać konto uprzywilejowane. Jeśli użytkownik korzystał na przykład z konta lokalnego administratora, a atakującemu udało się je przejąć, organizacja stawała w obliczu dużego problemu.

Obecnie większość organizacji zdaje sobie sprawę z tego zagrożenia i stara się stosować polityki minimalnych uprawień, zgodnie z którymi użytkownik nigdy nie będzie miał uprawnień lokalnego administratora. Oczywiście, często spotykamy się z wyjątkami, na przykład zespoły IT, helpdesk, developerzy i niektórzy użytkownicy biznesowi nadal posiadają konto na poziomie lokalnego administratora. W idealnym świecie, dążymy do sytuacji, w której eliminujemy te wyjątki, implementując program ochrony tożsamości, do czego przejdziemy w dalszej części tego artykułu.

Wracając do atakującego – w dzisiejszych czasach sposób w jaki przestępcy kompromitują tożsamość użytkownika uległ zmianie. Jeśli złośliwe oprogramowanie zostanie uruchomione na poziomie systemu operacyjnego, będzie przeszukiwało repozytoria haseł, kluczy SSH (Secure Shell) czy konta wysoko uprzywilejowane. Z drugiej strony praktycznie każde narzędzie cybebezpieczeństwa (Microsoft, EDRy, antywirus) potrafi rozpoznać oprogramowania typu Mimikatz i skutecznie blokować jego uruchomienie. Jednak atakujący może wykorzystać inne narzędzia, którymi będzie eksplorować proces LSASS (Local Security Authority Subsystem Service).

Warto jednak zwrócić uwagę na to, że współcześnie atakujący unikają „grzebania” w LSASSie, ponieważ jest to łatwe do wykrycia. Z tego powodu atakujący wykorzystują inne techniki – na przykład, w kontekście użytkownika, czyli konta nieuprzywilejowanego. Coraz częściej dochodzi do kradzieży czegoś, co nazywamy ciasteczkiem.

Atakujący skupiają się więc na przeglądarkach internetowych oraz aplikacjach webowych, które użytkownik wykorzystuje w swojej codziennej pracy skąd próbują wykraść ciasteczko. Dlaczego? Ponieważ współcześnie większość aplikacji oferuje użytkownikom interfejs w ramach przeglądarki. Użytkownik po prostu łączy się z wykorzystaniem HTTPS i korzysta z aplikacji.

Kradzież ciasteczek realizowana jest praktycznie przez każde złośliwe oprogramowanie, które w obecnych czasach uruchamiane jest na stacji roboczej użytkownika. Ciasteczka relatywnie łatwo zdobyć. Jeszcze kilka miesięcy temu można było dostać się za pośrednictwem darknetu do platformy o nazwie Genesis, gdzie za zaledwie kilka dolarów można było wyszukać osobę i pozyskać ciasteczka (jeśli wyciekły z systemu operacyjnego). Wyszukiwarka pozwalała na zawężenie wyszukiwania do np. osoby z Polski, firmy np. z sektora finansowego i filtrowanie po nazwach poszczególnych banków. W tak prosty sposób można było pozyskać ciasteczka, które złośliwe oprogramowanie wykradło ze stacji użytkowników. Dobra wiadomość jest taka, że ta platforma już nie działa. Kilka tygodni temu z inicjatywy FBI i we współpracy 17 państw serwis Genesis został zamknięty.

Posiadając ciasteczko, można w łatwy sposób ominąć systemy bezpieczeństwa zaimplementowane w aplikacji web. Po przykład odsyłam do artykułu, który powstał z inicjatywy centrum badawczego CyberArk, który opisuje technikę bypassowania uwierzytelniania w Gmail. Większość użytkowników korzysta z Gmail w taki sam sposób – uwierzytelniamy się raz w przeglądarce na naszej stacji roboczej. Następnie korzystamy z Gmail na przeglądarce bez konieczności ponownego uwierzytelnienia.

Co w takiej sytuacji dzieje się w tle? Pierwsze uwierzytelnianie bazuje zazwyczaj na mulitifactor authentication (MFA) – czyli połączeniu hasła statycznego i smsa, który użytkownik otrzymuje jako token potwierdzający. To bezpieczna metoda, jednak pamiętajmy, że jeśli dokonaliśmy procesu uwierzytelniania, w Gmail tworzy się tzw. persistent cookie (trwałe ciasteczko), które osadza się w systemie operacyjnym. Następnym razem, kiedy będziemy łączyli się z Gmail z tej samej stacji i przeglądarki, przeglądarka będzie „widziała” ciasteczko i wykorzysta je do uwierzytelniania.

Gmail nie będzie, więc pytał o hasło czy MFA, ponieważ zaufał naszej stacji roboczej i naszej przeglądarce i ma ciasteczko, które wykorzystuje do uwierzytelniania.

W ramach działalności CyberArk Labs, na potrzeby testów, stworzyliśmy narzędzie, które w kontekście użytkownika jest w stanie wyciągnąć z systemu operacyjnego wspomniane wcześniej ciasteczko. Wykorzystując to ciasteczko na innym systemie operacyjnym, w innej przeglądarce, modyfikując tylko podstawowe atrybuty, jesteśmy w stanie ominąć MFA i dostać się do sesji uwierzytelnionej powiązanej z tym konkretnym ciasteczkiem.

Przerażający natomiast jest czas przechowywania ciasteczka po stronie Gmail (czyli czas, który upływa od pierwszego logowania do ponownej prośby o uwierzytelnienie wysłanej przez Gmail).
Trwałe ciasteczko domyślnie jest ważne DWA LATA (stan na maj 2023 roku)! Oznacza to, że ktoś kto posiadł dane ciasteczko, może wykorzystać je do podszywania się pod sesje użytkownika w przeciągu dwóch lat....

 

Reszta artykułu o ZTA dostępna jest bezpłatnie po wypełnieniu poniższego formularza

Udostępnij artykuł

Napisano Sep 19, 2023 3:18:34 PM przez Katarzyna