Sekcje

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


Baza wiedzy Publikacje Skutki ataku na routery klasy SOHO

Skutki ataku na routery klasy SOHO

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

psyb0t

Dość szeroko komentowanym przypadkiem, było wykrycie na początku 2009 roku robaka atakującego routery oraz modemy DSL klasy SOHO. Robak ten, o roboczej nazwie psyb0t, włączał zainfekowane maszyny do botnetu, który z kolei pokazał swoją siłę wykonując atak DDoS na DroneBL. Informacje o botnecie są dość skąpe (pomijając „sensacje” dostarczane przez popularne portale). Na pewno wiemy, że robak:

  • rozpowszechniał się poprzez interfejsy administracyjne udostępnione do sieci Internet (wykorzystanie domyślnych lub słownikowych haseł na maszynach);
  • po otrzymaniu dostępu root poprzez interfejs administracyjny, dalsza infekcja polegała na ściągnięciu z określonego serwera pliku binarnego i uruchomieniu go na maszynie. W tym momencie następowało połączenie się do serwera IRC, gdzie „zombie” czekał na dalsze polecenia (np. wyszukanie kolejnych podatnych urządzeń,  na których można zainstalować robaka). Blokowane były również wszelkie połączenia administracyjne na zainfekowaną maszynę;
  • atakował urządzenia oparte o architekturę MIPS little endian (wspominany wcześniej router ASMAX działa właśnie w oparciu o tego typu sprzęt; pamiętajmy też że kod skompilowany na daną architekturę sprzętową nie będzie działał na innych platformach);
  • miał zaimplementowane kilka różnych typów ataków (łącznie z kilkoma różnymi atakami DoS, skanowaniem w poszukiwaniu „dziurawych” serwerów MySQL czy podatnych instalacji phpMyAdmin);
  • wykorzystane zostało najprawdopodobniej gotowe oprogramowanie do budowy botnetów (może świadczyć o tym jedno z kontrolnych poleceń botnetu: „.r00t” wykorzystujące vmsplice() exploit do uzyskania dostępu jako root - z poziomu mniej uprawnionego użytkownika. Pamiętajmy, że na zainfekowanych maszynach dostęp administracyjny był zapewniony od razu po infekcji…);
  • zainfekował przeszło 100 000 maszyn.

Sam botnet „oficjalnie” zakończył działanie komunikatem na swoim „kontrolnym” kanale IRC: 
„* Now talking on #mipsel * Topic for #mipsel is: .silent on .killall .exit ._exit_ .Research is over: for those interested i reached 80K. That was fun :), time to get back to the real life...”.

Rozpatrując przypadek psyb0t-a, można więc powiedzieć, że wykorzystanie sieciowych urządzeń klasy SOHO do wrogich celów stało się faktem. Przy okazji warto zauważyć, że scenariusz ataku jest stosunkowo prosty i uniwersalny (wykorzystanie udostępnionych interfejsów administracyjnych oraz słabych, czy wręcz domyślnych haseł dostępowych).

Zapewne w niedalekiej przyszłości można się spodziewać analogicznych „niewidzialnych” ataków na pozostałe platformy sprzętowe. Z czasem też zapewne zostaną wykorzystane bardziej zaawansowane techniki polegające na wykorzystaniu innych błędów - w konfiguracji urządzeń, czy błędów w oprogramowaniu maszyn.

Warto również zwrócić uwagę na fakt, że tego typu ataki następują w miejsce, które uznawane jest za dość bezpieczne. Użytkownicy domowi traktują tego tupu urządzenia jako bezpieczne ‘czarne skrzynki’, które dobrze spełniają swoje funkcję i mało kto wykonuje okresową aktualizację firmware, nie mówiąc już o skanowaniu tego typu systemów na obecność trojanów/robaków/czy innego szkodliwego oprogramowania. Ponadto, bardzo niewielu użytkowników zmienia domyślne hasła dostępowe do urządzeń. Patrząc od strony atakujących, nie bez znaczenia jest również fakt, że tej klasy maszyny są prawie zawsze włączone (w przeciwieństwie np. do zwykłych PC-tów).

Pozostałe skutki ataku

Poza wspomnianymi wcześniej atakami DDoS czy możliwością bezpośredniego ataku na inne urządzenia/serwery, możliwe jest podsłuchiwanie ruchu czy prowadzenie aktywnych ataków klasy MiTM (Man in The Middle) – np. na połączenia do bankowości elektronicznych (czy to w sposób bezpośredni – na protokół https – czy w sposób pośredni  - np. poprzez przechwytywanie i modyfikację zapytań DNS), w grę wchodzą również tego typu „klasyczne” działania jak masowe rozsyłanie spamu. Słowem – możliwe są ataki mające cechę nieautoryzowanego dostępu do naszej sieci LAN.

Wskazywane w artykule podatności mogą nieść za sobą również walory edukacyjne, niekoniecznie związane z samym bezpieczeństwem.  Otrzymujemy bowiem pełen dostęp do niedrogiego sprzętu o architekturze innej niż popularne x86. Dodatkowo mamy dostępny prekonfigurowany i sprawnie działający otwarty system operacyjny. Może to stanowić dobry start do nauki asemblera na bardziej nietypowe procesory czy po prostu pomóc w analizie sposobu budowy oraz wewnętrznej konfiguracji tej klasy urządzeń. Czytelników zainteresowanych tego typu działaniami odsyłamy do tekstu pokazującego jak w bardziej uporządkowany sposób uruchomić oprogramowanie argus na routerze Linksys (jedna z ciekawszych aplikacji wykorzystywanych przy NSM (Network Security Monitoring)) . W takim przypadku przydatna może być również tematyka związana z tzw. cross kompilatorami  (umożliwiającymi tworzenie kodu wykonywalnego dla innej platformy niż ta, na której działa kompilator) oraz projektami: routertech czy openwrt, dostarczającymi alternatywnych  firmware do wielu urządzeń klasy SOHO.

Jak zapobiegać tego typu atakom?

Jak widzieliśmy wcześniej, zmiana domyślnego hasła nie stanowi  zawsze stuprocentowego zabezpieczenia (patrz: wspominane wcześniej podatności klasy Authentication Bypass) i podobnie okresowa aktualizacja firmware może pozostawić nas narażonych na ataki (producenci niekiedy ignorują problemy bezpieczeństwa, a przygotowanie nowego firmware często liczone jest w miesiącach). Niemniej jednak te dwa kroki należy zaliczyć do skuteczniejszych metod ochrony.

Dobrą praktyką jest również nieudostępnianie interfejsów administracyjnych poza LAN.

Najprostszą metodą ochrony przez wspomnianymi wcześniej atakami CSRF na urządzenia jest zmiana domyślnego, wewnętrznego adresu IP maszyny - czasami jednak producent nie zapewnia takiej możliwości…., a ponadto jest to raczej dodatkowy, niż podstawowy element ochrony. W tym przypadku, skuteczniejszym sposobem jest zmiana konfiguracji proxy w przeglądarce internetowej, tak aby połączenia http do sieci o adresacji prywatnej nie dochodziły do skutku (można to wykonać za pomocą mechanizmu auto-konfiguracji proxy lub korzystając ze stosownego pluginu do przeglądarki  internetowej - np. FoxyProxy).

Oczywiście bardzo skuteczną ochroną byłoby projektowanie urządzeń sieciowych od początku z myślą o bezpieczeństwie –zazwyczaj jednak nie mamy na to wpływu… 

Podsumowanie

W tekście wskazaliśmy kilka charakterystycznych dla urządzeń sieciowych problemów bezpieczeństwa. Zaprezentowaliśmy również konkretne podatności w dwóch wybranych modelach routerów klasy SOHO, wskazując potencjalne możliwości ochrony przed atakami.

Mamy nadzieję, że artykuł skłoni dociekliwe osoby do własnych badań – często bowiem urządzenia tego typu są pod ręką, a podatności nie są bardzo trudne do znalezienia.  Zachęcamy również do dzielenia się z nami swoimi wynikami oraz rozwijania bazy projektu Devices Hacking.

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