Wybrany post: Atak na usługi w sieci lokalnej z Internetu za pomocą narzędzia Singularity – część 2

Po krótkim wprowadzeniu w teorię, które możecie przeczytać tutaj, zajmijmy się praktyką i opiszemy narzędzie, za pomocą którego wykonamy atak na naszą podatną witrynę dekodera UPC znajdującą się w lokalnej sieci.

Narzędzie Singularity

Singularity of Origin to przemyślane i łatwe w użyciu narzędzie do przeprowadzania ataków polegających na ponownym wiązaniu DNS. Zbudowane jest z DNS i serwera WWW, posiada też interfejs do konfigurowania i uruchamiania ładunków na komputerze ofiary celem przeprowadzenia określonego typu ataku na konkretną usługę.

Singularity zapewnia kompletną listę ataków i usług wykorzystujących DNS Rebinding:

• Własny serwer DNS, który umożliwia ponowne powiązanie nazwy DNS i adresu IP serwera WWW atakującego z docelowym adresem komputera ofiary
• Własny serwer HTTP do obsługi stron HTML i kodu JavaScript, którego celem jest atakowanie użytkowników oraz zarządzanie atakiem
• Posiada kilka przykładowych ładunków ataku, od przechwytywania strony głównej aplikacji docelowej do wykonywania zdalnego kodu. Ładunki można łatwo dostosować do przeprowadzania nowych i niestandardowych ataków.

Singularity oferuje funkcje:

• Obsługuje równoczesnych użytkowników korzystających z aplikacji.
• Zapewnia kilka strategii DNS Rebinding, w tym mapowanie sekwencyjne od atakującego na docelowy adres IP oraz mapowanie losowe, w celu zminimalizowania wpływu zakłóceń ataku przez rozwiązania do bezpieczeństwa takie jak IDS / IPS.
• Oferuje wiele technicznych kontroli w celu maksymalizacji niezawodności i szybkości ataków:
  • Wyłączanie funkcji HTTP keep alive, buforowania, wstępnego pobierania DNS.
  • Agresywne TTL dla odpowiedzi DNS.
  • Opcję użycia DNS CNAME zamiast rekordów A w celu uniknięcia kilku rozwiązań bezpieczeństwa do filtrowania DNS.
• Możliwość alokacji serwerów HTTP podczas uruchamiania lub później
• Umożliwia przeprowadzenie automatycznego skanowania wrażliwych portów.

Postanowiliśmy przetestować narzędzie Singularity i napisać do niego własny exploit na usługę WWW dekodera UPC. Wyniki możecie zobaczyć poniżej.

Scenariusz przeprowadzenia ataku przy użyciu DNS Rebinding

UWAGA! Poniższy scenariusz służy jedynie celom edukacyjnym. Nie odpowiadamy za bezprawne użycie jego przez czytelnika i nie odpowiadamy za skutki wynikające z ewentualnych konsekwencji prawnych, bądź materialnych występujących podczas jego użycia.

Od czego musimy zacząć?

Przede wszystkim musimy zakupić domenę do testów. W naszym przypadku był to serwis Gandi.net, w którym zakupiliśmy domenę „kapitanhack.space” za 5,38PLN na rok! Potrzebowaliśmy jeszcze jakiś serwer wirtualny w Internecie do testów, więc również postanowiliśmy go kupić (można też postawić we własnej sieci) w usłudze IaaS jako serwer Linux. W naszym przypadku skorzystaliśmy z serwera RedHat Linux 8.1 zainstalowanego przez nas w chmurze Microsoft Azure, ale polecamy również inne usługi dostawców takich jak AVS, Google czy OVH.
W następnym kroku przystąpiliśmy do odpowiedniej konfiguracji domeny (odpowiednie wpisy w DNS), serwera Linux (instalacja i konfiguracja Singularity).
W kolejnym kroku musimy obrać cel – podatną usługę WWW w sieci ofiary. Może to być dowolny serwis WWW urządzenia znajdującego się w lokalnej sieci np. telewizora, routera, czy nawet wystawiany przez jakąś aplikację.

W celu sprawdzenia koniecznego warunku do przeprowadzenia ataku wykorzystaliśmy polecenie „curl” i sprawdziliśmy, czy nasz dekoder Horizon od UPC jest podatny na atak.

curl -v –header “Host: kapitanhack.space” http://192.168.1.1:80/

Polecenie wykonaliśmy celem sprawdzenia, czy możemy podmienić zmienną Host w zapytaniu usługi WWW na naszym ruterze na naszą domenę. Jest to o tyle ważne, ponieważ wartość pola host w same-origin policy dla przeglądarki będzie taka sama w dokumencie HTML prezentowanym dla użytkownika pochodzącego z usługi WWW routera jak adres www serwera atakującego.

Jak się okazuje usługa routera akceptuje dowolne nagłówki hosta! – możemy działać dalej!

Ponieważ wiedzieliśmy też, że nasz testowany modem jest podatny na atak z wyciągnięciem hasła z Wifi przystąpiliśmy do napisania własnego exploit’a w JavaScript dla Singularity (payload)– skryptu pozwalającego wyłuskać nazwę sieci Wifi oraz hasło z urządzania UPC.

Do przeprowadzenia ataku na naszej ofierze – użytkowniku w sieci wymyśliliśmy phishing polegającego na przesłaniu linku do naszej strony. Taki link można przesłać mailem, SMS, na czacie w portalach społecznościowych, w dokumencie itp. Metod jest naprawdę bardzo dużo!
Po odpaleniu strony przez naszą ofiarę skrypt na stronie zajął się wszystkim:

• Sprawdził z jakiego IP komunikuje się ofiara. Jeśli IP odpowiadało dostawcy usługi UPC wówczas skrypt uruchamiał się w tle.
• Poprzez usługę DNS i technikę DNS Rebinding wyciągnął hasło i nazwę sieci Wifi z routera w lokalnej sieci użytkownika i skomunikował się z serwerem w chmurze Microsoft w celu przesłania tych informacji.

Poniżej pokazujemy scenariusz ataku w kolejnych krokach.

Krok 1 – postawienie serwera w Internecie

W tym kroku uruchomimy w Internecie nasz serwer C2. W naszym przypadku jest to Linux Red Hat Enterprise 8.1. Serwer uruchomiliśmy w usłudze Microsoft Azure i skonfigurowaliśmy w niej dodatkowo porty UDP 53, SSH(TCP) 22 oraz HTTP(TCP) 80, aby były one dostępne z zewnątrz Internetu. Oczywiście po stronie Linuxa również trzeba odblokować te porty na jego lokalnym firewallu za pomocą komendy firewall-cmd i skonfigurowaniu odpowiedniej strefy.

Usługę Singularity uruchomimy w kroku 2 na porcie HTTP 80 jako główna usługę portalu prezentująca użytkownikowi stronę z payload. Istotne jest to, aby port naszej aplikacji na WWW był taki sam jak port atakowanej usługi – wynika to z funkcji sprawdzania same-origin policy przez przeglądarkę. Omijamy tym funkcjonalność zabezpieczeń same-origin policy ponieważ nazwa hosta w dokumencie HTML będzie identyczna jak w przypadku witryny atakującego- udowodniliśmy w poleceniem „curl” powyżej. Port 22 SSH posłuży nam do zdalnego podpięcia się do serwera i zarzadzania Singularity, natomiast port 53 UDP posłuży do komunikacji skryptu z sieci ofiary z serwerem C2.

Krok 2 – instalacja narzędzia i uruchomienie Singularity

Do instalacji narzędzia Singularity potrzebny jest kompilator „Go”. Jeśli takie narzędzie mamy zainstalowane w systemie, wówczas będziemy mogli wykonać następujące komendy:

go get -v github.com/nccgroup/singularity
go get -v github.com/gorilla/mux
go get -v github.com/gorilla/websocket
go get -v github.com/gorilla/securecookie

Kompilację binarek serwera Singularity wykonamy za pomocą poniższego polecenia „go build”:

$ cd ~/go/src/github.com/nccgroup/singularity/cmd/singularity-server
$ go build

Teraz pozostanie nam tylko przekopiowanie plików do pokatalogu singulatiry i html:

$ cd ~/
$ mkdir -p singularity/html
$ cp ~/go/src/github.com/nccgroup/singularity/cmd/singularity-server/singularity-server ~/singularity/
$ cp -r ~/go/src/github.com/nccgroup/singularity/html/* ~/singularity/html/

i będziemy mogli uruchomić nasz serwer C2 na porcie 80:

Krok 3 – konfiguracja domeny kapitanhack.space

Konfigurację wpisów w naszej domenie przedstawia poniższy zrzut. Ważne parametry to TTL oraz dodane dwa pierwsze rekordy typu A oraz jeden typu NS wskazujący na nasz serwer Singularity (C2) – rebinder.kapitanhack.space.

Krok 4 – skonfigurowanie i uruchomienie Singularity

Jeśli przebrniemy przez prawidłową konfigurację wpisów DNS w naszej domenie oraz przez instalację narzędzia Singularity, po uruchomieniu serwera poleceniem „./singularity-server –HTTPServerPort 80” powinniśmy w przeglądarce naszego komputera zobaczyć poniższą stronę.

Po przejściu do interfejsu Managera będziemy mogli skonfigurować opcje połączenia i skryptu „Payload.js” takie jak:

• Attack Host Domain – nazwa FQDN naszego serwera rozwiązywania nazw (name serwer) C2. Skrypt JavaScript pobrany z tego serwera C2 uruchomi się na stronie internetowej w przeglądarce ofiary i będzie komunikował się z tym adresem.
• Attack Host – adres IP naszego serwera Singularity.
• Target Host – adres IP lub CNAME atakowanej usługi w lokalnej sieci, w której znajduje się komputer ofiary. Możemy w parametrze podać także adres localhost, 127.0.0.1 lub 0.0.0.0, wtedy będziemy mogli wykonać atak na lokalną usługę na komputerze ofiary.
• Target port – port, na którym uruchomiona jest usługa Singulatiry. W naszym scenariuszu portal do zarządzania routerem UPC jest uruchomiony na porcie 80. Gdyby był to inny port, wówczas serwer Singularity musielibyśmy uruchomić także na tym samym porcie.
• Attack Payload – tutaj wybieramy payload, który będziemy chcieli użyć do ataku w JavaScript. W kolejnym kroku napiszemy własny – pod usługę UPC.
• Toogle Advanced Options – wybieramy ten przycisk, jeśli chcemy skorzystać z zaawansowanych opcji nawiązywania komunikacji i skonfigurować dodatkowe parametry taki jak np. Flood DNS Cache. Możemy tez skorzystać z komunikacji po websockets/Proxy, wtedy zdalnie możemy w Internecie przejąć kontrolę nad stroną przejętej usługi wewnątrz sieci lokalnej!

Powyższe parametry możemy także skonfigurować w pliku „manager-config.json” znajdującego się w podkatalogu „html”:

Krok 5 – napisanie exploit pod dekoder UPC

W celu dobicia się do usługi wystawianej w sieci przez router UPC i wyciągnięcia z jego portalu hasła do Wifi stworzyliśmy własny exploit. W katalogu „html/payloads” utworzyliśmy nowy plik o nazwie „upc-wifi-creds-get.js”:

Kawałek kodu exploit przedstawiamy na poniższym ekranie:

W nagłówku zapytania do podstrony „/Wireless24GhZSecurity.asp” przekazujemy do zmiennej Authorization parametry pozwalające uwierzytelnić się w portalu, następnie parsujemy zwrócony wynik wyszukując w nim nazwę ssid sieci oraz hasło do Wifi.

Krok 6 – wysłanie linka do użytkownika i przeprowadzenie ataku

Po stronie serwera C2 Singulatiry wybieramy odpowiednie opcje w portalu Manager’a lub konfigurujemy je wcześniej w pliku „manager-config.json”:

Po stronie komputera ofiary w przeglądarce wpisujemy adres strony http://kapitanhack.space/manager.html i w trybie debuggera przeglądarki obserwujemy cały atak. Klikamy na przycisk „Start attack”:

Oczywiście cały atak możemy tak przygotować, aby użytkownik nie musiał nic klikać, a strona będzie zawierała ulubione zdjęcia kotów lub psów albo czegoś innego, co zainteresuje użytkownika.

W tle odpali się skrypt „soopayload.html”, który skomunikuje się z serwerem C2 i wykona odpytanie wewnętrznej usługi dekodera UPC w sieci użytkownika. Po udanej komunikacji z usługą routera UPC nastąpi jej ekspoitacja i wykonanie naszego skryptu pobierającego z niej hasło.

Po udanym ataku, na końcu w wierszu konsoli powinniśmy zobaczyć wynik: nazwę sieci oraz hasło do wifi 🙂

Jak sobie radzić z problemem? Jak się zabezpieczyć?

Poniżej zebraliśmy kilka porad, jak możesz uchronić się przed tego typu atakiem.

1. Nie klikać w nieznane linki. Jest to pierwszą rzecz jaką powinniśmy zrobić. Oczywiście jest to porada, która tak naprawdę nic konkretnego nam nie mówi i spotykana jest w wielu poradnikach dot. Bezpieczeństwa. Musimy klikać, ale z rozwagą i mieć na uwadze te wskazówki, które opublikowaliśmy w tym poradniku.
2. Wyłączyć JavaScript w przeglądarce. W przypadku naszego scenariusza ataku wykorzystywaliśmy na stronie skrypt napisany w JavaScript. W tym artykule dowiesz się jak zabezpieczyć swoją przeglądarkę i jak wyłączyć JavaScript (uwaga, mogą przestać działać niektóre aplikacje, których używasz przez WWW). Gdybyśmy mieli wyłączona obsługę JavaScript w naszej przeglądarce podany atak by się nie powiódł. Z JavaScript jest podobna sytuacja jak z PowerShell. Dlatego najlepiej na komputerze mieć jedną zabezpieczoną przeglądarkę internetową, z której surfujesz po necie i drugą używaną do zaufanych domen i przeprowadzania np. przelewów.

Jeśli chodzi o zabezpieczenia infrastruktury dla firm, to:

1. Atakom ponownego wiązania DNS można zapobiec, sprawdzając poprawność nagłówka HTTP „Host” po stronie serwera, aby zezwolić tylko na zestaw wartości z białej listy. W przypadku usług nasłuchujących na interfejsie pętli zwrotnej ten zestaw wartości hosta na białej liście powinien zawierać tylko hosta lokalnego i wszystkie zastrzeżone adresy numeryczne dla interfejsu pętli zwrotnej, w tym 127.0.0.1. Załóżmy na przykład, że usługa nasłuchuje pod adresem 127.0.0.1, port TCP 3000. Następnie usługa powinna sprawdzić, czy wszystkie wartości nagłówka „Host” żądania HTTP zawierają „127.0.0.1:3000” i / lub „localhost: 3000″. Jeśli nagłówek hosta zawiera coś jeszcze, żądanie powinno zostać odrzucone.
2. W zależności od modelu wdrażania aplikacji może być konieczne dodanie do białej listy innych lub dodatkowych adresów, takich jak 127.0.0.2, inny zarezerwowany adres numeryczny dla interfejsu pętli zwrotnej.
3. W przypadku usług udostępnianych w sieci (i ogólnie wszystkich usług) należy wymagać uwierzytelnienia, aby zapobiec nieautoryzowanemu dostępowi.
4. Nieakceptowanie i filtrowanie odpowiedzi DNS zawierających adresy prywatne, lokalne łącza lub sprzężenia zwrotnego, zarówno w przypadku IPv4, jak i IPv6, nie powinno być traktowane jako podstawowy mechanizm obrony przed atakami ponownego wiązania DNS. Osobliwość może ominąć niektóre filtry w określonych warunkach, takich jak odpowiadanie rekordowi CNAME hosta lokalnego, na przykład podczas celowania w aplikację za pośrednictwem przeglądarki Google Chrome.
5. W aplikacjach ograniczyć obsługę JavaScript (aby atakujący nie mógł wymuszać żądań).
6. Przypisać adresy IP do nazw (aby nie mogły się zmieniać/rotować).
7. Odrzucanie i nieakceptowanie wartości TTL poniżej określonego rozmiaru (aby nie mogły się szybko zmieniać).
8. Wyłączyć funkcję WebRTC w przeglądarce, dzięki której atakujący może się dowiedzieć jaki adres ma nasza sieć lokalna. O WebRTC i innych ciekawych informacjach, jakie może wyciągnąć z przeglądarki cyberprzestępca pisaliśmy w artykule tutaj.
9. Zalecamy do poniesienia nakładów finansowych w porządne rozwiązanie do ochrony DNS.

Podsumowanie

Na podstawie powyższego przykładu pokazaliśmy jak groźne skutki dla użytkownika może spowodować kliknięcie w niesprawdzony link lub odwiedzenie złośliwej strony internetowej. Pokazaliśmy także i udowodniliśmy na podstawie ataku DNS Rebinding jak ważną rolę w bezpieczeństwie pełni bezpieczeństwo DNS. Sytuacja, do której doprowadziliśmy – wyciek nazwy i hasła dostępowego do lokalnego Wifi w sieci użytkownika daje dużo do myślenia. Dlatego oprócz bezpieczeństwa DNS, klikania w nieznane linki powinniśmy zwrócić uwagę na bezpieczeństwo naszych urządzań w sieci i portali WWW, do których mamy dostęp na co dzień. Na koniec pozostaje nam sprawdzenie tezy stawianej w Internecie czy technika DNS Rebinding jest przepuszczana przez wszystkie rozwiązania do bezpieczeństwa? Z tego co się orientujemy, to jest, ale warto byłoby to potwierdzić. Może kolejny artykuł napiszemy właśnie o tym?