Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W ekosystemie OpenWrt ujawniono publiczny proof-of-concept opisujący podatność prowadzącą do zdalnego wykonania poleceń po uwierzytelnieniu w komponencie luci-app-https-dns-proxy. Problem dotyczy mechanizmu administracyjnego dostępnego przez interfejs UBUS/LuCI i może skutkować uruchomieniem komend systemowych z wysokimi uprawnieniami. W praktyce oznacza to, że użytkownik posiadający ograniczony dostęp do określonej funkcji aplikacji może doprowadzić do przejęcia konta root na urządzeniu.
W skrócie
- Podatność ma charakter command injection w komponencie
luci-app-https-dns-proxydla OpenWrt 23.05. - Atak wymaga poprawnego uwierzytelnienia oraz dostępu ACL do metody
setInitActionw przestrzeniluci.https-dns-proxy. - Skutkiem może być wykonanie dowolnych poleceń systemowych i trwała eskalacja uprawnień do roota.
- Przejęcie routera może otworzyć drogę do podsłuchu ruchu, manipulacji DNS i dalszej kompromitacji sieci.
Kontekst / historia
OpenWrt jest szeroko stosowaną platformą dla routerów i urządzeń brzegowych, a interfejs LuCI wraz z UBUS stanowi podstawę zdalnej administracji. Rozszerzenia LuCI często udostępniają operacje serwisowe, takie jak uruchamianie, zatrzymywanie lub przeładowywanie usług. Jeżeli dane wejściowe przekazywane do takich mechanizmów nie są odpowiednio walidowane lub bezpiecznie mapowane na dozwolone akcje, pojawia się klasyczny wektor wstrzyknięcia poleceń.
Publicznie opublikowany materiał wskazuje, że problem dotyczy wersji testowanych na OpenWrt 23.05 i może obejmować wydania dostępne przed 17 stycznia 2026 roku. W momencie publikacji opis koncentruje się na publicznym PoC, a nie na szeroko udokumentowanym procesie naprawczym. Z operacyjnego punktu widzenia oznacza to, że administratorzy korzystający z dodatku DNS-over-HTTPS powinni traktować temat priorytetowo i zweryfikować stan wdrożenia.
Analiza techniczna
Scenariusz ataku opiera się na komunikacji JSON-RPC z endpointem /ubus. Napastnik loguje się przy użyciu prawidłowych danych uwierzytelniających użytkownika posiadającego odpowiednie uprawnienia ACL, a następnie wywołuje metodę setInitAction, przekazując kontrolowany parametr name oraz akcję start.
Kluczowym elementem problemu jest brak bezpiecznej sanitacji wartości name. Publiczny proof-of-concept pokazuje, że spreparowany parametr może zawierać dodatkowe polecenia powłoki, co prowadzi do wykonania nieautoryzowanych instrukcji systemowych. Taki przebieg wskazuje, że wartość wejściowa trafia do kontekstu wykonania polecenia bez właściwego ograniczenia do zaufanej listy nazw usług lub bez poprawnego escapowania argumentów.
W efekcie mamy do czynienia z uwierzytelnionym RCE połączonym z eskalacją uprawnień na urządzeniu. Atakujący nie musi posiadać pełnego dostępu administracyjnego do całego systemu, lecz jedynie możliwość wywołania konkretnej funkcji w UBUS. To szczególnie istotne w środowiskach, w których deleguje się część uprawnień operatorom, kontom technicznym albo procesom automatyzacji.
Choć w demonstracji skutkiem była zmiana hasła użytkownika root, wektor może zostać wykorzystany również do innych działań, takich jak dodanie klucza SSH, modyfikacja konfiguracji zapory, podmiana ustawień DNS, pobranie dodatkowego ładunku czy osadzenie trwałego backdoora. Najważniejsze z perspektywy bezpieczeństwa jest samo uzyskanie możliwości arbitralnego wykonania poleceń na urządzeniu brzegowym.
Konsekwencje / ryzyko
Ryzyko operacyjne i biznesowe jest wysokie, ponieważ router z OpenWrt często pełni funkcję bramy sieciowej, punktu styku z Internetem, koncentratora VPN lub urządzenia filtrującego ruch. Przejęcie takiego hosta może prowadzić do podsłuchu ruchu, przekierowań DNS, ataków typu man-in-the-middle, osłabienia polityk bezpieczeństwa oraz dalszej kompromitacji systemów wewnętrznych.
Szczególnie niebezpieczny jest fakt, że exploit nie wymaga pełnego konta administracyjnego, lecz tylko dostępu do wrażliwej metody UBUS. Oznacza to, że kompromitacja konta o ograniczonych uprawnieniach może wystarczyć do pełnego przejęcia urządzenia. W organizacjach opierających się na granularnym modelu ACL taka luka podważa założenia separacji uprawnień.
Dodatkowym problemem jest możliwość cichego utrzymania dostępu. Zmiana hasła roota, dopisanie klucza SSH, modyfikacja autostartu czy korekta reguł zapory nie zawsze są natychmiast wykrywane, zwłaszcza jeśli monitoring ogranicza się do podstawowej dostępności usług. Skutki mogą ujawnić się dopiero podczas analizy incydentu lub po wystąpieniu anomalii w ruchu sieciowym.
Rekomendacje
W pierwszej kolejności należy ustalić, czy na urządzeniach działa pakiet luci-app-https-dns-proxy oraz czy wdrożona wersja została już poprawiona. Jeśli organizacja nie ma jeszcze potwierdzonej aktualizacji w swoim kanale dystrybucji, rozsądnym działaniem tymczasowym może być wyłączenie lub odinstalowanie pakietu, o ile nie jest krytyczny dla działania środowiska.
Kolejnym krokiem powinien być przegląd ACL użytkowników LuCI i UBUS, ze szczególnym uwzględnieniem dostępu do przestrzeni luci.https-dns-proxy i metody setInitAction. Uprawnienia do tej funkcji należy ograniczyć do absolutnego minimum. Warto również sprawdzić, czy nie istnieją konta techniczne, testowe lub dawno nieużywane, które zachowały niepotrzebny dostęp.
- ograniczyć dostęp administracyjny do LuCI wyłącznie z zaufanych segmentów sieci,
- wymusić silne hasła i rotację poświadczeń,
- monitorować zmiany kont root, kluczy SSH, konfiguracji DNS i reguł firewall,
- włączyć centralizację logów dla działań administracyjnych,
- regularnie aktualizować pakiety LuCI oraz komponenty powiązane,
- przeprowadzić audyt konfiguracji po każdym podejrzeniu nadużycia.
W przypadku podejrzenia wykorzystania luki warto sprawdzić historię zmian konfiguracji, pliki autostartu, zadania harmonogramu, wpisy w authorized_keys, integralność ustawień DNS i zapory oraz wszystkie niestandardowe procesy uruchamiane na urządzeniu. W środowiskach produkcyjnych zasadna może być pełna reinstalacja z zaufanego obrazu oraz zmiana wszystkich poświadczeń, które mogły zostać naruszone.
Podsumowanie
Publiczny proof-of-concept dla OpenWrt 23.05 wskazuje na poważny problem w luci-app-https-dns-proxy, gdzie uwierzytelniony użytkownik z odpowiednim ACL może doprowadzić do wykonania poleceń i przejęcia uprawnień root. Mimo że atak wymaga logowania, jego znaczenie pozostaje wysokie ze względu na rolę routera w infrastrukturze oraz możliwość obejścia modelu ograniczonych uprawnień. Administratorzy powinni niezwłocznie zweryfikować obecność pakietu, zredukować uprawnienia do wrażliwych metod UBUS, wdrożyć poprawki i skontrolować urządzenia pod kątem śladów kompromitacji.
Źródła
- Exploit Database – OpenWrt 23.05 – Authenticated Remote Code Execution (RCE) https://www.exploit-db.com/exploits/52521
- GitHub – stangri/luci-app-https-dns-proxy https://github.com/stangri/luci-app-https-dns-proxy
- OpenWrt – Technical Reference / UBUS https://openwrt.org/docs/techref/ubus
- OpenWrt – LuCI Documentation https://openwrt.org/docs/guide-user/luci/luci.essentials