Gdzie kończy się bezpieczeństwo sieci domowej, a zaczyna dziki zachód? Historia podatności i jej „usuwania”.

Wstęp

W artykule chciałbym podzielić się moimi doświadczeniami związanymi ze zgłoszeniem podatności w routerach dostarczanych przez dostawców Internetu (ISP) oraz procesem jej późniejszego „usuwania”.

Ze względu na niską złożoność ataku oraz konsekwencję jej wykorzystania czuję moralny obowiązek podzielenia się spostrzeżeniami. Celem artykułu jest pokazanie, jak w praktyce wygląda obsługa podatności w urządzeniach, nad którymi użytkownik końcowy ma ograniczoną kontrolę oraz jakie wnioski można z tego wyciągnąć dla bezpieczeństwa własnej sieci domowej.

Początek historii

Historia zaczyna się 26 czerwca 2025 roku, kiedy przestał działać u mnie Internet. W czasie oczekiwania na przywrócenie usługi, z czystej ciekawości postanowiłem przyjrzeć się routerowi dostarczonemu przez operatora.

Podczas analizy okazało się, że urządzenie działa w oparciu o system OpenWRT 19.07.6. Od tego momentu dalsze kroki były już dość naturalne – OpenWRT jest dobrze udokumentowanym systemem, a jego architektura i mechanizmy są powszechnie znane.

Analiza techniczna

OpenWRT udostępnia interfejs API ubus, który w tym przypadku był dostępny przez protokół HTTP. Webowy panel administracyjny producenta nie stanowi odrębnej warstwy serwerowej – w praktyce jest to aplikacja kliencka, która z poziomu przeglądarki użytkownika wywołuje bezpośrednio endpointy API ubus, przekazując tokeny sesyjne i parametry operacji w jawnej postaci.

Ta obserwacja skierowała mnie do próby nadużycia tego interfejsu w sposób, którego producent najwyraźniej nie przewidział. Przeglądając dostępne obiekty i procedury API, szybko okazało się, że jedna z nich umożliwia wykonywanie poleceń na poziomie systemu operacyjnego (procedura exec z obiektu file). W praktyce oznaczało to dostęp do powłoki systemowej i możliwość wykonania pełnego zrzutu systemu plików urządzenia.

Przykładowe wywołanie API ubus:

$cmdPayload = @{
    jsonrpc = "2.0"
    id      = 1
    method  = "call"
    params  = @(
        $SessionToken,
        "file",
        "exec",
        @{
            command = "whoami"
        }
    )
}

Invoke-RestMethod -Uri https://$RouterIP/ubus -Method Post -Body $cmdPayload -ContentType "application/json"

W tym momencie analiza weszła w kolejny etap. Posiadając kompletny obraz systemu, możliwe stało się spokojne przyjrzenie się rozwiązaniom dodanym przez producenta – w szczególności skryptom i mechanizmom, które nie są częścią standardowej dystrybucji OpenWRT. To właśnie w tych elementach ujawniły się problemy, które w kolejnych krokach doprowadziły do pełnego zdalnego wykonania kodu.

Źródło podatności

Podczas analizy natrafiłem na skrypt powłoki odpowiedzialny za obsługę obiektu ubus kaonsessionhelper, służący do tworzenia sesji ubus po zalogowaniu się do panelu WWW.

Skrypt ten zawierał zaszyte na stałe poświadczenia systemowego użytkownika:

• użytkownik: kaonwebui
• hasło: kaonwebui
• użytkownik posiadał uid i gid 0
  • oznacza to, że użytkownik posiada te same uprawnienia co użytkownik root.

Stałe poświadczenia zaszyte w firmware urządzenia umożliwiały utworzenie sesji ubus przy użyciu procedury login obiektu session. Co istotne, proces ten nie wymagał znajomości poświadczeń abonenta ani dostępu do jego panelu administracyjnego. W praktyce dawało to pełny dostęp do API, a w konsekwencji — pełną kontrolę nad urządzeniem.

Interfejs ten dostępny jest za pośrednictwem usługi HTTP (port 80 i 443). Domyślnie usługa ta udostępniana jest wyłącznie w sieci lokalnej (LAN), jednak znane są przypadki, w których użytkownicy wystawiają ją również na interfejs WAN.

Proces zgłoszenia podatności

W związku z powyższym odkryciem:

• 27 czerwca 2025 – podatność została przeze mnie opisana i zgłoszona do CERT Polska.
• 3 lipca 2025 – CERT Polska poprosił o dodatkowe informacje oraz poinformował o rezerwacji numeru CVE.
• Został zarezerwowany identyfikator CVE-2025-7072, a CERT zadeklarował kontakt z producentem oraz operatorami w celu potwierdzenia podatności i skoordynowania publikacji.

Kolejne etapy komunikacji wyglądały następująco:

• 5 sierpnia 2025 – informacja, że producent przygotował poprawki, które mają trafić do kolejnej wersji oprogramowania.
• 26 sierpnia 2025 – poprawki w fazie testów u jednego z operatorów.
• 7 października 2025 – poprawki przekazane kolejnemu operatorowi, również w fazie testów.
• 9 stycznia 2026 – oficjalna publikacja opisu podatności jako CVE-2025-7072.
• 12 stycznia 2026 – podjąłem próbę weryfikacji skuteczności wdrożonych poprawek – wdrożone poprawki uważam za nieskuteczne.
• 12 stycznia 2026 – w związku z powyższymi ustaleniami zgłosiłem do CERT Polska informację o nieskuteczności wdrożonych poprawek oraz o istnieniu dodatkowego wektora dostępu.

Na tym etapie warto podkreślić rolę CERT Polska, który odpowiadał za koordynację procesu obsługi podatności oraz komunikację z producentem i dostawcami Internetu (ISP) za co serdecznie dziękuję.

Weryfikacja poprawek

12 stycznia 2026 roku postanowiłem zweryfikować skuteczność wprowadzonych poprawek.

Analiza wykazała, że:

• zmieniono nazwę użytkownika oraz hasło – jednak nadal były one bardzo proste,
• przeniesiono miejsce przechowywania poświadczeń ze skryptu do plików konfiguracyjnych,
• dodatkowo zidentyfikowałem hasło użytkownika root, które:
  • było takie samo w aktualnej wersji oprogramowania oraz przed poprawkami,
  • nie zostało zmienione w ramach wydanej poprawki.

W praktyce oznacza to, że podatność nie została usunięta w sposób trwały, a jedynie częściowo zamaskowana. Z tego powodu uznałem poprawkę za nieskuteczną. Informacja o nieskuteczności poprawki została przekazana do CERT Polska.

Wnioski i refleksje

Na tym etapie naturalnie pojawia się pytanie:
W jakim stopniu producenci i operatorzy są w stanie zadbać o bezpieczeństwo urządzeń, które trafiają do milionów użytkowników?

Nie jest to pytanie z tezą. Model biznesowy operatorów, skala wdrożeń, długie cykle testowe oraz zależności pomiędzy producentem a dostawcami usług powodują, że proces reagowania na podatności bywa długi i skomplikowany.

Ostateczną ocenę pozostawiam czytelnikowi.

Kto by pomyślał, że 15 minutowy black-out routera może zaprowadzić do podatności?

Własny router za urządzeniem operatora: wady i zalety

Na podstawie powyższych doświadczeń warto rozważyć architekturę, w której router dostarczony przez operatora pełni jedynie rolę modemu lub urządzenia dostępowego, a właściwą bramą sieciową jest własny, zarządzany przez użytkownika router. Co ważne router powinien pochodzić od renomowanego producenta lub takiego który umożliwia wgranie alternatywnego oprogramowania np. OpenWRT.

Takie podejście ma kilka istotnych zalet:

1. Pełna kontrola nad aktualizacjami

Posiadając własny router:

• samodzielnie decydujemy o wersji oprogramowania,
• mamy możliwość szybkiego reagowania na nowe podatności,
• nie jesteśmy uzależnieni od harmonogramów operatora.

2. Transparentność konfiguracji

Własny router to:

• brak nieudokumentowanych użytkowników systemowych,
• brak ukrytych usług oraz możliwość wyłączenia mechanizmów zdalnego zarządzania,
• możliwość audytu konfiguracji i usług działających na urządzeniu.

3. Separacja odpowiedzialności

Router operatora:

• musi spełniać wymagania masowej infrastruktury,
• często zawiera dodatkowe mechanizmy diagnostyczne lub zarządcze.

Własny router:

• służy wyłącznie użytkownikowi i jego sieci,
• może być skonfigurowany zgodnie z indywidualnym modelem zagrożeń.

4. Lepsza segmentacja sieci

Dodatkowa warstwa routingu umożliwia:

• skuteczną separację sieci domowej od infrastruktury operatora,
• możliwość wdrożenie VLAN-ów, firewalli czy VPN-ów,
• ograniczenie skutków ewentualnych podatności w urządzeniu operatora.

Natomiast jak każde rozwiązanie to również ma swoje wady o których warto wspomnieć:

1. Podwójny NAT
   • problemy z port forwardingiem (trzeba przekierowywać porty na dwóch urządzeniach),
   • problemy z niektórymi protokołami VPN (szczególnie IPsec, L2TP),
   • mogą pojawić się problemy z dostępem do telewizji dostarczanej przez ISP.
2. Większa złożoność konfiguracji

Dwa urządzenia to:

• dwa firewalle,
• dwa NAT-y,
• często dwa DHCP,
• dwa miejsca, gdzie coś może być źle ustawione,
• więcej punktów awarii.

Efekt:

Debugowanie problemów sieciowych jest trudniejsze.

Natomiast możemy przeciwdziałać niektórym wadom w zależności od możliwości:

1. Bridge na urządzeniu ISP
   • router ISP działa jak modem,
   • brak podwójnego NAT-a.
2. DMZ na urządzeniu ISP
   • cały ruch przychodzący przekierowywany jest na nasze urządzenie,
   • nadal NAT, ale mniejsza złożoność konfiguracji.

Podsumowanie

Opisana historia pokazuje, że zaufanie do dostawcy usługi nie zawsze idzie w parze z realną kontrolą nad urządzeniem, które staje się bramą do naszej sieci. Problem polega na tym, że użytkownik końcowy ma bardzo ograniczony wpływ na jego konfigurację, aktualizacje i sposób reagowania na podatności. Skutki takiego modelu stają się szczególnie widoczne, gdy spojrzymy na dane dotyczące podatnych urządzeń obecnych w publicznej przestrzeni Internetu.

Według danych z zoomeye.ai w polskich sieciach nadal widocznych jest około 300 podatnych routerów. Każdy z nich to potencjalny element cudzej infrastruktury – węzeł botnetu, punkt przesiadkowy lub punkt do dalszych ataków. Najczęściej bez wiedzy i świadomości jego właściciela. Przykładem realnej kampanii, która pokazała jak taka infrastruktura może wyglądać w praktyce, jest botnet AyySSHush, opisany przez zespół GreyNoise Labs na początku 2025 roku. W ramach tej operacji cyberprzestępcy wykorzystali luki w oprogramowaniu routerów ASUS do utworzenia ukrytego dostępu SSH w tysiącach urządzeń, a analizy Censys i innych narzędzi wskazały ponad 9 000 faktycznie przejętych routerów na całym świecie.

Własny router, umieszczony za urządzeniem operatora, nie jest gwarancją bezpieczeństwa, ale pozwala odzyskać coś znacznie ważniejszego: kontrolę nad tym, co dzieje się w naszej sieci, a od kontroli zaczyna się świadome bezpieczeństwo.

~Piotr Ługowski