- Dołączył
- 26 Maj 2015
- Posty
- 19209
- Reakcje/Polubienia
- 55912
źródło:Domowa 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 (Zaloguj lub Zarejestruj się aby zobaczyć!) 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 zaZaloguj lub Zarejestruj się aby zobaczyć!, 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.Zaloguj lub Zarejestruj się aby zobaczyć!) przeglądarek, czyli ograniczenie komunikacji pomiędzy dokumentami pochodzącymi z różnych źródeł. Gdzie źródło = protokół + host + port (np.Zaloguj lub Zarejestruj się aby zobaczyć!). 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ł –Zaloguj lub Zarejestruj się aby zobaczyć!– 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 stronieZaloguj lub Zarejestruj się aby zobaczyć!nie może wykonać standardowego żądaniaZaloguj lub Zarejestruj się aby zobaczyć!doZaloguj lub Zarejestruj się aby zobaczyć!, 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. SystemZaloguj lub Zarejestruj się aby zobaczyć!(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.
Jak działa DNS rebinding?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.
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 stronyZaloguj lub Zarejestruj się aby zobaczyć!w przeglądarce. Może do tego dojść za pomocąZaloguj lub Zarejestruj się aby zobaczyć!,Zaloguj lub Zarejestruj się aby zobaczyć!lub wykupieniuZaloguj lub Zarejestruj się aby zobaczyć!.
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śćZaloguj lub Zarejestruj się aby zobaczyć!na 1 sekundę, aby przeglądarka i komputer ofiary nie zapisywała jej na długo.
4) Ofiara ładuję zawartość strony zZaloguj lub Zarejestruj się aby zobaczyć!, która zawiera złośliwy kod JavaScript. Wykonuje on się w przeglądarce internetowej ofiary. Strona nagle zaczyna wielokrotnie powtarzać dziwne żądania HTTP typuZaloguj lub Zarejestruj się aby zobaczyć!do adresuZaloguj lub Zarejestruj się aby zobaczyć!z ładunkiem w formacieZaloguj lub Zarejestruj się aby zobaczyć!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 (Zaloguj lub Zarejestruj się aby zobaczyć!Zaloguj lub Zarejestruj się aby zobaczyć!) 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.plposiada adres IP: 192.168.1.75, który tak się składa jest adresem IPZaloguj lub Zarejestruj się aby zobaczyć!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 eksploracjiZaloguj lub Zarejestruj się aby zobaczyć!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,Zaloguj lub Zarejestruj się aby zobaczyć!, termostaty, lodówki, domowi asystenci) w chronionym intranecie, a nawetZaloguj lub Zarejestruj się aby zobaczyć!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.
Dlatego wartoWeb 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.Zaloguj lub Zarejestruj się aby zobaczyć!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 standardowychZaloguj lub Zarejestruj się aby zobaczyć!Zaloguj lub Zarejestruj się aby zobaczyć!np. doZaloguj lub Zarejestruj się aby zobaczyć!. 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 interfejsuZaloguj lub Zarejestruj się aby zobaczyć!(ang. Internet Gateway Device) za pośrednictwemZaloguj lub Zarejestruj się aby zobaczyć!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ć szyfrowanieZaloguj lub Zarejestruj się aby zobaczyć!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 doZaloguj lub Zarejestruj się aby zobaczyć!serwera DNS routera,Zaloguj lub Zarejestruj się aby zobaczyć!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 poprzezZaloguj lub Zarejestruj się aby zobaczyć!lubZaloguj lub Zarejestruj się aby zobaczyć!. 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łączenieZaloguj lub Zarejestruj się aby zobaczyć!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ą nawetZaloguj lub Zarejestruj się aby zobaczyć!nagłówkaZaloguj lub Zarejestruj się aby zobaczyć!. 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ą odpowiednichZaloguj lub Zarejestruj się aby zobaczyć!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 kilkuZaloguj lub Zarejestruj się aby zobaczyć!. Przede wszystkim gry wideoZaloguj lub Zarejestruj się aby zobaczyć!, klient protokołu torrentZaloguj lub Zarejestruj się aby zobaczyć!oraz kilka portfeliZaloguj lub Zarejestruj się aby zobaczyć!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.
Wszystkie powyżej opisane sposoby łagodzenia lub przeciwdziałania temu atakowi były by 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ćPotrzebujemy, aby programiści pisali oprogramowanie, które traktuje lokalne sieci prywatne tak, jakby były wrogimi sieciami publicznymi.Zaloguj lub Zarejestruj się aby zobaczyć!
Zaloguj
lub
Zarejestruj się
aby zobaczyć!
