Zdalny root na routerze SOHO

Wstęp

W czteroczęściowym tekście przedstawimy wybrane ataki na urządzenia sieciowe.  W pierwszej kolejności, wskażemy pewne trendy w  sposobie projektowania sprzętu sieciowego oraz związane z tym zagrożenia. Następnie skupimy się na atakach przeprowadzanych z wykorzystaniem webowych konsoli zarządczych -  przedstawione zostaną podatności w dwóch modelach routerów klasy SOHO (ang. Small Office / Home Office)– ASMAX oraz Linksys. Finalnie, wskażemy potencjalne skutki tego typu ataków oraz opiszemy metody ochrony.

Trend w budowie urządzeń sieciowych

Od pewnego czasu na rynku można zaobserwować pewien trend, polegający na budowie urządzeń sieciowych według następującego schematu:

• wykorzystaj darmowy system operacyjny (np. Linux / FreeBSD);
• wykorzystaj oprogramowanie open source, które zapewnia odpowiednią funkcjonalność dla danej maszyny (np. w przypadku routera klasy SOHO mogą to być: iptables, daemon ppp, serwer SNMP, lekki serwer WWW, …);
• skonfiguruj system operacyjny / dodatkowe oprogramowanie – dla danego sprzętu i pod konkretne wymagania funkcjonalne urządzenia.

Jednym zdaniem – wykorzystuje się bogate możliwości oferowane przez oprogramowanie open source, w znacznej mierze ograniczając koszty. W jaki sposób możemy oszczędzić? Otóż odpowiednio dobrane oprogramowanie open source:

• zapewnia  bogatą funkcjonalność;
• jest stabilne i dokładnie przetestowane na różnych platformach sprzętowych oraz w różnych konfiguracjach;
• jest bezpłatne (wliczając w to również wsparcie zapewniane przez twórców).

Stworzenie od podstaw oprogramowania do obsługi firewalla czy innego urządzenia sieciowego byłoby niesłychanie czasochłonne (patrząc od strony producenta – kosztowne). I jak wskazaliśmy wyżej (funkcjonalności oferowane przez open source) w wielu przypadkach niekonieczne… 

Warto jednak dostrzec pewną ukrytą wadę takiego podejścia.  Otóż niejako „klejąc”  oprogramowanie open source z różnych źródeł, możemy utracić kontrolę nad bezpieczeństwem systemu.  Pamiętajmy, że każdy wykorzystany komponent ewoluuje w czasie. Przykładowo:

• wykrywane są nowe błędy;
• publikowane są się nowe wersje komponentu, zawierające pewne dodatkowe (potencjalnie podatne) funkcjonalności;
• ukazuje się zupełnie nowa linia komponentu – niekoniecznie w pełni kompatybilna z poprzednią; z czasem twórcy poprawiają błędy jedynie w nowej linii.

Tego typu właściwości powodują, że precyzyjna kontrola bezpieczeństwa systemu staje się sporym wyzwaniem.

Trend w budowie urządzeń sieciowych - przykład

Zobaczmy jak wygląda to w praktyce. Jako pierwszy przykład niech posłuży jedno ze sztandarowych produktów Cisco – urządzenie ASA (Adaptive Security Appliance), łączące w sobie funkcjonalność firewalla, VPN oraz systemu IPS (Intrusion Prevention System).

Od niedawna maszyna ta wykorzystuje system operacyjny Linux oraz całą gamę dodatkowego oprogramowania open source.  Pełną listę licencji  wykorzystanych w ASA można znaleźć tutaj, a są to przykładowo: Apache License, HSQLDB License, libxml2 License, Linux 2.6 License, zlib 1.2.2 License .

Pełna lista obejmuje ponad czterdzieści pozycji , przy czym samego, użytego oprogramowania open source jest z pewnością o wiele więcej. W przypadku biblioteki zlib, na stronie producenta można znaleźć informację: “Version 1.2.3 eliminates potential security vulnerabilities in zlib 1.2.1 and 1.2.2, so all users of those versions should upgrade immediately”. 

Czyżby zatem ASA była podatna? Trudno powiedzieć - być może wykorzystywana jest inna wersja zlib niż wskazana w licencjach, być może producent sam załatał błędy bezpieczeństwa, a być może nawet jeśli wykorzystana jest podatna wersja biblioteki, to na tym urządzeniu błędy te nie są groźne.  Schemat ten pokazuje jednak potencjalną drogę działania intruza.  Zlib to tylko jedna z wielu bibliotek open source wykorzystywanych w ASA. Z kolei ASA, to tylko jedno z wielu urządzeń sieciowych…  

Kolejny przykład można znaleźć pracy w zatytułowanej „Analyzing Complex Systems - The BlackBerry Case” autorstwa fx. W prezentacji tej wskazane są m.in. nieaktualne (tj. z błędami bezpieczeństwa) biblioteki: zlib oraz GraphicsMagick (wspomagająca operacje na plikach graficznych). Dzięki błędom w ostatniej możliwe było przejęcie kontroli nad BlackBerry Enterprise Serwer - poprzez wysłanie odpowiednio spreparowanego pliku graficznego na telefon BlackBerry.

Przykładów tego typu można wymieniać wiele – zainteresowanych czytelników odsyłamy np. do projektu „router hacking challenge” organizowanego przez gnucitizen czy pracy zatytułowanej: „Universal Plug and Play - Dead simple or simply deadly?” autorstwa Armijn Hemel.

W dalszej części tekstu skupimy się na atakach związanych z podatnościami  w specyficznym komponencie urządzenia – serwerze http oraz działającej na nim konsoli zarządczej. Precyzyjniej - wskażemy dwa modele routerów klasy SOHO, w których istnieje możliwość zdalnego, nieautoryzowanego wywołania polecenia systemu operacyjnego (jako root) z poziomu tej konsoli.

Web Management a bezpieczeństwo urządzenia.

Coraz większa liczba urządzeń sieciowych umożliwia na pełne zarządzanie maszyną poprzez przeglądarkę internetową. Można wręcz powiedzieć, iż jest to ostatnimi czasy funkcjonalność, która po prostu musi być dostępna w tego typu maszynie (czy aby na pewno musi?).  Warto pamiętać, że tego typu funkcjonalność stwarza od strony bezpieczeństwa pewne problemy. Intruz może bowiem próbować: 

• zaatakować serwer WWW (na przykład wykorzystując niepoprawną obsługę protokołu http);
• zaatakować aplikację działającą na serwerze WWW (w dalszej części tekstu prezentujemy tego typu przykład);
• zaatakować konfigurację komponentu (przykładowo - źle skonfigurowane uwierzytelnianie oraz autoryzację użytkowników).

Czy łatwo jest przeprowadzić tego typu atak?  Aby odpowiedzieć na to pytanie, zobaczmy w jaki sposób często budowany jest web management w urządzeniach klasy „domowej”:

• wykorzystany jest „lekki” serwer http (zaletą jest jego „lekkość”, nie bezpieczeństwo);
• aplikacja do zarządzania przygotowana jest w „starym stylu” – CGI.  Często jest to oprogramowanie napisane w C i skompilowane do postaci binarnej;
• http serwer działa z uprawnieniami root.

Dlaczego wykorzystywane są tego typu konstrukcje? Ponieważ w ten sposób zapewniamy, iż oprogramowanie do zarządzania urządzeniem nie skonsumuje cennych zasobów bądź co bądź słabego sprzętu. Z kolei dzięki uprawnieniom roota całość będzie działać bez przeszkód (maksymalne uprawnienia, to brak problemów z dostępem do określonych zasobów…). 

Dodatkowo pewnymi cechami „wbudowanymi” tego typu urządzeń są niekiedy:

• wykorzystanie nieaktualnej wersji serwera http (wskazania błędów można znaleźć np. w plikach changelog…);
• brak odpowiedniej walidacji wejścia w aplikacji służącej do zarządzania urządzeniem;
• wykorzystanie dość rozbudowanych funkcjonalnie dystrybucji Linux (np. zapewniających takie binarna jak: wget czy tftp).
  

Bardzo ostrożnie mówiąc, jeśli chodzi o bezpieczeństwo, nie jest to najszczęśliwsze podejście.

Zawsze można jednak zignorować te problemy i całkowicie zablokować na wbudowanym firewallu dostęp inicjowany z Internetu. W domyślnej konfiguracji czyni znaczna liczba producentów.  Ale czy w ten sposób zablokujemy potencjalnych intruzów próbujących wykonać atak z poza LAN? W kolejnej odsłonie tekstu zobaczmy dwa przykłady, które są wynikiem naszych badań nad bezpieczeństwem routerów klasy domowej.

Więcej informacji

• Pierwsza część artykułu: obecnie ją czytasz
  
• Druga część artykułu: root na routerze ASMAX
• Trzecia część artykułu: root na routerze Linksys
• Czwarta część artykułu: skutki ataku na router SOHO
  

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