Niewielka próbka 1000 stron najbardziej popularnych według rankingu Alexa ujawnia, że aż 80% domen internetowych da się użyć do ataków phishingowych lub ataków ukierunkowanych, pomimo używania certyfikatu SSL. Nowy rodzaj ataku Client Domain Hooking odkryty przez Piotra Duszyńskiego (konsultanta ds. bezpieczeństwa i programisty z 10-letnim stażem specjalizującym się w bezpieczeństwie aplikacji internetowych i mobilnych) budzi podziw, a zarazem otwiera oczy szeroko i potwierdza to, co eksperci powtarzają od lat — należy korzystać z VPN. Szyfrować. Szyfrować. I jeszcze raz szyfrować przy łączeniu się do zasobów zdalnych, aby uodpornić się na przechwycenie komunikacji (MiTM). Niestety w pewnych okolicznościach nawet stosowanie VPN przy ataku Client Domain Hooking to za mało. Jednym pewny i bezpieczny sposób to używanie TLS dla całej transmisji przeglądarki z serwerem.
Proszę wyobrazić sobie sytuację, w której korzysta się ze źle zabezpieczonej aplikacji mobilnej, systemu do księgowości online, portalu CRM, chmury współdzielenia plików. Osoba atakująca, jeżeli przechwyci pojedyncze nieszyfrowanie zapytanie HTTP — a te są zazwyczaj wysyłane na początku sesji przez przeglądarki pomimo stosowania TLS ze stroną lub aplikacją — może na czas trwania sesji „ukraść” prawdziwą stronę WWW i dokleić ją do złośliwej domeny. Przykład takiego „doczepienia” wyszukiwarki DuckDuckGo wygląda tak:
Client Domain Hooking — „kradzież” strony WWW
Zaprezentowany atak typu Client Domain Hooking jest nową odmianą MiTM. Pozwala „przykleić” (prawie) dowolną stronę WWW do zupełnie innej domeny i przechwytywać cały ruch (tak jak na powyższym przykładzie z wyszukiwarką DuckDuckGo).
Podobne przekierowanie da się przeprowadzić, podmieniając wpisy w adresach DNS na serwerze, routerze, pliku HOSTS. W efekcie przestępca może pośredniczyć w przekazywaniu ruchu. Popularyzacja szyfrowania i stosowania certyfikatów SSL wcale nie czyni Internet dużo bezpieczniejszym, ponieważ sedno problemu ciągle znajduje się w pozostawionym obszarze nieszyfrowanym. Przeglądarka w dalszym ciągu będzie wyświetlała w pełni funkcjonalną stronę czy web-aplikację, ponieważ atakujący bez problemu może wdrożyć własny certyfikat SSL. Różnice pomiędzy prawdziwą a fałszywą domeną są bardzo subtelne.
Podsumowując, Client Domain Hooking w pewnych okolicznościach umożliwia przechwycenie komunikacji HTTP w przeglądarce. Technika ta zmusza przeglądarkę do komunikowania się z domeną kontrolowaną przez atakującego przez pojedyncze przechwycone żądanie HTTP — bez zrywania nowej sesji z domeną „zahaczoną”. Atak został pierwotnie zaimplementowany w oprogramowaniu „Modlishka”, które stworzył Piotr Duszyński. W obecnej formie technika Client Domain Hooking została nieco zmodyfikowana.
Problemem są źle zabezpieczone aplikacje i serwery
Odkrycie Piotra Duszyńskiego uwydatnia następujący problem: deweloperzy aplikacji bazujących na przeglądarce oraz administratorzy serwerów WWW nie stosują mechanizmu HSTS. Oba te obszary powinny ze sobą współgrać, aby nie pozostawiać luki bezpieczeństwa. Należy na szeroką skalę zaadaptować HSTS-preload.
HTTP Strict Transport Security zabezpiecza serwery WWW przed obniżeniem poziomu szyfrowania. Składa się z nagłówka HTTP z kilkoma parametrami, które „mówią” przeglądarkom internetowym, aby zmieniły połączenie z HTTP na HTTPS i wyświetliły wszystkie ostrzeżenia SSL z kodami błędów, jeżeli nie można wyświetlić strony.
Jeżeli użytkownik przy pierwszym połączeniu do serwera nie jest chroniony (np. przez VPN), to pojawia się problem. Jego przeglądarka dopiero po zobaczeniu nieszyfrowanego nagłówka wie, jak ma się dalej zachowywać.
HSTS-preload i brak ruchu „non-TLS” jest sposobem na atak Client Domain Hooking.
Aktualnie jedynie HSTS-preload i brak ruchu „non-TLS” zapewni odpowiedni poziom bezpieczeństwa, ale dodatkowe zabezpieczenia powinny być również stosowane (są wyszczególnione w raporcie).
— wyjaśnia ekspert, Piotr Duszyński.
Protokół HSTS z parametrem preload powinny wdrożyć na przykład banki oraz instytucje finansowe czy sklepy internetowe, gdzie istnieje ryzyko kradzieży danych, a także deweloperzy aplikacji webowych bazujących na przeglądarce (również aplikacje mobilne korzystające z tzw. WebView).
Do przechwycenia całego ruchu wystarczy często jeden nieszyfrowany pakiet HTTP (przy czym istnieją również inne metody na osiągnięcie tego efektu, takie jak XSS, DNS Cache Poisoning) i nie wymaga to ciągłego aktywnego ataku na poziomie sieci.
— dodaje ekspert.
W chwili przechwycenia cały ruch przeglądarki w ramach ustanowionej sesji będzie przesyłany przez serwer osoby atakującej. Zagrożone są wszystkie aplikacje oparte na przeglądarkach oraz strony internetowe, a zwłaszcza te, które wcale nie korzystają z mechanizmu HSTS czy HSTS-preload. W efekcie aplikacja zostanie przekierowana na domenę atakującego.
- Szczegółowe informacje o ataku są dostępne na blogu Piotra Duszyńskiego: https://blog.duszynski.eu
- Nagłówki pod kątem HSTS można sprawdzić na stronie: https://hstspreload.org
WebView i PunyCode — kiedy nie wiadomo co ukrywa się w pasku adresu URL
Atak typu Client Domain Hooking powoduje duże pole do nadużyć. Hackerzy, łącząc kilka technik socjotechnicznych, mogą przekonać ofiarę do odwiedzenia prawdziwego portalu, ale pod inną domeną. Do zmanipulowania adresu URL można wykorzystać konwersję znaków z PunyCode do znaków obsługiwanych przez serwery DNS. A więc da się zarejestrować domenę bardzo przypominającą dużą znaną firmę:
W nieco inny trick da się wyposażyć aplikacje mobilne. Komponent WebView bazuje na Chrome i umożliwia aplikacjom na Androida wyświetlanie treści internetowych w dowolnej aplikacji (nie musi to być przeglądarka). WebView stwarza pole do nadużyć, ponieważ może być tak zaprogramowane, by nie wyświetlało pasku adresu URL.
Jak się chronić przed Client Domain Hooking?
W sieciach lokalnych ryzykowne jest logowanie się do portali lub zasobów nieszyfrowanymi połączeniami. Zalecane jest używanie VPN. Jest to jeden ze sposobów na ochronę przed Client Domain Hooking, ale tylko w sytuacjach, zanim atak się rozpocznie. Jeśli dojdzie do przechwycenia nieszyfrowanego nagłówka HTTP, to wówczas nie ma ograniczeń, gdzie aplikacji zostanie przekierowana lub czy są stosowane nagłówki HSTS.
Mechanizm HSTS ma za zadanie ograniczyć możliwość przechwycenia pierwszego pakietu i w efekcie zahaczenia domeny klienta. Przy czym to tylko przeciwdziała wówczas, gdy atakujący chce uzyskać pierwszy pakiet poprzez atak MiTM. Aby użytkownicy byli zupełnie bezpieczni deweloperzy aplikacji i administratorzy serwerów powinni korzystać z HSTS-preload i całkowicie zrezygnować z innego ruchu niż po TLS.
A co z VPN? Szyfrowany tunel nie zabezpiecza przed atakiem, jeżeli domena została już wcześniej „zahaczona” albo firmowy serwer DNS / router został wcześniej zainfekowany, a adresy DNS zmienione.
Ekspert zaleca, aby oprócz włączenia reguły HSTS aplikacje i serwery powinny ze sobą współgrać tj. muszą respektować mechanizm HSTS z parametrem preload i najlepiej, aby ruch nieszyfrowany był zabroniony pomiędzy klientem a serwerem.
