Dzisiejszy artykuł to pierwszy z dwóch, w których przedstawimy nieco odmienną i interesującą koncepcję ataku na usługi WWW w sieci lokalnej. Pokażemy w jaki sposób za pomocą protokołu DNS, będziemy w stanie zaatakować z poziomu Internetu portal administracyjny udostępniany przez router znajdujący się w sieci lokalnej oraz wyciągniemy z niego hasło do Wifi. Pokażemy przykład phishingu ukierunkowanego na określony typ usługi WWW (oczywiście podatnej na atak) – w naszym przypadku dobijemy się do portalu WWW wystawianego w sieci lokalnej przez router UPC. W następnej części w, ramach kontynuacji tego artykułu pokażemy i udowodnimy, jak ważne jest bezpieczeństwo lokalnych usług WWW i aplikacji wystawiających dostęp API. Pod koniec zwrócimy uwagę na bezpieczeństwo pracy użytkownika na komputerze i na bezpieczeństwo w sieci firmie.
Wstęp
O tym, że należy odpowiednio zabezpieczyć router z funkcją Wifi i inne urządzenia udostepniające portal do zarządzania w sieci lokalnej, nie musimy nikomu tłumaczyć. Nawet mało „wprawiony w bezpieczeństwo” atakujący (script kiddie) może narobić wielu problemów w lokalnych sieciach. W naszym poprzednim artykule dotyczącym niezabezpieczonego routera z Wifi od UPC pokazaliśmy, jak może to zrobić. Poprzedni scenariusz z wykradaniem haseł z routera zakładał, że osoba atakująca znajduje się w tej samej sieci lokalnej jak podatny portal. W tym artykule pokażemy, że niekoniecznie tak musi być i atak można przeprowadzić z Internetu wysyłając jedynie użytkownikowi link do odpowiednio spreparowanej strony (zawierającej odpowiedni skrypt w JavaScript). Do przeprowadzenia ataku użyjemy środowiska Singularity, którego źródła dostępne są do pobrania w Internecie. Specjalnie wybraliśmy to narzędzie, ponieważ używa ono techniki ataku ponownego wiązania DNS zwanej po ang. DNS Rebinding, która jest niewykrywalna przez systemy do bezpieczeństwa. Całość opiszemy dokładniej poniżej. Zatem do dzieła!
Jak oszukać zabezpieczenia przeglądarki i DNS? Dlaczego DNS Rebinding?
O próbach wykradania informacji/danych przez DNS (infiltracja i eksfiltracja) pisaliśmy dużo na Kapitanie Hack’u tutaj, przytaczając odpowiednie przykłady, pisząc skrypty i atakując komputery. DNS podobnie jak inne egzotyczne protokoły ma kilka zalet dla cyberprzestępców. Przede wszystkim jest ogólnodostępny (w firmach i w sieciach domowych) i jest włączony w większości urządzeń dla których chcemy, aby obsługiwały rozwiązywanie nazw domenowych – praktycznie bez niego urządzania miałyby z tym problem. Standardowo jego obsługa jest włączona na routerach od dostawców ISP i nie tylko – adresy IP serwerów DNS są najczęściej automatycznie przydzielane przez usługę DHCP dla innych urządzeń/komputerów łączących się do sieci. Po drugie uważamy, że jest on nadal słabo monitorowany przez specjalistyczne rozwiązania do Security, czy wręcz nawet pomijany w monitorowaniu wśród wielu firm. W związku z zagrożeniami jakie zaczęły pojawiać się na Świecie związanych z DNS wymyślono coś takiego jak DNS-over-HTTP(S) (w skrócie DoH), aby jeszcze bardziej skomplikować życie cyberprzestępcom. Więcej informacji o DoH pisaliśmy w naszym poprzednim artykule tutaj. Zanim przejdziemy do omówienia techniki atakowania zwanej DNS Rebinding najpierw wyjaśnijmy, jak radzą sobie przed próbami ataków przeglądarki internetowe.
Co to jest same-origin policy?
Same-origin Policy (zasada pochodzenia tego samego źródła) to w wielkim skrócie funkcja bezpieczeństwa przeglądarki, która ogranicza sposób interakcji dokumentów i skryptów w jednym źródle adresu URL z zasobami w innym źródle (URL). Przeglądarka internetowa może ładować i wyświetlać zasoby z wielu witryn jednocześnie. Przeglądając Internet w jej zakładkach możesz mieć jednocześnie otwartych kilka adresów stron(witryn) lub sama witryna (dokument) może osadzać wiele ramek „iframe” z różnych witryn. Jeśli nie ma żadnych ograniczeń interakcji między tymi zasobami (dokumentami witryn), a atakujący umieścił na jednej z nich złośliwy skrypt, wówczas może on ujawnić wszystko w przeglądarce użytkownika. Dwa adresy URL są tego samego pochodzenia (mają ten sam origin), jeśli oba posiadają taki sam są schemat (protokół), host (adres IP lub nazwa) i port (jeśli jest wyszczególniony).
Przykładowo strony o adresach URL https://www.kapitanhack.pl/index.html i https://www.kapitanhack.pl/stary.html maja ten sam origin. Zaś strony https://www.kapitanhack.pl/index.html oraz https://www.onet.pl/index.html już nie, ponieważ różnią się w jednym ze składników – host’em. Przeglądarki zezwalają na interakcje pomiędzy różnymi źródłami (origins), jeśli jest to:
- Odwołanie w postaci linków
- Przekierowanie na inną stronę (redirect)
- Osadzanie treści z innego origin (np. CSS, JavaScript)
- Przesyłanie formularzy
Logiczne jest więc, że przeglądarka będzie blokowała dostęp wszystkich skryptów, ciasteczek i innych rzeczy strony kapitanhack.pl do onet.pl i na odwrót. Warto również zwrócić uwagę na to, że przeglądarka nie zezwala na tzw. odczyty Cross-Origin (CORS), czyli czytanie zawartości dokumentu HTML strony jednej witryny z poziomu drugiej. Innymi słowy mając w jednej zakładce przeglądarki otwartą stronę atakującego o nazwie „atak.pl”, a w drugiej pocztę na „gmail.com”, to strona atakującego nie będzie mogła uzyskać dostępu (odczytów) do maili użytkownika na gmail’u. Opisany przez nas atak używający DNS Rebinding pozwoli na ominięcie same-origin policy w przeglądarce i dzięki niemu będziemy mogli uzyskać dostęp ze strony odpalanej z Internetu (strona atakującego) do wewnętrznej strony w sieci lokalnej (strona atakowana).
DNS Rebinding
Jeśli już wiemy o co chodzi z same-origin policy możemy przejść do samego ataku DNS Rebinding.
DNS Rebinding z pewnością nie jest najnowszym atakiem w dziecinie cybersecurity, ale nadal może spustoszyć i skompromitować wiele sieci komputerowych poprzez podatne w nich usługi WWW lub wystawiane przez aplikacje API. Z powodu jego skomplikowanej metody działania i rzadkości występowania dużo osób zajmujących się cyberbezpieczeństwem mogło o nim jeszcze nie słyszeć. Zobaczmy poniżej na czym on polega.
Atak wykorzystujący tę metodę polega na ponownym powiązaniu zapytania DNS skierowanego do aplikacji internetowej lub interfejsu API atakującego, który kontroluje stronę internetową lub serwer WWW oraz domenę DNS. Atakujący może przekonać ofiarę używając socjotechniki, do odwiedzenia jego strony internetowej. Serwer DNS atakującego odpowiada na początkowe zapytanie przeglądarki adresem IP serwera domeny kontrolowanej przez atakującego, podając adres złośliwego serwera WWW atakującego (serwer C2).
Po połączeniu z serwerem internetowym atakującego przeglądarka pobiera i wykonuje plik JavaScript znajdujący się na jego zainfekowanej stronie. Skrypt ten ma na celu ciągłe przeszukiwanie strony internetowej w celu wykrycia, że nie ma ona nawiązanej już sesji z domeną atakującego, ale zamiast tego z komputerem ofiary.
Po pewnym czasie pozycja pamięci podręcznej DNS dla domeny atakującego wygasa (ustawiony niski parametr TTL rekordu w DNS), co powoduje, że przeglądarka wysyła ponowienie kolejne żądanie dotyczące domeny atakującego. Tym razem domena atakującego (tak naprawdę jego serwer DNS) odpowiada w zapytaniu innym adresem IP wskazującym na adres aplikacji docelowej, która może być wrażliwą usługą powiązaną z hostem lokalnym na komputerze użytkownika ofiary lub wrażliwą usługą w sieci wewnętrznej, do której komputer użytkownika ofiary ma dostęp. Złośliwy skrypt atakującego może teraz w pełni współdziałać z aplikacją ofiary. Pozwala to atakującemu na wykonanie dowolnych żądań do interfejsu docelowego i odczytanie jego odpowiedzi.
Usługa DNS Rebinding umożliwia wysyłanie poleceń do systemów znajdujących się za firewallem (zaporą ogniową ofiary) czyli w lokalnej sieci, pod warunkiem, że w jakiś sposób dotarły one do domeny, którą zarządza atakujący, z prośbą o zasób oraz strona atakującego może uruchomić skrypt JavaScript w przeglądarce ofiary.
Jeśli powyższy opis jest zbyt skomplikowany i zawiły najlepiej wyjaśnić go na żywym przykładzie.
Przykład działania DNS Rebinding:
Załóżmy, że jesteśmy właścicielem domeny kapitanhack.space. Wykonujemy następujące kroki:
- Prosimy użytkownika (ofiarę) w sieci o wysłanie żądania do naszej domeny (kliknięcie na link http://kapitanhack.space).
- Serwer DNS, na którym znajduje się nasza domena zwróci ofierze odpowiedź, którą zmapuje nazwę kapitanhack.space na adres IP – powiedzmy: 1.2.3.4.
- Skoro jesteśmy właścicielami domeny to mamy prawo do tego, aby zmieniać jej rekordy (specjalne wpisy i parametry) w usłudze DNS. Jeśli dodatkowo ustawimy we wpisach(rekordach) naszej domeny kapitanhack.space specjalny parametr TTL odpowiadający za czas odpowiedzi na bardzo niską wartość np. 5 sekund, to zmusimy system operacyjny (przeglądarkę ofiary) do ciągłego sprawdzania co 5s jaki adres IP zwróci odpowiedź serwera DNS na której jest nasza domena kapitanhack.space.
- Wiemy, że ofiara ma określony typ systemu w swojej sieci wewnętrznej – na przykład router lub urządzenie IoT, które chcielibyśmy zaatakować i przejąć nad nim kontrolę. Jeśli podatne urządzenie znajduje się w tej samej sieci co komputer ofiary możemy na naszej stronie kapitanhack.space użyć złośliwego kodu napisanego w JavaScript, który uruchomi się po stronie przeglądarki ofiary żądanie do naszego serwera C2, który jest tez naszym drugim serwerem DNS o IP 5.6.7.8. Np. skrypt wyśle żądanie: http://kapitanhack.space/set-dns-server?server=5.6.7.8
- Kiedy to polecenie zostanie wysłane po raz pierwszy, zostanie przesłane do użytkownika na adres IP 1.2.3.4, ponieważ to był początkowy adres IP, który wysłaliśmy ofierze dla kapitanhack.space. Następnie, gdy klient (przeglądarka ofiary) zaktualizuje rekord DNS (w ciągu 5 sekund, ponieważ właśnie na to ustawiliśmy TTL), w kolejnej odpowiedzi zwróci adres IP: 192.168.1.1. Zatem przeglądarka ofiary następnie wysyła http:// kapitanhack.space /set-dns-serwer?serwer= 5.6.7.8 do 192.168.1.1.
- Jeśli router jest podatny na wysyłane przez Ciebie dane (być może używa domyślnych poświadczeń), zaktualizuje parametr Host w nagłówku żądania dokumentu HTML, aby wskazywał na serwer C2.
Dlaczego przeglądarka zezwala na takie połączenie? Ponieważ zachowany jest to same źródło „Origin” http://kapitanhack.space, natomiast zmienił się w zapytaniach jedynie adres IP serwera. Odnośnie sprawdzania zmieniającego się adresu IP na lokalny i zabezpieczeń przed tym powiemy później.
Powyższe kroki zobrazowaliśmy na poniższym schemacie.
Więcej na temat techniki DNS Rebinding oraz przykłady jakie urządzenia można za jej pomocą atakować możecie poczytać w artykule Attacking Private Networks from the Internet with DNS Rebinding
Więcej napiszemy i zasymulujemy atak w następnym artykule – „Niewykrywalny atak na lokalne usługi za pomocą narzędzia Singularity”