MikroTik udostępnił poprawki bezpieczeństwa we wszystkich kanałach RouterOS. Producent nie ujawnia szczegółów podatności, ale określa aktualizację jako ważną i zaleca ją wszystkim użytkownikom. CERT Polska powtarza to zalecenie i dodaje punkt, który łatwo przeoczyć: po aktualizacji trzeba sprawdzić, czy urządzenie nie zostało wcześniej przejęte.
Co się stało
Zespół CERT Polska poinformował o wydaniu nowych wersji RouterOS zawierających poprawki bezpieczeństwa. Podatność została załatana, ale MikroTik świadomie nie publikuje jej szczegółów – chce dać administratorom czas na zabezpieczenie urządzeń, zanim opis luki trafi do publicznego obiegu.
Producent w komunikacie do wydania podkreśla dwie rzeczy jednocześnie: to ważna aktualizacja bezpieczeństwa oraz większość konfiguracji nie jest zagrożona. Mimo tego drugiego zdania zalecenie aktualizacji obejmuje wszystkich użytkowników – bez wyjątków i bez „u nas to nie dotyczy”.
Wersje z poprawką
Łatki trafiły do wszystkich kanałów RouterOS:
| Kanał | Wersja | Wydanie |
|---|---|---|
| Long-term (v6) | 6.49.21 | forum MikroTik |
| Long-term (v7) | 7.23.4 | forum MikroTik |
| Stable | 7.24.2 | forum MikroTik |
| Development | 7.25beta | forum MikroTik |
Poprawka jest dostępna w każdej gałęzi, więc nie ma powodu, by zwlekać z aktualizacją „do czasu, gdy pojawi się wersja w naszym kanale”.
Jedna uwaga dla środowisk trzymanych na long-term: nowym wydaniem long-term jest 7.23.4. Jeśli infrastruktura pracuje na starszej gałęzi long-term (np. 7.21.x), aktualizacja oznacza przeskok o dwie wersje minor i większy zakres zmian konfiguracyjnych niż zwykły update poprawkowy. Nie jest to argument, żeby jej nie robić – jest to argument, żeby zrobić ją w kontrolowanym oknie serwisowym, z eksportem konfiguracji i planem wycofania.
Aktualizacja to dopiero połowa pracy
To najważniejszy fragment komunikatu CERT Polska i to on najczęściej ginie w pośpiechu.
Po wykonaniu upgrade’u RouterOS sam przeprowadza kontrolę konfiguracji. Jeśli wykryje oznaki nieautoryzowanego dostępu, ustawia urządzenie w stanie „Flagged”, a odpowiedni komunikat krytyczny zapisuje w sekcji Log. Pierwszą czynnością po restarcie powinno być więc zajrzenie do logów – nie sprawdzenie, czy „internet działa”.
Brak statusu „Flagged” nie jest jednak certyfikatem czystości. Mechanizm wykrywa znane wzorce, nie wszystko. Dlatego po aktualizacji należy przejrzeć konfigurację ręcznie, szukając elementów, których nikt z zespołu nie dodawał: nieznanych użytkowników, skryptów, harmonogramów, tuneli, reguł NAT.
Status „Flagged” – co oznacza i czego nie robić
RouterOS podczas uruchamiania może przeanalizować konfigurację pod kątem śladów nieautoryzowanego dostępu. Gdy wykryje podejrzane elementy, wyłącza je i ustawia parametr flagged na yes. Urządzenie przechodzi wtedy w specjalny stan z ograniczeniami:
- blokowane są narzędzia takie jak bandwidth-test, traffic-generator i sniffer,
- system nie pozwala tworzyć nowych wpisów m.in. dla harmonogramów, serwera SOCKS, PPTP, L2TP, IPsec, proxy i SMB.
Podstawowa konfiguracja nadal działa, co bywa mylące – kusi, żeby po prostu wyjść ze stanu „Flagged” i wrócić do pracy. To najgorsza możliwa reakcja. Zalecenie MikroTika jest jednoznaczne: pojawienie się tego statusu należy traktować jako założenie, że urządzenie zostało skompromitowane, i przeprowadzić pełny audyt konfiguracji.
Kolejność działań powinna wyglądać tak:
- pełny przegląd konfiguracji pod kątem nieznanych użytkowników, skryptów, reguł i zmian, których nikt nie wprowadzał,
- zmiana wszystkich haseł systemowych (oraz kluczy SSH i tokenów integracji),
- aktualizacja RouterOS do najnowszej dostępnej wersji,
- dopiero na końcu wyjście ze stanu „Flagged”, zgodnie z dokumentacją producenta,
- przywrócenie urządzenia do normalnej eksploatacji.
To, że RouterOS automatycznie wyłączył podejrzane elementy, nie znaczy, że wyłączył wszystkie. Automat nie zwalnia z audytu.
Co sprawdzić po aktualizacji – szybka lista kontrolna
Minimalny zakres weryfikacji z poziomu terminala:
# wersja i firmware
/system resource print
/system routerboard print
# ślady w logach
/log print where message~"flagged"
# konta, klucze, dostęp
/user print detail
/user ssh-keys print
/ip service print
/ip firewall filter print detail
# najczęstsze miejsca ukrywania persystencji
/system script print detail
/system scheduler print detail
/file print
/ip socks print
/ip proxy print
/ip firewall nat print detail
/ppp secret print detail
/interface print detail
/ip dns print detail
/tool e-mail print
/ip cloud print
/certificate print
Na co zwracać szczególną uwagę: skrypty i harmonogramy uruchamiające fetch, konta serwisowe o nazwach zbliżonych do istniejących, włączony SOCKS lub proxy, nieznane tunele (L2TP, PPTP, SSTP, WireGuard, EoIP, GRE), podmienione serwery DNS, reguły dst-nat przekierowujące ruch do środka sieci oraz pliki .rsc i backupy, których nikt nie wgrywał.
Po zakończeniu upgrade’u RouterOS warto też zaktualizować firmware urządzenia (System → RouterBOARD → Upgrade) i wykonać restart – bez tego część poprawek niskopoziomowych nie zostanie zastosowana.
Czy znamy szczegóły podatności?
Nie. Na moment publikacji tego wpisu nie ma przypisanych numerów CVE, nie opublikowano opisu technicznego ani publicznego PoC. MikroTik zapowiada uzupełnienie informacji w późniejszym terminie, a CERT Polska poinformował, że zaktualizuje swój komunikat po oficjalnym ujawnieniu szczegółów.
W changelogu wydania stabilnego znajduje się wpis o refaktoryzacji wewnętrznych procesów SSH i część społeczności łączy go z poprawką bezpieczeństwa. To wyłącznie spekulacja – podobny wpis pojawił się także w poprzednim wydaniu, a producent nie potwierdził żadnego wektora. Nie należy na tej podstawie zakładać, że wystarczy ograniczyć dostęp do SSH zamiast aktualizować.
Warto natomiast pamiętać o tym, jak działa okno czasowe przy takich wydaniach. Producent wstrzymuje szczegóły, bo różnica między wersją poprzednią a poprawioną znacznie zawęża obszar poszukiwań dla analityków – zarówno tych po dobrej, jak i po złej stronie. Historycznie odstęp między publikacją łatki MikroTika a pojawieniem się analizy w sieci liczony był w dniach, nie tygodniach.
Uwagi praktyczne z pierwszych godzin po wydaniu
- W pierwszych godzinach po publikacji zgłaszano problemy z funkcją Check For Updates i opóźnienia serwerów mirror. Jeśli aktualizacja „przechodzi”, a po restarcie urządzenie zgłasza starą wersję – powtórz próbę lub wgraj pakiet ręcznie z strony pobierania MikroTika.
- Przed aktualizacją: eksport konfiguracji (
/export file=) i backup binarny, oba zapisane poza urządzeniem. - Zapewnij urządzeniu stabilne zasilanie na czas upgrade’u i wolne miejsce w pamięci na pakiety.
- Zdalne oddziały aktualizuj z dostępem out-of-band, jeśli nim dysponujesz.
Rekomendacja
Kolejność jest prosta i nie warto jej zmieniać: zaktualizuj, sprawdź logi, przejrzyj konfigurację, wymień hasła. Sama instalacja poprawki nie zamyka tematu – zamyka go dopiero potwierdzenie, że w konfiguracji nie ma śladów cudzej obecności.
Jeśli w Twojej sieci pracuje kilkadziesiąt urządzeń MikroTik w rozproszonych lokalizacjach, ręczne przejście przez tę listę na każdym z nich to realny problem organizacyjny. W DSERVE prowadzimy takie akcje aktualizacyjne dla klientów w ramach usług utrzymania infrastruktury i monitoringu 24/7 – od inwentaryzacji wersji, przez kontrolowane okna serwisowe, po audyt konfiguracji po upgrade’zie i weryfikację śladów kompromitacji.
Potrzebujesz wsparcia przy tej aktualizacji? Skontaktuj się z nami.
Źródła
- CERT Polska – komunikat o poprawkach bezpieczeństwa RouterOS
- RouterOS 6.49.21 (long-term)
- RouterOS 7.23.4 (long-term)
- RouterOS 7.24.2 (stable)
- RouterOS 7.25beta (development)
- MikroTik – strona bezpieczeństwa