ProSoft RLX-IFH24E v2.2.44 podatny na złośliwe aktualizacje firmware i wykonanie kodu jako root

Wprowadzenie do problemu / definicja

W urządzeniach przemysłowych OT mechanizm aktualizacji firmware należy do kluczowych elementów ochrony integralności systemu. W przypadku ProSoft RLX-IFH24E z firmware w wersji 2.2.44 opisano podatność polegającą na akceptowaniu pakietów aktualizacyjnych bez skutecznej weryfikacji ich autentyczności i integralności.

Oznacza to, że urządzenie może przyjąć spreparowaną paczkę aktualizacji, a następnie uruchomić zawarte w niej komponenty z najwyższymi uprawnieniami. W praktyce otwiera to drogę do zdalnego wykonania kodu jako root, trwałej modyfikacji systemu oraz przejęcia kontroli nad urządzeniem wykorzystywanym w środowiskach przemysłowych.

W skrócie

Podatność dotyczy przemysłowego radia bezprzewodowego ProSoft RLX-IFH24E.
Mechanizm aktualizacji nie weryfikuje podpisu cyfrowego ani zaufanego skrótu pakietu firmware.
Złośliwa paczka może doprowadzić do wykonania kodu z uprawnieniami root.
Możliwe są także trwałe zmiany konfiguracji i lokalnej bazy kont.
Ryzyko jest szczególnie istotne w środowiskach SCADA, ICS i sieciach automatyki przemysłowej.

Kontekst / historia

ProSoft RLX-IFH24E to przemysłowe radio Ethernet działające w paśmie 2,4 GHz, stosowane do komunikacji bezprzewodowej na potrzeby infrastruktury przemysłowej. Tego typu urządzenia często funkcjonują w środowiskach o wydłużonym cyklu życia, dlatego nawet rozwiązania uznawane za legacy nadal mogą pozostawać częścią aktywnych instalacji.

Opisywany problem dotyczy pakietu firmware oznaczonego jako RLX-IFH24E_v2244.pkg. Analiza koncentruje się na logice mechanizmu aktualizacji oraz zachowaniu instalatora, a nie wyłącznie na specyficznych warunkach jednej konkretnej sieci. To ważne, ponieważ słabość wynika z samego modelu zaufania przyjętego w procesie upgrade’u.

Analiza techniczna

Łańcuch ataku rozpoczyna się od przesłania pliku aktualizacji przez interfejs zarządzający. Komponent odpowiedzialny za upload zapisuje paczkę w katalogu aktualizacji, a następnie przekazuje ją do lokalnego mechanizmu instalacyjnego.

Kluczowy problem polega na tym, że instalator rozpoznaje sposób obsługi pliku na podstawie jego rozszerzenia oraz danych osadzonych w samej paczce. Dla plików typu .pkg wykonywana jest ekstrakcja archiwum, odczyt metadanych i uruchomienie skryptów instalacyjnych, takich jak pre oraz post. Jeżeli identyfikator produktu zapisany w paczce odpowiada oczekiwanej wartości, zawartość zostaje rozpakowana do głównego systemu plików, a skrypty uruchamiane są z uprawnieniami root.

Nie jest to klasyczny przypadek command injection. Sednem problemu pozostaje brak kryptograficznej weryfikacji pakietu aktualizacyjnego. Urządzenie nie sprawdza podpisu cyfrowego, nie wymusza walidacji zaufanego źródła i nie opiera procesu na silnym modelu integralności. W rezultacie atakujący może przygotować paczkę zawierającą oczekiwane metadane i własny kod.

Opis wskazuje również na dodatkowe ścieżki nadużyć. Pliki z określonymi rozszerzeniami mogą nadpisywać elementy odpowiedzialne za konta lokalne lub konfigurację urządzenia. To oznacza, że skutkiem ataku może być nie tylko wykonanie własnego kodu, ale też utworzenie nowego konta uprzywilejowanego, osłabienie polityk dostępowych albo trwała zmiana ustawień systemowych.

Z perspektywy operacyjnej szczególnie niebezpieczne jest to, że cały proces może wyglądać jak zwykła, legalna aktualizacja firmware. Objawy po stronie użytkownika mogą ograniczyć się do standardowego przesłania pliku, komunikatu powodzenia i restartu urządzenia.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość uruchomienia dowolnego kodu jako root na urządzeniu odpowiadającym za transmisję danych w sieci przemysłowej. W środowiskach OT taki element może być krytyczny dla komunikacji pomiędzy systemami nadrzędnymi a urządzeniami polowymi.

trwałe przejęcie urządzenia i utrzymanie persystencji po restarcie,
modyfikacja systemu plików i plików konfiguracyjnych,
dodanie lub podmiana kont uprzywilejowanych,
zmiana parametrów dostępu do interfejsów administracyjnych,
zakłócenie dostępności przez instalację wadliwego obrazu lub wymuszony restart,
pośredni wpływ na ciągłość transmisji danych w systemach przemysłowych.

Poziom ryzyka zależy od tego, czy panel zarządzania jest dostępny z szerzej zaufanych segmentów sieci, jak wygląda kontrola dostępu oraz czy w użyciu pozostają słabe lub domyślne poświadczenia. W starszych środowiskach OT takie warunki nadal występują częściej niż w nowoczesnych systemach IT, co może zwiększać praktyczną wykonalność ataku.

Rekomendacje

Organizacje wykorzystujące urządzenia ProSoft RLX-IFH24E powinny potraktować tę podatność jako istotne zagrożenie dla integralności procesu aktualizacji i bezpieczeństwa komponentów brzegowych OT.

zidentyfikować wszystkie urządzenia RLX-IFH24E i potwierdzić wersje firmware,
ograniczyć dostęp do interfejsów HTTP i HTTPS wyłącznie do wydzielonych sieci administracyjnych,
zablokować dostęp do panelu zarządzania z sieci biurowych, sieci użytkowników końcowych i Internetu,
wzmocnić segmentację pomiędzy strefami IT i OT,
przeprowadzić przegląd lokalnych kont oraz sprawdzić obecność nieautoryzowanych wpisów uprzywilejowanych,
monitorować nieplanowane restarty i zmiany konfiguracji urządzeń,
dopuszczać wyłącznie obrazy firmware pochodzące z kontrolowanego i zaufanego źródła,
wdrożyć mechanizmy kompensacyjne, jeśli poprawka producenta nie jest dostępna,
przygotować plan wymiany urządzeń legacy pełniących krytyczne funkcje operacyjne.

Dobrą praktyką będzie także ograniczenie listy hostów administracyjnych, inspekcja ruchu do interfejsów zarządzających oraz okresowe porównywanie konfiguracji z zatwierdzonym stanem bazowym. W środowiskach ICS i SCADA funkcja aktualizacji firmware nie powinna być dostępna z tych samych segmentów, z których realizowany jest rutynowy dostęp operatorski.

Podsumowanie

Podatność w ProSoft RLX-IFH24E v2.2.44 pokazuje, jak poważne konsekwencje może mieć brak kryptograficznej weryfikacji pakietów aktualizacyjnych. Jeżeli urządzenie ufa danym zawartym w samej paczce, proces upgrade’u staje się pełnoprawną powierzchnią ataku.

Dla zespołów bezpieczeństwa OT to wyraźny sygnał, że ochrona mechanizmów aktualizacji powinna być traktowana priorytetowo. W starszych urządzeniach przemysłowych połączenie słabej kontroli dostępu, braku podpisu firmware i wysokich uprawnień procesów serwisowych może bezpośrednio przełożyć się na utratę integralności oraz dostępności komunikacji przemysłowej.