Bezpieczeństwo routerów SOHO

Kontynuując cykl publikacji materiałów z jubileuszowego, 5. Raportu CERT Orange Polska, tym razem proponujemy lekturę obowiązkową dla przedsiębiorców z segmentu SOHO. O tym dlaczego warto przyjrzeć się naszego domo/firmowemu routerowi i na jakie potencjalnie przykre niespodzianki możemy być narażeni pisze Kamil Uptas. Oczywiście niezmiennie zapraszamy do zapoznania się z treścią całego raportu (a także tych z lat wcześniejszych).

Fotografia tytułowa, autorstwa użytkownika Asim18, na licencji CC 3.0, ma charakter ilustracyjny, nie ma na celu prezentować modelu urządzenia konkretnego producenta.

Mimo, iż świadomość, jak istotne jest bezpieczeństwo naszych „bram do internetu” stale rośnie, nadal daleko temu segmentowi urządzeń sieciowych do stanu idealnego. Przez ostatnie lata w CERT Orange Polska poddaliśmy walidacji kilkanaście routerów klasy SOHO (Small Office/Home Office), będących w ofercie Orange oraz niezliczoną ilość urządzeń, biorących udział w obsługiwanych incydentach.

Bezpieczeństwo po stronie klienckiej

Najpopularniejszym interfejsem administracyjnym jest ten osiągalny za pomocą przeglądarki internetowej, skupiając tym samym na sobie najwięcej uwagi agresorów.

Większość testowanych rozwiązań posiadało mechanizm filtracji danych przeniesiony na stronę kliencką, czyli obsługiwany za pomocą JavaScriptu. Takie podejście jest nieskuteczne i mija się z celem – wystarczy zmodyfikować formularz za pomocą narzędzi deweloperskich przeglądarki, wyłączyć obsługę JS, lub wysłać żądanie za pomocą konsolowych narzędzi, np. takich jak cURL.

Istnieje więcej przeciwwskazań do nadmiernego bazowania na mechanizmach client-side. Wystarczy wyobrazić sobie scenariusz, w którym zarządzanie sesją oparte jest na cookies, a mechanizm wylogowywania realizowany jest z poziomu JavaScript. W sytuacji gdy zechcemy wymusić użycie flagi HttpOnly, stracimy możliwość wylogowania się.

Wrażliwe dane w jawnej formie

Zapomniałeś danych uwierzytelniających do sesji PPP, a z jakiegoś powodu są Ci potrzebne? Istnieje spore prawdopodobieństwo, że znajdziesz je w źródle strony panelu administracyjnego. Równie duża jest szansa, że będziesz mógł odczytać je z pobranego pliku konfiguracyjnego. Są to rzeczy, które dobrze sprawdzić już na samym początku, choć wynik może pozbawić złudzeń z czym ma się do czynienia.

Cross Site Scripting

Podatności tego typu są tak samo stare jak pierwsze dynamiczne witryny internetowe. W routerach SOHO również występują, czy raczej należałoby powiedzieć: „rzadko kiedy nie występują”. Winę za to ponosi chociażby wspomniany wcześniej fakt filtrowania danych wprowadzanych do formularzy po stronie przeglądarki. Przeniesienie go na stronę serwera powinno załatwić sprawę, ale nie zawsze tak się dzieje. Często walidacja sprowadza się do wycinania kluczowych słów jak “script”, “document”, czy “write”, co nie rozwiązuje problemu, a jedynie zmusza do szukania metod obejścia blacklisty za pomocą mniej znanych funkcji lub egzotycznych kodowań.

Zdarzało się też, że złego kodu nie można było wstrzyknąć z poziomu GUI, ale dało się to zrobić podając go w odpowiednich zmiennych w pliku konfiguracyjnym (jeśli był przechowywany w formie jawnej), a następnie reuploadować.

Ciekawym wektorem jest wstrzyknięcie kodu poprzez użycie pola hostname w żądaniu DHCP o przydzielenie nowego adresu IP (DHCPREQUEST). W takiej sytuacji kod miałby się wykonać w zakładce wyświetlającej klientów przyłączonych do sieci, co w kilku przypadkach było równoznaczne z indexem panelu administracyjnego.

Problematyka haseł

Domyślne hasła takie jak “admin” czy “123456” nie wróżą dobrze, ale nie są też niczym nowym. Nie od dzisiaj wiadomo, że lepiej osłabić bezpieczeństwo rozwiązania niż narażać klienta na niewygodę przepisywania czegoś bardziej złożonego z naklejki pod urządzeniem, albo dzwonienia do dostawcy z prośbą o reset hasła.

Pół biedy jeśli usługi administracyjne nie są wystawione do WAN, tym niemniej na próżno szukać sensownych polityk haseł. Największym osiągnięciem na tym polu było wymuszenie na jednym z dostawców wyświetlanie komunikatu z prośbą o zmianę hasła po pierwszym zalogowaniu.

Tylko jeden producent zasłużył na wyjątkowe brawa, bowiem badany model jego urządzenia faktycznie nie umożliwiał prowadzenia prac administracyjnych dopóki hasło nie zostało zmienione (sic!).

Druga rzeczą, nad którą warto się pochylić, jest mechanizm generowania haseł do WIFI (kwestie algorytmu szyfrowania pomijamy, na całe szczęście WEP i WPA już dawno umarły). Zdarzały się sytuacje gdzie hasło składało się ze stałego ciągu i np. czterech ostatnich znaków SSID. Jeśli właściciel takiej sieci nie zmienił jej nazwy, sieć stawała otworem dla każdego kto znalazł się w jej zasięgu.

Ostatnia kwestia to sposób przekazywania i przechowywania haseł. Routery pewnej polskiej firmy przekazywały dane uwierzytelniające jawnym tekstem, w dodatku metodą GET.  Była to wyjątkowa patologia, lecz konkurencja także nie pozostała w tyle korzystając z base64 (albo łatwo poddającego się atakowi brute force Basic-Auth). Nie spotkałem się ani z przekazywaniem hasła w sposób niejawny, ani tym bardziej z wykorzystaniem funkcji skrótu. Można odnieść wrażenie, że dla dostawców są zbyt zasobożerne i zbyt drogie do wdrożenia.

Szyfrowanie komunikacji

Jedną z fundamentalnych praktyk bezpieczeństwa powinno być zapewnienie szyfrowania komunikacji pomiędzy interfejsami administracyjnymi a użytkownikiem. W rzeczywistości taka sytuacja ma miejsce stosunkowo rzadko, co producenci zrzucają na karb parametrów technicznych bądź co bądź “słabych” urządzeń.

W ten sposób klient zamiast SSH dostaje usługę Telnet, zamiast HTTPS/HTTP (niektóre modele posiadały co prawda obie usługi uruchomione jednocześnie, co zaprzeczało wersji dostawców, ale w takim wypadku i tak nie następowało automatyczne przekierowanie do instancji szyfrowanej). Podobna argumentacja producentów miała miejsce, gdy zwracano uwagę na niedostateczną długość klucza (przeważnie 1024 bity), choć nie udało mi się dotrzeć do wyników testów wydajnościowych.

Z drugiej strony, jeśli ruch do GUI mógł odbywać się w sposób zabezpieczony kryptograficznie, okazywało się, że certyfikat był podpisany własnoręcznie, a tym samym niezaufany. W dodatku wygasł 5 lat wcześniej (…).

Ukryte możliwości

Przy walidowaniu dwóch urządzeń tego samego producenta, dostosowywanych do działania z innymi usługami okazało się, że dostęp do niektórych funkcji usunięto jedynie pozornie. Skrypty w dalszym ciągu znajdowały się w systemie, a producent skasował jedynie odnośniki do nich. Niestety jest to bardzo popularna praktyka, najprawdopodobniej wynikająca z pośpiechu.

Co jeszcze?

Oczywiście luk bywa znacznie więcej, ale nie powtarzają się w co drugim testowanym rozwiązaniu, jak opisane powyżej. Zdarzały się takie, które były konsekwencją złej implementacji standardów czy protokołów sieciowych (podatne implementacje WPS czy UPnP); sterowania pamięcią (przepełnienia buforów); przekazywaniu danych pochodzących od użytkownika do powłoki (remote code execution), zarządzania sesją (auth bypass); błędów w logice aplikacji (m.in. Denial of Service) i wiele wiele innych.

Wnioski

Jak łatwo zauważyć, jedna rzecz wynika z drugiej, tworząc w ten sposób łańcuch uchybień w bezpieczeństwie. Routery SOHO zawsze będą na celowniku hakerów jako relatywnie łatwy w zdobyciu przyczółek do dalszej nielegalnej działalności – przeprowadzania kolejnych ataków, budowy botnetów, etc., toteż ich oprogramowanie powinno być cyklicznie poddawane testom bezpieczeństwa. Wszechobecny pęd do urządzeń Internetu Rzeczy sprawia, że czeka nas jeszcze dużo ciekawego researchu i zarazem mnóstwo przypadków zaniedbań kwestii bezpieczeństwa.

Kamil Uptas