NFsec Logo

Atakowanie prywatnych sieci dzięki DNS rebinding

10/03/2019 (3 tygodnie temu) w Ataki Internetowe Brak komentarzy.  (artykuł nr 680, ilość słów: 2331)

D

omowa sieć WiFi to nasze święte miejsce. Nasz skromny kawałek cyberprzestrzeni. Tam podłączamy nasze telefony, laptopy i inne „inteligentne” urządzenia ze sobą i internetem. Jeszcze nie ma końca dwa tysiące dwudziestego roku, a nasze sieci lokalne zostały zaludnione przez rosnącą liczbę urządzeń. Od inteligentnych telewizorów i odtwarzaczy multimedialnych po asystentów domowych, kamery bezpieczeństwa, lodówki, zamki do drzwi i termostaty – nasze LANy stały się schronieniem dla zaufanych urządzeń osobistych i domowych. Wiele z tych urządzeń oferuje ograniczone lub żadne uwierzytelnianie w celu uzyskania dostępu i kontrolowania swoich usług. Z natury ufają one innym urządzeniom w sieci w taki sam sposób, w jaki z własnej woli ufalibyście komuś, komu pozwoliliście znaleźć się w Waszym domu. Korzystają z takich protokołów, jak Universal Plug and Play (UPnP) i HTTP, aby swobodnie komunikować się między sobą, ale są z natury chronione przed połączeniami przychodzącymi z internetu za pomocą zapory ogniowej routera. Można porównać to do ogrodu otoczonego murem. Niestety wystarczy podążenie za złym linkiem, aby umożliwić atakującemu dostanie się do wewnętrznej sieci i uzyskanie kontroli nad różnego rodzaju urządzeniami.

Aby lepiej zrozumieć, jak działa DNS rebinding (ponowne związanie z DNSem) warto najpierw zrozumieć mechanizm bezpieczeństwa, który obchodzi: SOP (ang. Same-Origin Policy) przeglądarek, czyli ograniczenie komunikacji pomiędzy dokumentami pochodzącymi z różnych źródeł. Gdzie źródło = protokół + host + port (np. https://ofiara.domena.org:443). Jakiś czas temu dostawcy przeglądarek zadecydowali, że dobrym pomysłem będzie, aby strony internetowe serwowane z jednej domeny nie mogły wykonywać dowolnych żądań do innej domeny bez wyraźnej zgody tej drugiej. Czyli jeśli podążymy, za szkodliwym odnośnikiem to strona internetowa na którą wejdziemy nie powinna być w stanie przesłać żądania HTTP do internetowej strony naszego banku i wykorzystać już istniejącą sesję do logowania w celu opróżnienia naszego konta. Przeglądarki ograniczają to zachowanie poprzez limitowanie żądań HTTP tylko do zasobów zlokalizowanych w tej samej domenie (lub innej, która jawnie ma włączony mechanizm współużytkowania zasobów pochodzących z innych źródeł – Cross-Origin Resource Sharing – CORS).

Niestety DNS może zostać wykorzystany do oszukania przeglądarek internetowych w celu komunikowania się z serwerami, z którymi nie zamierzały. Skoro już wiemy, że szkodliwy kod znajdujący się na stronie http://cyber.porywacze nie może wykonać standardowego żądania XMLHttpRequest do https://bank.pl/przelew-krajowy, ponieważ dla przeglądarki są to dwa różne źródła. Przeglądarki wymuszają to wymagając, aby protokół (https), nazwa domeny (bank.pl) i numer portu (:443) był identyczny z adresem URL strony wysyłającej żądanie. Brzmi nieźle, prawda? Nie tak szybko. Za każdą nazwą domeny znajduje się adres IP. cyber.porywacze mogą znajdować się pod adresem: 35.195.225.45, a bank.pl: 175.155.225.155. System DNS (ang. Domain Name System) zapewnia przydatny mechanizm tłumaczenia łatwych do zapamiętania nazw domen na adresy IP, z których nasz komputer faktycznie korzysta, aby rozmawiać z innymi. Haczyk jest w tym, że współczesne przeglądarki używają adresów URL do oceny polityki SOP, a nie adresów IP. Więc co by się stało, gdyby adres IP złośliwej witryny internetowej został szybko zmieniony z 35.195.225.45 na 175.155.225.155? Według przeglądarki nic by się nie zmieniło. Tylko teraz, zamiast komunikować się z serwerem, który pierwotnie hostował szkodliwe pliki na stronie internetowej, Twoja przeglądarka faktycznie będzie rozmawiać z bankiem. Widzisz problem? DNS może być wykorzystany do oszukiwania przeglądarek internetowych w celu komunikowania się z serwerami, z którymi wcale nie zamierzały.

DNS rebinding umożliwia zdalnemu atakującemu ominięcie zapory ogniowej ofiary i wykorzystanie jego przeglądarki jako serwera proxy do bezpośredniej komunikacji z urządzeniami w ich prywatnej sieci domowej.

Jak działa DNS rebinding?

1) Osoba atakująca jest pod kontrolą serwera DNS, który odpowiada na zapytania dotyczące złośliwej domeny pewna.wygrana.pl.
2) Atakujący nakłania użytkownika do odwiedzenia strony https://pewna.wygrana.pl w przeglądarce. Może do tego dojść za pomocą phishingu, XSS lub wykupieniu reklamy internetowej.
3) Po tym, jak ofiara podąży za linkiem jej przeglądarka wyśle zapytanie DNS, szukając adresu IP dla domeny pewna.wygrana.pl. Po otrzymaniu żądania DNS od ofiary, serwer DNS kontrolowany przez atakującego odpowie rzeczywistym adresem IP np. 35.195.225.45, ale ustawiając także wartość TTL na 1 sekundę, aby przeglądarka i komputer ofiary nie zapisywała jej na długo.
4) Ofiara ładuję zawartość strony z https://pewna.wygrana.pl, która zawiera złośliwy kod JavaScript. Wykonuje on się w przeglądarce internetowej ofiary. Strona nagle zaczyna wielokrotnie powtarzać dziwne żądania HTTP typu POST do adresu https://pewna.wygrana.pl z ładunkiem w formacie JSON o zawartości: {"tmode": 1, "a_heat": 35}.
5) Początkowo te żądania są wysyłane do serwera WWW atakującego działającego pod adresem IP 35.195.225.45, ale po pewnym czasie (pamięć podręczna przeglądarek jest dziwna) resolver przeglądarki zauważa, że wpis DNS dla domeny pewna.wygrana.pl jest nieaktualny i dlatego wykonuje kolejne zapytanie DNS.
6) Serwer DNS atakującego odbiera drugie żądanie DNS ofiary, ale tym razem odpowiada, że domena pewna.wygrana.pl posiada adres IP: 192.168.1.75, który tak się składa jest adresem IP inteligentnego termostatu w sieci lokalnej ofiary.
7) Tym razem żądania POST (z pkt. 4) zostają wysyłane do małego niezabezpieczonego serwera WWW działającego w termostacie podłączonym do sieci WiFi ofiary. Termostat przetwarza żądanie, a temperatura w domu ofiary jest ustawiona na 35C stopni.

Powyżej został opisany prosty scenariusz eksploracji luki w Radio Thermostat CT50 przy pomocy ataku DNS rebinding. Konsekwencje i wpływ takiego ataku mogą mieć daleko idące i niszczycielskie skutki dla urządzeń lub usług działających w sieci lokalnej. Wykorzystując przeglądarkę internetową ofiary jako pewnego rodzaju serwer proxy HTTP, ataki ponownego związania z DNSem mogą ominąć zapory sieciowe dostając się do „inteligentnych” urządzeń (TV, zamki, termostaty, lodówki, domowi asystenci) w chronionym intranecie, a nawet udostępnić je na zewnątrz w internecie.

Jak się bronić?

1) Zacznijmy od faktu, skąd atakujący może się dowiedzieć jaki adres ma nasza sieć lokalna? Mówi mu o tym sama przeglądarka za pomocą WebRTC.

Web Real-Time Communication (WebRTC) to zbiór standardowych technologii, które pozwalają przeglądarkom internetowym komunikować się ze sobą bezpośrednio, bez potrzeby korzystania z serwera pośredniczącego. Zalety WebRTC obejmują: szybszą prędkość i mniej lagów w przypadku aplikacji internetowych, takich jak czat wideo, przesyłanie plików oraz streaming na żywo. Jednak dwa urządzenia, które komunikują się ze sobą bezpośrednio za pośrednictwem WebRTC muszą znać wzajemnie swoje rzeczywiste adresy IP. Teoretycznie może to pozwolić osobie trzeciej na wykorzystanie WebRTC w przeglądarce do wykrycia Twojego prawdziwego adresu IP i użycia go do zidentyfikowania Cię. Nazywamy to właśnie wyciekiem WebRTC. – ExpressVPN.

Dlatego warto wyłączyć ten mechanizm lub kontrolować go za pomocą odpowiednich wtyczek dla przeglądarek.

2) Pewnie nie zaskoczy nas fakt, że historycznie to routery sieciowe były jednym z najczęstszych celów ataków. To dlatego, że routery sieciowe trzymają klucze do prywatnego królestwa. Przejmując router, przejmujemy sieć. Istnieją dwa typowe wektory ataku, które mogą nastąpić: Pierwszym jest wysyłanie standardowych danych logowania np. do http://192.168.1.1/login. Po poprawnym uwierzytelnieniu osoba atakująca ma pełną kontrolę nad urządzeniem i może je skonfigurować według własnego uznania. Drugim natomiast jest wykorzystanie interfejsu IGD (ang. Internet Gateway Device) za pośrednictwem UPnP w celu skonfigurowania przekierowania portów UDP oraz TCP i publicznego udostępnienia ich od strony internetu. Pierwszy jest dość prosty. Wiele routerów jest dostarczanych z domyślnymi danymi logowania, a konsumenci nigdy ich nie zmieniają. Pewnie, że mogą włączyć szyfrowanie WPA2 i ustawić hasło WiFi, ale wielu z nich nie zdaje sobie sprawy, że panel administracyjny routera nadal jest dostępny dla każdego w sieci przy użyciu danych admin:admin. Drugi atak jest jeszcze gorszy. Nawet w dzisiejszych czasach większość nowych, domowych routerów nadal jest domyślnie dostarczanych z włączonymi serwerami UPnP. Umożliwiają one administracyjną kontrolę nad konfiguracją routera dowolnej, nieuwierzytelnionej maszynie w sieci za pośrednictwem protokołu HTTP. Dlatego dowolny komputer w sieci lokalnej lub od strony internetu (za pośrednictwem ataku DNS rebinding i nie tylko) może wykorzystać IGD / UPnP do skonfigurowania serwera DNS routera, dodawać i usuwać mapowania portów NAT i WAN, czy przeglądać liczbę wysłanych / odebranych bajtów w sieci. IGD zapewnia także interfejs do wykrywania publicznego adresu IP routera za pomocą prostego nieuwierzytelnionego żądania HTTP. Ta funkcja, w połączeniu z ponownym związaniem z DNSem może zostać wykorzystana do de-anonimizacji użytkowników, którzy próbują zamaskować swój publiczny adres IP poprzez VPN lub TOR. Niektóre routery całkowicie blokują tego rodzaju ataki, inne wybierają losowo swój port serwera UPnP, aby je utrudnić, no i są te, które są całkowicie otwarte na atak. Dlatego na samym początku zawsze należy zmienić standardowe dane uwierzytelniające do danego urządzenia. Warto również poważnie rozważyć wyłączenie dziurawego UPnP na rzecz manualnego puszczania ruchu poprzez firewall.

3) Kolejną kwestią są odpowiedzi z serwerów DNS. Powinniśmy korzystać z takich serwerów DNS, które nie pozwalają na wysyłanie odpowiedzi o publiczne domeny z prywatnymi adresami IP. Możemy też sami filtrować, aby odpowiedzi z prywatnymi adresami IP nie przychodziły do nas od strony publicznego interfejsu. Można to porównać do mechanizmu rp_filter (ang. Reverse Path Filtering) net.ipv4.conf.default.rp_filter / net.ipv4.conf.all.rp_filter, czyli metody używanej przez jądro systemu Linux w celu zapobiegania atakom wykorzystywanym do fałszowania adresów IP. Zapewnia ona zrzucanie pakietów, które nie są rutowalne / trasowalne. Najprostszym przykładem będzie pakiet z prywatnym adresem IP z zakresu 10.0.0.0/8, który zostanie odebrany na publicznym interfejsie routera. Tych pakietów nie można przekierować do internetu i nie powinny one się pojawić od tej strony. Analogicznie jest z serwerami DNS – te które obsługują publiczne domeny internetowe nigdy nie powinny odpowiadać z prywatnymi adresami IP dla tych domen, jak i rekordów subdomen – jest to błąd w konfiguracji takiego serwera DNS.

4) Przeglądarki próbują się bronić przed DNS rebinding techniką zwaną DNS pinning (przypięcie do DNS). Następuje ona wtedy, gdy przeglądarka buforuje sobie parę domena:adresIP na czas życia całej sesji, nie zwracając uwagi na wartość TTL dla rekordu DNS. Więc jeśli nawet życie danego rekordu jest ustawione np. na 20 sekund, DNS pinning przeglądarki zapisze sobie informację z DNS do czasu aż przeglądarka zostanie zamknięta. Czyli zgodnie z przykładem działania ataku powyżej – przeglądarka nie spyta się za drugim razem o adres domeny pewna.wygrana.pl, nawet jeśli jej czas życia rekordu właśnie wygasł. Niestety i ten mechanizm posiada lukę. 14 sierpnia 2006 roku Martin Johns opublikował metodę anti-DNS pinning. Bazuje ona na jednym prostym fakcie: aby nasza przeglądarka nie wykonała drugiego zapytania – serwer, z którym się komunikuje musi być cały czas dostępny. Więc jeśli w odpowiednim momencie atakujący zgasi lub wytnie połączenia do strony to przeglądarka zapyta się ponownie serwera DNS o dany rekord upewniając się, czy przypadkiem serwer WWW nie został gdzieś w między czasie przeniesiony. O ile koncepcja ta jest dobra dla użyteczności przeglądarki to jest fatalna od strony bezpieczeństwa.

5) Inną skuteczną metodą psucia ataków ponownego związania z DNSem jest użycie protokołu HTTPS zamiast HTTP, nawet w przypadku lokalnych połączeń sieciowych. Jeśli nasz router / inteligentne urządzenie po wystąpieniu ponownego zapytania DNS i związania lokalnego adresu IP z szkodliwą domeną – będzie miało certyfikat SSL, który nie jest prawidłowy dla złośliwej witryny internetowej to ostrzeże o błędzie w zabezpieczeniach użytkownika blokując tym samym złośliwe żądanie. Do utrudnienia ataku możemy też wykorzystać poprawną obsługę nagłówka Host. Proste serwery HTTP używane wewnątrz sieci nie sprawdzają nawet poprawności nagłówka Host. Nagłówek ten jest zawarty we wszystkich żądaniach HTTP wysyłanych z przeglądarki i zawiera host serwera, z którym spodziewa się komunikować. Jego wartością może być nazwa domeny lub adres IP, ale w obu przypadkach serwer, który odbierze żądanie, powinien sprawdzić, czy jego własny host odpowiada żądanemu hostowi. Ponieważ atak DNS rebinding polega na zmianie podstawowego adresu IP powiązanego z nazwą domeny, nagłówek hosta zawarty w szkodliwym żądaniu HTTP zachowa oryginalną nazwę domeny jako wartość nagłówka Host. Dlatego złośliwe żądanie POST np. do strony logowania routera będzie miało wartość nagłówka Host, która nie będzie odpowiadać nazwie hosta lub adresowi IP routera w sieci. Czyli żądanie miałoby postać: Host: pewna.wygrana.pl, a nie Host: router.lan. Gdyby serwery WWW sprawdzały, czy żądany nagłówek hosta dokładnie odpowiada oczekiwanej wartości to mogłyby reagować za pomocą odpowiednich kodów HTTP np. 403. Niestety powszechne wgrywanie i aktualizacja certyfikatów SSL lub dostępna opcja typu: Host header strict checking na prostych, domowych routerach, czy innych urządzeniach jest odległą przyszłością.

Podsumowanie:

Atak ponownego związania z DNSem otrzymał kilka krótkich chwil uwagi w ciągu poprzedniego roku, kiedy wykryto luki w kilku popularnych programach. Przede wszystkim gry wideo firmy Blizzard, klient protokołu torrent Transmission oraz kilka portfeli kryptowalutowych było podatnych na ataki DNS rebinding. Niestety w czasach przeładowania sieci lokalnych różnymi urządzeniami, które nie są zabezpieczone już na etapie projektowania atak ten stanowi dość poważne zagrożenie.

Potrzebujemy, aby programiści pisali oprogramowanie, które traktuje lokalne sieci prywatne tak, jakby były wrogimi sieciami publicznymi.

Wszystkie powyżej opisane sposoby łagodzenia lub przeciwdziałania temu atakowi byłyby zbędne, gdyby każde urządzenie w sieci wewnętrznej było dodatkowo zabezpieczone i nie ufało ślepo różnym klientom. Od momentu już samego wytwarzania oprogramowania najlepszym rozwiązaniem przed potencjalnym zakłóceniem istniejącej usługi w tego typu urządzeniach jest dodanie do interfejsów API pewnej formy uwierzytelniania użytkownika. Jeśli dany interfejs API kontroluje funkcjonalność, która ma wpływ na świat rzeczywisty lub zapewnia dostęp do poufnych informacji to powinien on być dostępny tylko dla zaufanych podmiotów. Jeśli będzie dostępny dla całej sieci prywatnej to równie dobrze może być dla internetu. Nie ma absolutnie żadnego powodu, aby jakiekolwiek urządzenie w sieci WiFi mogło dowolnie kontrolować ciepło w naszym mieszkaniu. Ludzie nawet zapominają, jak łatwo jest złamać WiFi WPA2.

Więcej informacji: Attacking Private Networks from the Internet with DNS Rebinding, Protecting Browsers from DNS Rebinding Attacks, Interactive DNS Rebinding, Intranet Invasion Through Anti-DNS Pinning

Kategorie K a t e g o r i e : Ataki Internetowe

Tagi T a g i : , , , , , , , , , ,

Komentowanie tego wpisu jest zablokowane.