Backdoor w większości tanich urządzeń Wi-Fi. Jak go odkryto?

Ekstremalnie tanie urządzenia sieciowe dostępne na popularnych platformach zakupowych mogą kryć znacznie więcej zagrożeń, niż sugerowałaby ich prosta funkcja. Badacz bezpieczeństwa Keiran Smith przeanalizował jeden z najtańszych wzmacniaczy sygnału Wi-Fi typu „range extender” i odkrył w jego oprogramowaniu mechanizm, który można traktować jako pełnoprawny backdoor.

Problem nie ograniczał się przy tym do słabego hasła domyślnego. Urządzenie zawierało nieudokumentowane konto root ze stałym hasłem, którego użytkownik nie mógł trwale zmienić, a dodatkowo przy każdym uruchomieniu automatycznie aktywowało usługę Telnet. Analiza ujawniła również kolejne poważne problemy, w tym brak rzeczywistego uwierzytelniania interfejsu administracyjnego oraz możliwość wykonania poleceń systemowych zdalnie.

Tajemniczy sprzęt bez prawdziwego producenta

Badane urządzenie było sprzedawane jako tani wzmacniacz lub repeater Wi-Fi. Jak często zdarza się w przypadku bardzo taniej elektroniki, marka umieszczona w ofercie sprzedażowej nie prowadziła do żadnego konkretnego producenta odpowiedzialnego za projekt sprzętu i firmware.

Po otwarciu urządzenia badacz zidentyfikował płytę główną oznaczoną jako Z05L V1.0. Konstrukcja oparta była między innymi na popularnym układzie MediaTek MT7620, przeznaczonym do niedrogich routerów i urządzeń Wi-Fi. Firmware przechowywany był w pamięci SPI NOR Winbond W25Q32 o pojemności 4 MB. To właśnie fakt, że urządzenie prawdopodobnie jest konstrukcją typu white-label/reference design, stanowi dodatkowy problem. Jeden projekt sprzętowy i jedno oprogramowanie mogą być sprzedawane pod wieloma różnymi nazwami i markami. Oznacza to, że podatność wykryta w jednym pozornie anonimowym urządzeniu może dotyczyć znacznie większej liczby produktów dostępnych na rynku.

Analiza firmware bez zaufania do producenta

Ponieważ producent nie udostępniał łatwo dostępnego firmware do analizy, badacz zdecydował się odczytać zawartość pamięci flash bezpośrednio z urządzenia.

Do tego celu wykorzystano interfejs Bus Pirate i bezpośredni odczyt układu SPI. Takie podejście pozwala uzyskać rzeczywisty obraz oprogramowania znajdującego się w urządzeniu, wraz z konfiguracją, bootloaderem, jądrem systemu oraz elementami, które niekoniecznie byłyby dostępne w oficjalnym pakiecie aktualizacji. Po uzyskaniu pełnego obrazu pamięci flash rozpoczęła się analiza struktury firmware. W pamięci znajdował się obraz systemu Linux dla architektury MIPS. Co szczególnie niepokojące, urządzenie wykorzystywało bardzo stary kernel Linux 2.6.36, mimo że firmware został zbudowany stosunkowo niedawno. System plików urządzenia nie był jednak klasyczną partycją SquashFS. Root filesystem został umieszczony jako skompresowany initramfs wewnątrz obrazu kernela. To właśnie ta dodatkowa warstwa kompresji sprawiła, że najważniejszy sekret urządzenia nie był widoczny podczas prostego przeszukiwania obrazu flash.

Ukryte konto root i hasło wspólne dla wszystkich urządzeń

Najpoważniejsze odkrycie znajdowało się w jednym z głównych programów sterujących urządzeniem – procesie masterCtrl.

Analiza statyczna wykazała obecność zakodowanego na stałe hasła dla użytkownika root. Co istotne, nie było to standardowe hasło administracyjne widoczne dla właściciela urządzenia. Dane logowania były zaszyte bezpośrednio w kodzie programu i wykorzystywane podczas uruchamiania systemu.

0x410bc4 "/etc/group"
0x410bd0 "root"
0x410bd8 "198277tt@"       <-- root password literal
0x410be4 "%s:x:0:%s\n"
0x410c18 "/etc/passwd"
0x410c24 "%s::0:0:Adminstrator:/:/bin/sh\n" <-- note the empty password field
0x410c6c "/tmp/tmpnamepass"
0x410c80 "%s:%s\n"
0x410c88 "chpasswd < /tmp/tmpnamepass"
0x411474 "telnetd&"

Program przy każdym starcie urządzenia odtwarzał pliki /etc/passwd oraz konfigurację kont systemowych, a następnie ustawiał hasło dla konta root. Oznacza to, że nawet gdyby właściciel urządzenia samodzielnie zmienił hasło administratora z poziomu systemu, zmiana znikała po ponownym uruchomieniu urządzenia. To fundamentalna różnica pomiędzy zwykłym słabym hasłem domyślnym a mechanizmem przypominającym backdoor. Domyślne hasło powinno być znane właścicielowi i możliwe do zmiany. W tym przypadku użytkownik:

• nie był informowany o istnieniu dodatkowego mechanizmu dostępu,
• nie miał możliwości trwałego usunięcia dostępu,
• nie mógł zmienić zakodowanego hasła w sposób zachowujący zmianę po restarcie,
• korzystał z urządzenia, które automatycznie przywracało ten sam dostęp root.

Telnet uruchamiany automatycznie przy każdym starcie

Samo istnienie stałego hasła root nie byłoby jeszcze dużym problemem, gdyby urządzenie nie udostępniało usługi pozwalającej na zdalne wykorzystanie tego konta.

Analiza kodu wykazała jednak, że podczas uruchamiania systemu wykonywane było polecenie uruchamiające Telnet.

telnet 192.168.11.1
# login: root
# password: 198277tt@

Usługa była aktywowana automatycznie i nie miała ochrony pod postacią żadnej dodatkowej konfiguracji czy opcji dostępnej dla użytkownika. Badacz nie znalazł mechanizmu, który pozwalałby właścicielowi urządzenia wyłączyć tę funkcję w trwały sposób. W praktyce powstawała więc wyjątkowo niebezpieczna kombinacja:

stałe hasło + konto root + automatycznie uruchamiany Telnet
+ brak możliwości trwałego cofnięcia dostępu

Dodatkowo hasło było wspólne dla całej populacji urządzeń tego typu. Nie było generowane na podstawie numeru seryjnego, adresu MAC ani indywidualnego identyfikatora sprzętu. Oznacza to, że osoba posiadająca informacje o jednym urządzeniu mogła potencjalnie wykorzystać tę wiedzę wobec innych egzemplarzy korzystających z identycznego firmware.

Interfejs WWW, który praktycznie nie chronił urządzenia

Kolejnym poważnym problemem okazał się panel administracyjny dostępny przez przeglądarkę. Z pozoru urządzenie posiadało stronę logowania administratora. Analiza kodu JavaScript oraz serwera WWW wykazała jednak, że mechanizm logowania miał bardzo ograniczoną wartość bezpieczeństwa. Po stronie przeglądarki ustawiany był odpowiedni plik cookie sugerujący, że użytkownik został zalogowany. Badacz przeanalizował backend i odkrył, że API obsługujące funkcje urządzenia nie posiadało rzeczywistego mechanizmu kontroli sesji dla poszczególnych żądań. W praktyce wiele funkcji można było wywoływać bez uprzedniego uwierzytelnienia. To szczególnie niebezpieczne w przypadku urządzenia znajdującego się wewnątrz sieci domowej lub firmowej. Atakujący mający dostęp do tej samej sieci mógł potencjalnie odczytywać lub modyfikować konfigurację urządzenia bez konieczności przechodzenia standardowego procesu logowania.

Command Injection – możliwość wykonywania poleceń systemowych

Analiza firmware ujawniła również kolejną krytyczną podatność: command injection. Jedna z funkcji API pobierała dane przekazane przez użytkownika i umieszczała je bez odpowiedniej walidacji w poleceniu wykonywanym przez system operacyjny.

curl -s -X POST 'http://192.168.11.1/protocol.csp' \
 --data-urlencode 'fname=net' --data-urlencode 'opt=host_list' \
 --data-urlencode 'function=set' --data-urlencode 'type=disconn' \
 --data-urlencode 'mac=;telnetd -l /bin/sh -p 4444;'

Schemat problemu był klasyczny:

1. aplikacja pobiera parametr z żądania HTTP,
2. wartość parametru jest wstawiana do tekstu polecenia,
3. polecenie trafia do funkcji uruchamiającej powłokę systemową,
4. system wykonuje polecenie z wysokimi uprawnieniami.

Co szczególnie interesujące, firmware zawierał funkcję pozwalającą poprawnie walidować adresy MAC, ale nie została ona wykorzystana w analizowanej ścieżce kodu. To ważna lekcja dla producentów i zespołów bezpieczeństwa. Samo istnienie mechanizmu ochronnego w kodzie nie oznacza bezpieczeństwa. Kluczowe jest to, czy mechanizm rzeczywiście chroni konkretną ścieżkę przetwarzania danych.

W przypadku takiej podatności osoba atakująca potencjalnie mogła przejść od zwykłego żądania HTTP do wykonania poleceń systemowych na urządzeniu.

Stary system i brak nowoczesnych mechanizmów ochrony

Firmware analizowanego urządzenia miał również inne cechy charakterystyczne dla przestarzałego i słabo zabezpieczonego oprogramowania embedded. Badacz wskazał między innymi na brak istotnych współczesnych mechanizmów ochrony binariów, takich jak odpowiednie zabezpieczenia stosu czy nowoczesne techniki utrudniające wykorzystanie błędów pamięci. W połączeniu ze starym jądrem Linux tworzy to środowisko, w którym znalezione podatności mogą być znacznie łatwiejsze do wykorzystania niż w nowoczesnych systemach. Warto podkreślić, że problem nie musi wynikać wyłącznie ze starego sprzętu. Badany firmware został zbudowany w 2024 roku, ale opierał się na technologii systemowej mającej znacznie starsze fundamenty. To pokazuje problem często spotykany w świecie IoT– nowy produkt może zawierać oprogramowanie bazujące na komponentach, które od wielu lat nie są już wspierane pod względem bezpieczeństwa.

Aktualizacja firmware bez kryptograficznego podpisu

Analiza mechanizmu aktualizacji ujawniła jeszcze jeden poważny problem. Urządzenie sprawdzało poprawność obrazu firmware między innymi za pomocą CRC32. Taki mechanizm pozwala wykryć przypadkowe uszkodzenie pliku, ale nie zapewnia bezpieczeństwa kryptograficznego. CRC32 nie odpowiada na pytanie, czy firmware został rzeczywiście przygotowany przez producenta.

Odpowiedni mechanizm aktualizacji powinien wykorzystywać podpis kryptograficzny i zaufany klucz producenta. W analizowanym przypadku badacz nie znalazł mechanizmu podpisywania firmware, HMAC ani odpowiedniego systemu weryfikacji autentyczności. Jeżeli urządzenie akceptuje dowolny poprawny technicznie obraz firmware, potencjalny atakujący mający odpowiedni dostęp może próbować uzyskać trwałą kontrolę nad urządzeniem poprzez instalację zmodyfikowanego oprogramowania.

Podsumowanie

Historia taniego wzmacniacza Wi-Fi jest doskonałym przykładem zagrożeń związanych z anonimowym i niedrogim sprzętem IoT. Problem nie polegał na pojedynczym błędzie programistycznym. Badacz odkrył całą kombinację poważnych problemów: nieudokumentowane konto root, stałe hasło wspólne dla wszystkich urządzeń, automatycznie uruchamiany Telnet, brak skutecznego uwierzytelniania API, możliwość command injection oraz niewystarczającą ochronę procesu aktualizacji firmware.

Najbardziej niepokojący jest jednak fakt, że właściciel urządzenia nie miał realnej możliwości trwałego usunięcia ukrytego dostępu. Po restarcie system ponownie odtwarzał konto root i przywracał zakodowaną konfigurację. Dla użytkowników oznacza to prostą zasadę: urządzenie sieciowe nie powinno być oceniane wyłącznie przez pryzmat ceny, liczby anten czy deklarowanego zasięgu Wi-Fi. Każdy router, repeater, kamera czy inne urządzenie IoT staje się częścią infrastruktury sieciowej i potencjalnym punktem wejścia do całej sieci. W przypadku sprzętu niewiadomego pochodzenia szczególne znaczenie ma możliwość otrzymywania aktualizacji bezpieczeństwa, identyfikacja rzeczywistego producenta oraz przejrzystość firmware. Kilka złotych zaoszczędzonych na urządzeniu Wi-Fi może tak naprawdę oznaczać znacznie większy koszt w postaci niekontrolowanego dostępu hakerów do domowej lub firmowej sieci.