Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje root na routerze Asmax

root na routerze Asmax

 Tekst jest kontynuacją artykułu zdalny root na routerze SOHO.

Router ASMAX - AR 804 gu (ADSL + WiFi)

Jest to używane Polsce urządzenie, umożliwiające m.in. dostęp do Internetu z wykorzystaniem popularnej neostrady.  Z dalszych badań wynika, iż jest ono zbudowane na bazie architektury sprzętowej MIPS (w szczególności wykorzystany procesor jest klasy RISC).

asmax 804gu

Z kolei od strony softwareowej, jako podstawa wykorzystany jest zestaw Linux oraz BusyBox (tj. pakiet przydatnych, lekkich aplikacji pomocniczych). Warto również wspomnieć, że router ten blokuje domyślnie komunikację nawiązywaną z poziomu sieci Internet.

Czy zatem można  zaatakować urządzenie z zewnątrz (tj. nie będąc w LAN)?  Na myśl przychodzą ataki klasy CSRF (Cross Site Request Forgery), które z komputera na którym działa przeglądarka internetowa, tworzą swego rodzaju punkt pośredni do zaatakowania docelowego systemu.  Zanim jednak rozwiniemy kwestię ataku CSRF w kontekście urządzeń sieciowych, wykonajmy pewną analizę bezpieczeństwa samego routera ASMAX oraz dostępnej na nim konsoli zarządzania przez przeglądarkę internetową. Otóż okazuje się, że:

  • wykorzystywana webowa aplikacja zarządcza jest skompilowana do pliku wykonywalnego o nazwie webcm;
  • aplikacja ta między innymi wykorzystuje parametr getpage do ładowania określonych danych w interface administracyjnym. Przykładowe wykorzystanie tego parametru wygląda następująco:

http://192.168.1.1/cgi-bin/webcm?getpage=wskazanie_na_plik_html&kolejny_parametr... 

  •  dalsze testy pokazują, że parametr getpage nie jest poprawnie walidowany i umożliwia odczytanie dowolnego pliku w systemie operacyjnym (w szczególności pliku webcm zapewniającego obsługę administracji routerem);
  • kolejny problem to istnienie pliku o dość enigmatycznej nazwie ‘script’ w katalogu /cgi bin/ (można go zlokalizować np. dzięki kolejnej podatności – directory listing na katalogu /cgi bin/). Uruchomienie tego skryptu nie powoduje niczego szczególnego (pusty ekran wynikowy) . 

Jednak korzystając z poprzedniej podatności, związanej z parametrem getpage, możemy wyświetlić źródło pliku ‘script’. Okazuje się, że jest to skrypt najprawdopodobniej służący developerom producenta  do debugowania routera. Wśród kilku parametrów wykonania, dostępny jest jeden o dość interesującej nazwie: system. Przekazując ten parametr umożliwiamy wykonanie dowolnego polecenia w systemie operacyjnym! Wywołanie to wygląda w sposób następujący: 

http://192.168.1.1/cgi-bin/script?system%20ps%20aux

Wynik tego polecenia został przedstawiony na rysunku poniżej:

Asmax - root

Rysunek 1. Wykonanie polecenia w systemie operacyjnym - router ASMAX

  • pamiętamy jednak, że po wpisaniu adresu do konsoli webowej, prezentowany jest nam ekran logowania.  Aby dostać się do naszego ‘scriptu’ potrzebujemy więc znać poprawny login oraz hasło administracyjne do maszyny. Otóż niekoniecznie. Okazuje się, że w przypadku dostępu do pliku ‘script’ takie ograniczenie nie jest narzucane!
  • po dodaniu, że serwer http uruchamiany jest z prawami użytkownika root, zaczyna być powoli widać w jaki sposób intruz może przeprowadzić zdalny atak.

Atak na ASMAX AR 804 gu

Poniżej prezentujemy przykładową ścieżkę ataku, umożliwiającą zdalne przejęcie kontroli nad systemem operacyjnym routera (przy zaznaczeniu, że jest to tylko jedna z możliwych dróg kompromitacji…). Aktywacja ataku następuje po odwiedzeniu przez ofiarę wrogiej strony WWW a na kolejne kroki składają się:

  • atak CSRF;
  • wykorzystanie podatności klasy Authentication Bypass dla skryptu ‘script’ (lub raczej: Lack of Authentication...);
  • wykorzystanie podatności klasy OS Commanding, umożliwiającej wykonanie poleceń systemu operacyjnego, z uprawnieniami root (odpowiedni parametr przekazywany do ‘script’);
  • wykorzystanie w systemie dostępności narzędzi typu wget / tftp, w celu pobrania na router prostego backdoora;

Znamy już ramowy plan ataku. Przejdźmy zatem do bardziej szczegółowego omówienia pierwszego kroku – Cross Site Request Forgery.

Ataki klasy CSRF polegają na wykorzystaniu pewnej relacji zaufana pomiędzy przeglądarką internetową ofiary a atakowanym systemem – i wykorzystaniu tej relacji do wrogich celów. Atak tego typu jest pośredni i wykonywany poprzez „zmuszenie” przeglądarki użytkownika do wykonania wrogich akcji.

Relacją zaufania może być np. aktywna sesja w bankowości elektronicznej, a  wykorzystanie relacji może polegać na otworzeniu przez ofiarę odpowiednio spreparowanej strony www  (w takim przypadku atakujący może wykonać np. nieautoryzowany przelew w imieniu ofiary).  Innymi słowy, w momencie gdy jesteśmy zalogowani do bankowości elektronicznej oraz w tym samym czasie odwiedzimy wrogą stronę WWW –  uruchomiony może być atak CSRF skutkujący wykradzeniem środków z naszego konta.

Tego typu działanie można również zastosować przy próbie atakowania routera. W naszym przypadku, ze względu na wskazane wyżej podatności (głównie: Authentication Bypass) atak podlega pewnemu uproszczeniu. Relacją zaufania, którą wykorzystamy jest obecność stacji z przeglądarką internetową w sieci LAN (na podstawie tej lokalizacji mamy dostęp sieciowy do konsoli zarządczej).  Z kolei wykorzystanie tej relacji polegało będzie na nieautoryzowanym wywołaniu omawianego wcześniej pliku ‘script’.

Dokładniej, aby wywołać dowolne polecenie w systemie operacyjnym, na którym działa router ofiary wystarczy:

  • umieścić na określonej stronie WWW tag HTML: <img src=http://192.168.1.1/cgi-bin/script?system%20polecenie%20parametry>;
  • skłonić ofiarę do wejścia na tą stronę.

W dalszej kolejności następuje automatycznie pobranie backdoora z serwera atakującego - za pośrednictwem klienta tftp. Finalnie, wrogi skrypt zestawia dwustronną komunikację z maszyną intruza (np. korzystając z możliwości przesyłania plików poprzez tego samego klienta tftp), dając tym samym atakującemu możliwość zdalnego wykonywania poleceń jako root.
Poszczególne etapy zostały przedstawione na Rysunku poniżej:

Schemat ataku - asmax

Rysunek 2.  Zdalny root na routerze – przykładowy atak 


Aby rozwiać ewentualne wątpliwości iż jest to tylko teoretyczny scenariusz, pragniemy wspomnieć, że działający na ten model routera atak został zaprezentowany na żywo podczas tegorocznej konferencji Confidence 2009.  Zobaczmy teraz jakie cechy posiada tego typu atak:

  • jest w zasadzie niewykrywalny dla niedoświadczonej ofiary;
  • nie wymaga użycia JavaScriptu (zatem przed atakiem nie chroni oprogramowanie typu NoScript);
  • atak nie wymaga posiadania hasła administracyjnego do routera (przed atakiem nie ochroni więc  zmiana hasła dostępowego do urządzenia; właściwość osiągnięta dzięki podatności Authentication Bypass);
  • atak działa niezależnie od blokady połączeń nawiązywanych z sieci Internet (właściwość osiągnięta dzięki atakowi CSRF);
  • atak wymaga odwiedzenia przez ofiarę strony z wrogim kodem HTML (zauważmy jednak, że sporo serwisów umożliwia załączenie obrazu z kontrolowanym przez siebie źródłem…);
  • nie jest wymagane bycie zalogowanym do konsoli zarządczej routera podczas dostępu do wrogiej strony WWW (właściwość osiągnięta dzięki podatności Authentication Bypass).

Dla porządku dodajmy, że omawiane poniżej podatności zostały zweryfikowane na najnowszym firmware - 66.34.1.  W momencie przygotowania tekstu, nie jesteśmy świadomi publikacji przez producenta jakichkolwiek poprawek korygujących te błędy.

Na marginesie, warto zwrócić również uwagę, że gdyby tego typu atak został przeprowadzony na infrastrukturę klasy enterprise to  ewentualnie odnotowane w logach systemowych źródło ataku (IP) będzie znajdowało się w sieci lokalnej. Ponadto, komunikacja nawiązywana z LAN jest zazwyczaj o wiele słabiej filtrowana niż ta przychodząca z Internetu... 

Dodatkowo, w infrastrukturze enterprise już samo istnienie podatności umożliwiającej wykonanie polecenia systemu operacyjnego może mieć nieprzyjemne skutki (często do konsoli administracyjnej mają dostęp użytkownicy o różnych uprawnieniach, a tego typu podatność mogłaby posłużyć do prostego ominięcia mechanizmów autoryzacyjnych).

Więcej informacji

 

--michal.sajdak@securitum.pl

tekst oryginalnie został opublikowany w magazynie hakin9 (10/2009)

Przydatne informacje? Polub nas na facebooku.

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS