CERT Polska potwierdził ataki na RouterOS z usługą SSH dostępną z internetu. Według zespołu połączenie dwóch podatności pozwala przejąć urządzenie bez uwierzytelnienia. W poniedziałek 7 września odpowiedź administratora powinna więc obejmować wdrożenie poprawki i sprawdzenie, czy ktoś wcześniej nie przejął routera.

Czy po otrzymaniu wiadomości „RouterOS zaktualizowany” można zamknąć sprawę? Ostrzeżenie CERT Polska z 5 września daje powód, by przed taką decyzją zadać jeszcze pytanie o wcześniejszy dostęp do urządzenia. Aktualizacja i ocena możliwego przejęcia routera wymagają osobnych ustaleń. Osoba zarządzająca odbiera więc od administratora informacje o ekspozycji SSH, wdrożeniu poprawki oraz przeglądzie kont, skryptów i tuneli. Przyjmijmy te elementy jako zakres pracy nad ostrzeżeniem. Jeśli któregoś ustalenia brakuje, zapiszmy brak przy konkretnym urządzeniu. Potwierdzone przez CERT Polska ataki uzasadniają taką kontrolę, ale same nie dowodzą, że doszło do włamania również w naszej organizacji.

Dwie podatności pozwalają przejąć RouterOS bez uwierzytelnienia

Jak podaje CERT Polska w ostrzeżeniu z 5 września, połączenie dwóch podatności umożliwia przejęcie urządzenia bez uwierzytelnienia. Zespół potwierdził ataki na RouterOS, w których usługa SSH była dostępna z internetu. W ocenie własnego urządzenia trzeba więc ustalić, czy taka ekspozycja występowała. Samo potwierdzenie, że organizacja korzysta z RouterOS, pozostawia to pytanie otwarte.

Weryfikację SSH odnieśmy także do okresu przed poprawką. Poprośmy administratora, by podał, co potrafi ustalić o wcześniejszej dostępności usługi z internetu i na jakiej podstawie. Jeżeli zna wyłącznie stan obecny, ograniczenie powinno pozostać widoczne w odpowiedzi. Nie dopisujmy historii ekspozycji routera na podstawie samego odczytu jego bieżących ustawień.

Możliwość przejęcia RouterOS bez uwierzytelnienia uzasadnia również osobne pytanie o stan urządzenia po aktualizacji. Załatanie aktywnie wykorzystywanych podatności nie powinno więc automatycznie kończyć reakcji na ostrzeżenie.

Potwierdzenie aktualizacji RouterOS nie odpowiada na pytanie, czy ktoś wcześniej przejął router.

Konta, skrypty i tunele wymagają osobnego wyniku przeglądu

Sprawdźmy własną procedurę obsługi aktualizacji RouterOS: czy do zamknięcia zadania wystarcza potwierdzenie instalacji poprawki? Jeśli tak, uzupełnijmy zakres odbioru o wynik przeglądu urządzenia. To propozycja kontroli procedury, a nie opis zaniedbania konkretnego administratora. Przywołane ustalenia CERT Polska nie dają podstaw, by przypisywać komukolwiek w naszej organizacji pominięcie takich czynności.

W przeglądzie kont poprośmy o ustalenie, czy każde z nich ma rozpoznane przeznaczenie i uzasadnioną obecność. Przy skryptach wymagajmy wyjaśnienia ich roli, a przy tunelach potwierdzenia, że odpowiadają zatwierdzonej konfiguracji. Są to proponowane pytania do administratora, które mają nadać kontroli konkretny zakres. Nie przedstawiajmy obecności dowolnego konta, skryptu lub tunelu jako dowodu przejęcia RouterOS.

Wynik przeglądu powinien wskazywać, które wpisy wyjaśniono, które wymagają dalszej oceny i czego nie sprawdzono. Poprośmy o uzasadnienie dla nierozpoznanych elementów konfiguracji. Odpowiedzi „sprawdzimy tunele” nie zapisujmy jako zakończonej kontroli tuneli. Przy każdej niewyjaśnionej pozycji pozostawmy osobę odpowiedzialną za ustalenie jej pochodzenia i termin przekazania wyniku.

Zarząd powinien odebrać ustalenia dotyczące konkretnego routera

Dla każdego urządzenia z RouterOS zbierzmy w jednym miejscu status ekspozycji SSH, potwierdzenie poprawki i wynik przeglądu konfiguracji. Osoba zatwierdzająca zakończenie prac powinna otrzymać odpowiedź odnoszącą się do wskazanego routera. Ogólną deklarację „aktualizacje wykonane” poprośmy uzupełnić o identyfikację urządzenia oraz informację, czy zakończono także sprawdzenie kont, skryptów i tuneli.

Odpowiedzialność za zebranie tych ustaleń przypiszmy jawnie. Jeżeli administrator zakończył aktualizację, lecz potrzebuje czasu na wyjaśnienie obecności skryptu, odnotujmy oba stany. Decyzję o dalszej pracy powiążmy z tym konkretnym brakiem. Nie oznaczajmy całej sprawy jako zamkniętej tylko dlatego, że administrator wdrożył poprawkę.

Rozmowę o kosztach oprzyjmy na oszacowaniu pracy przy własnym RouterOS. Przywołane fakty nie pozwalają wycenić strat naszej organizacji ani potwierdzić, że w ogóle je poniosła. Poprośmy zatem o określenie zakresu i nakładu dalszej weryfikacji, bez przypisywania hipotetycznemu przejęciu kwoty. Jeśli pochodzenie konta, skryptu lub tunelu pozostaje niejasne, wskażmy je w decyzji o kontynuowaniu sprawdzenia.

Zamknięcie sprawy RouterOS powinno wynikać z oceny ekspozycji, poprawki i konfiguracji urządzenia.

CERT Polska potwierdza ataki, a stan własnego routera trzeba ustalić

Dla polskiego odbiorcy punktem odniesienia jest bezpośrednie ostrzeżenie CERT Polska opublikowane 5 września. Na 7 września potwierdzenie aktywnego wykorzystania podatności jest podstawą do pilnego ustalenia stanu własnych urządzeń. Nie trzeba do tego zakładać, że liczba ataków rośnie: przywołane fakty nie dowodzą takiego trendu.

W rozmowie wewnątrz organizacji zachowajmy zakres tego potwierdzenia. CERT Polska opisuje ataki na RouterOS z SSH dostępnym z internetu; informacja ta nie rozstrzyga o przejęciu naszego routera. Nie wyprowadzajmy z niej także liczby poszkodowanych polskich firm. Komunikat instytucji i wynik kontroli własnego urządzenia powinny mieć w raporcie odrębne miejsce.

Do zadania dla administratora dołączmy wskazane ostrzeżenie CERT Polska. Odpowiedź powinna wyjaśniać, jak odnosi się ono do używanego RouterOS: co ustalono o SSH, czy potwierdzono poprawkę i jaki jest wynik przeglądu. Gdy nie udało się odtworzyć wcześniejszej ekspozycji, zapiszmy ją jako nieustaloną. Tak samo potraktujmy brak wyniku kontroli konfiguracji, zamiast zastępować go zapewnieniem o zakończeniu aktualizacji.

Co z tym zrobić w poniedziałek

Każdy punkt przeznacz na najwyżej 30 minut zebrania informacji lub zlecenia pracy nad wskazanym RouterOS. Pełnego przeglądu urządzenia nie uzależniaj od zmieszczenia się w tym czasie.

  1. Ustal status SSH. Wybierz urządzenie z RouterOS i poproś administratora o potwierdzenie obecnej oraz wcześniejszej dostępności SSH z internetu. Zapisz podstawę odpowiedzi. Jeśli brakuje danych o okresie przed poprawką, oznacz ten zakres jako nieustalony.
  2. Odbierz potwierdzenie poprawki. Sprawdź, czy informacja o aktualizacji dotyczy wybranego urządzenia i potwierdza wykonanie pracy. Gdy poprawka jest dopiero planowana albo jej status pozostaje nieznany, przypisz osobę odpowiedzialną za pilne wdrożenie i uzyskaj termin odpowiedzi.
  3. Zleć przegląd kont, skryptów i tuneli. W zgłoszeniu wymień te elementy konfiguracji RouterOS. Poproś o wynik, wskazanie nierozpoznanych wpisów i ograniczeń sprawdzenia. Ustal wykonawcę oraz termin przekazania oceny; jeśli przegląd już zakończono, odbierz jego ustalenia.

Przy aktywnie wykorzystywanych podatnościach RouterOS warunek zakończenia reakcji powinien sięgać poza instalację poprawki. Żądajmy podstawy oceny wcześniejszej ekspozycji SSH i stanu konfiguracji po aktualizacji. Dopóki te ustalenia pozostają otwarte, pozostawmy otwarte także odpowiadające im zadania.

Źródła

  1. CERT Polska: Krytyczne podatności w MikroTik RouterOS są aktywnie wykorzystywane. Zalecana pilna aktualizacja, publikacja: 5 września 2026 r.

Redakcja cyberinsight.pl.