Inspekcja SSL/TLS i ataki Man-in-the-Browser

HTTPS stanowi obecnie ponad 90% ruchu internetowego — w tym pobierania złośliwego oprogramowania, kanałów C2 i eksfiltracji danych. Narzędzia ochrony granicy sieci, które nie potrafią przeprowadzać inspekcji TLS, widzą tylko zaszyfrowane dane, tworząc lukę w widoczności aktywnie wykorzystywaną przez atakujących. Inspekcja SSL/TLS (nazywana także przechwytywaniem SSL, SSL bumpingiem lub głęboką inspekcją pakietów HTTPS) umożliwia bramom bezpieczeństwa odszyfrowywanie, sprawdzanie i ponowne szyfrowanie ruchu HTTPS, zanim dotrze on do urządzenia końcowego. Taka widoczność jest niezbędna do filtrowania treści internetowych, zapobiegania utracie danych (DLP) i skanowania antymalware w środowiskach, w których większość ruchu korzysta z HTTPS.

Inspekcja SSL jest technicznie kontrolowanym atakiem man-in-the-middle przeprowadzanym przez własną infrastrukturę bezpieczeństwa organizacji. Proces wygląda następująco: Krok 1: Klient nawiązuje połączenie TLS z proxy (korzystając z certyfikatu proxy podpisanego przez firmowy urząd CA). Krok 2: Proxy ustanawia oddzielną sesję TLS z właściwym serwerem, korzystając z prawdziwego certyfikatu serwera. Krok 3: Proxy odszyfrowuje ruch od klienta, sprawdza go, a następnie ponownie szyfruje i przekazuje do serwera (i odwrotnie). Klient ufa certyfikatowi proxy, ponieważ certyfikat firmowego urzędu CA jest wcześniej instalowany na wszystkich zarządzanych urządzeniach końcowych za pośrednictwem MDM lub zasad grupy.

Nie każdy ruch powinien być poddawany inspekcji. Organizacje zazwyczaj wyłączają z niej kategorie zawierające dane wrażliwe pod względem prawnym lub etycznym: serwisy bankowe i finansowe, portale ochrony zdrowia, bazy danych z materiałami prawniczymi, adresy URL związane z przejrzystością certyfikatów i OCSP (aby uniknąć zakłócenia walidacji certyfikatów) oraz witryny korzystające z przypinania certyfikatów (które odrzucą ponownie podpisane certyfikaty i spowodują awarię aplikacji). Wyłączenia są utrzymywane na liście wyjątków w zasadach inspekcji. W niektórych jurysdykcjach przepisy dotyczące monitorowania pracowników mogą ograniczać inspekcję prywatnego przeglądania internetu, co wymaga jasnego ujawnienia takich praktyk w zasadach akceptowalnego użytkowania.

Przypinanie certyfikatów to technika, w której aplikacja ma na stałe zapisany oczekiwany certyfikat lub klucz publiczny określonego serwera i odmawia połączenia, jeśli certyfikat nie pasuje — nawet gdy jest on prawidłowy i zaufany przez magazyn CA systemu operacyjnego. Uniemożliwia to inspekcję SSL, ponieważ ponownie podpisany przez proxy certyfikat nie jest zgodny z przypiętą wartością. Aplikacje mobilne (aplikacje bankowe i płatnicze) często wykorzystują przypinanie certyfikatów jako zabezpieczenie przed atakami MitM. Przedsiębiorstwa muszą omijać inspekcję dla aplikacji korzystających z przypinania, w przeciwnym razie przestaną one działać. Oznacza to również, że atakujący chcący ominąć inspekcję SSL za pomocą złośliwego oprogramowania mogą zaimplementować przypinanie certyfikatów.

SSL stripping to atak man-in-the-middle, w którym atakujący przechwytuje ruch HTTPS i obniża go do HTTP, dzięki czemu może odczytywać i modyfikować treść w postaci jawnej. Atak działa w przypadku połączeń rozpoczynających się od HTTP, a następnie przekierowywanych do HTTPS: atakujący przechwytuje początkowe żądanie HTTP, utrzymuje połączenie HTTP z ofiarą, jednocześnie ustanawiając połączenie HTTPS z prawidłowym serwerem, i transparentnie przekazuje ruch. Z perspektywy ofiary witryna wygląda jak działająca przez HTTP. HTTP Strict Transport Security (HSTS) chroni przed SSL strippingiem, informując przeglądarki, aby zawsze korzystały z HTTPS dla danej domeny, nawet jeśli użytkownik wpisze HTTP.

Atak typu Man-in-the-Browser (MitB) jest formą trojana bankowego, który wstawia się do przeglądarki internetowej — jako złośliwe rozszerzenie lub poprzez wstrzyknięcie do procesu przeglądarki — i modyfikuje strony internetowe oraz transakcje bez wiedzy użytkownika. W przeciwieństwie do sieciowego ataku MitM, MitB działa wewnątrz zaszyfrowanej sesji na poziomie przeglądarki, dlatego TLS nie zapewnia ochrony. Złośliwe oprogramowanie MitB (Zeus, SpyEye) może: zmieniać kwoty płatności, modyfikować numery rachunków odbiorców, przechwytywać jednorazowe hasła i potajemnie modyfikować formularze po ich wypełnieniu przez użytkownika. Modyfikacje następują po odszyfrowaniu TLS, a przed wyświetleniem wyrenderowanej strony użytkownikowi.

Złośliwe oprogramowanie MitB podłącza się do interfejsów API przeglądarki na poziomie aplikacji. W systemie Windows wstrzykuje kod do procesów przeglądarek (Chrome, Firefox, IE) za pomocą wstrzykiwania bibliotek DLL lub przejęcia COM, a następnie podłącza się do funkcji JavaScript i interfejsów API modyfikowania DOM. Gdy użytkownik odwiedza swój bank, złośliwe oprogramowanie przechwytuje kod JavaScript renderujący stronę i potwierdzenie transakcji, zmieniając rachunek odbiorcy na rachunek atakującego. Serwer widzi prawidłową transakcję, a serwerowe dzienniki HTTPS nie wykazują niczego niezwykłego. Użytkownik widzi prawidłowe potwierdzenie — z zamierzoną przez siebie kwotą — podczas gdy rzeczywisty przelew trafia na rachunek atakującego.

Obrona przed MitB wymaga wielowarstwowych zabezpieczeń. Izolacja przeglądarki (Menlo Security, Zscaler Browser Isolation) wykonuje renderowanie przeglądarki w zdalnej maszynie wirtualnej w chmurze i przesyła na ekran użytkownika wyłącznie piksele — złośliwe oprogramowanie nie może wstrzyknąć kodu do procesu przeglądarki działającego w zdalnym środowisku. Weryfikacja transakcji: banki potwierdzają szczegóły transakcji (kwotę + odbiorcę) za pośrednictwem kanału pozapasmowego (SMS OTP zawierający szczegóły transakcji), dzięki czemu użytkownik musi zweryfikować dane faktycznie otrzymane przez serwer. EDR na punktach końcowych, wykrywający wstrzykiwanie bibliotek DLL do procesów przeglądarek, może identyfikować infekcje MitB. Lista dozwolonych rozszerzeń przeglądarki zapobiega instalowaniu złośliwych rozszerzeń.

Złośliwe rozszerzenia przeglądarki stanowią poważne zagrożenie dla punktów końcowych. Rozszerzenia mają szerokie uprawnienia — mogą odczytywać zawartość stron, modyfikować żądania, przechwytywać wysyłanie formularzy i uzyskiwać dostęp do plików cookie. Rozszerzenie podszywające się pod przydatne narzędzie (blokadę reklam, tryb ciemny) może wykradać dane uwierzytelniające, wstrzykiwać reklamy, przekierowywać ruch lub działać jako agent MitB. Zabezpieczenia dla przedsiębiorstw: należy używać Group Policy lub MDM, aby ograniczyć instalowanie rozszerzeń do zatwierdzonej listy dozwolonych. Należy blokować instalowanie rozszerzeń ze źródeł innych niż Chrome Web Store lub Firefox Add-ons. Zainstalowane rozszerzenia na zarządzanych punktach końcowych należy regularnie kontrolować pod kątem naruszeń zasad.

Organizacje wdrażające inspekcję SSL muszą uwzględnić konsekwencje dla prywatności pracowników. W wielu jurysdykcjach i zgodnie z przepisami prawa pracy wymagane jest wyraźne powiadomienie przed rozpoczęciem monitorowania szyfrowanego ruchu. Najlepsze praktyki obejmują: opublikowanie Acceptable Use Policy (AUP), która wyraźnie informuje, że ruch sieciowy, w tym HTTPS, może być poddawany inspekcji; uzyskanie od pracowników potwierdzenia zapoznania się z AUP podczas wdrażania do pracy; wdrożenie kategorii wyłączeń dla stron bankowych i medycznych używanych prywatnie; oraz przechowywanie dzienników odszyfrowanego ruchu tylko przez okres niezbędny (zwykle 30–90 dni). Przed wdrożeniem programu inspekcji powinien go przeanalizować prawnik, szczególnie w krajach UE, gdzie RODO nakłada bardziej rygorystyczne ograniczenia na monitorowanie pracowników.

Certificate Transparency to struktura (RFC 6962), która wymaga, aby wszystkie publicznie zaufane certyfikaty TLS były rejestrowane w publicznie kontrolowalnych dziennikach CT, do których można tylko dopisywać dane, zanim przeglądarki im zaufają. CT umożliwia właścicielom domen monitorowanie niewłaściwie wystawionych certyfikatów: jeśli atakujący w jakiś sposób przekona urząd certyfikacji do wystawienia certyfikatu dla danej domeny (jak w przypadku DigiNotar w 2011 roku), dzienniki CT umożliwiają wykrycie tego niemal w czasie rzeczywistym. Narzędzia takie jak crt.sh pozwalają zespołom ds. bezpieczeństwa przeszukiwać dzienniki CT pod kątem wszystkich certyfikatów wystawionych dla ich domeny. Przeglądarki wymuszają CT, wymagając dowodu uwzględnienia certyfikatu w dzienniku (Signed Certificate Timestamps, SCT) osadzonego w uzgadnianiu TLS.

Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: inspekcja SSL/TLS odszyfrowuje, analizuje i ponownie szyfruje ruch HTTPS na serwerze proxy za pomocą certyfikatu urzędu certyfikacji firmy, któremu ufają zarządzane punkty końcowe; SSL stripping obniża HTTPS do HTTP i jest powstrzymywany przez HSTS; natomiast ataki man-in-the-browser wstrzykują kod do procesu przeglądarki powyżej warstwy TLS, aby niewidocznie modyfikować transakcje, dlatego jako zabezpieczenia wymagają izolacji przeglądarki lub pozapasmowej weryfikacji transakcji. W następnej części omówimy zastępowanie niezabezpieczonych protokołów ich bezpiecznymi odpowiednikami.