2026-09-06

MikroTik pod ostrzałem: sześć luk w RouterOS, które napastnicy już łączą w jeden atak

Bezpieczeństwo

Jeśli w firmie działa MikroTik RouterOS, a szczególnie jeśli usługa SSH jest dostępna z Internetu, ten komunikat wymaga pilnej reakcji. CERT Polska opisał sześć podatności w RouterOS, z których dwie tworzą łańcuch ataku nazwany MikroTrick. Co najważniejsze, wykorzystanie tego łańcucha przeciwko urządzeniom z publicznie dostępnym SSH zostało już potwierdzone w rzeczywistych atakach.

Co dokładnie znaleziono

Analiza CERT Polska obejmuje sześć błędów: CVE-2026-67276, CVE-2026-67277, CVE-2026-67278, CVE-2026-67279, CVE-2026-67281 oraz CVE-2026-86060. Dotyczą różnych fragmentów systemu: SSH, WebFig, usługi bandwidth-test i weryfikacji certyfikatów X.509. Trudno więc mówić o jednej wspólnej przyczynie. Niektóre pozwalają obejść uwierzytelnienie, inne psują kontrolę dostępu już po zalogowaniu, jeszcze inne prowadzą do wycieku pamięci albo zwykłej awarii urządzenia.

Najwięcej uwagi CERT poświęcił dwóm błędom w SSH, bo razem dają atakującemu coś więcej niż suma części.

Jak ktoś może podszyć się pod administratora (CVE-2026-67276)

Klucz publiczny RSA to w skrócie para liczb: moduł n i wykładnik publiczny e. Zmiana któregokolwiek z nich to już inny klucz. Tak przynajmniej powinno to wyglądać w poprawnej implementacji.

RouterOS tego nie pilnował. Przy porównywaniu klucza przedstawionego przez klienta SSH z kluczem przypisanym do konta system sprawdzał moduł n, ale nie weryfikował porządnie wykładnika e. Efekt: dwa różne klucze o tym samym module mogły zostać uznane za ten sam klucz użytkownika. CERT pokazał, że da się to wykorzystać, przygotowując klucz z e = 1, czyli parametrem, przy którym cała operacja RSA traci sens jako zabezpieczenie.

Gorzej, że dalsza weryfikacja podpisu też opierała się na parametrach dostarczonych przez klienta. Ktoś znający publiczny klucz danego użytkownika mógł więc przygotować własny klucz i podpis, które RouterOS po prostu zaakceptował. To nie jest złamanie RSA ani odzyskanie klucza prywatnego. To błąd w logice, która nie traktuje klucza publicznego jako jednej, nierozdzielnej wartości. Skutek jest jednak praktyczny: podszycie się pod użytkownika logującego się kluczem RSA.

Gdy uwierzytelnienie już nie ma znaczenia (CVE-2026-86060)

Druga część układanki dotyczy tego, co dzieje się chwilę później, czyli nadawania uprawnień sesji. RouterOS decyduje na podstawie wewnętrznej maski uprawnień, do czego dana sesja SSH ma prawo: czy może administrować, tylko czytać konfigurację, czy jeszcze coś innego.

CERT wykrył, że odpowiednio skonstruowana nazwa użytkownika potrafi zostać źle zinterpretowana podczas budowania tego kontekstu. To klasyczny argument injection (CWE-88). Nie chodzi o wykonanie polecenia systemowego, tylko o to, że spreparowana wartość zmienia parametry odpowiadające za politykę bezpieczeństwa sesji. W praktyce sesja dostaje więcej niż powinna. CERT potwierdził, że da się w ten sposób uzyskać pełny zestaw uprawnień RouterOS.

Różnica między tymi dwiema lukami jest prosta, choć istotna. Pierwsza odpowiada na pytanie, czy ktoś jest tym, za kogo się podaje. Druga: jakie uprawnienia dostanie sesja, którą już utworzył. Połączone razem, pozwalają przejść przez oba mechanizmy naraz, co CERT opisał jako MikroTrick. Błędne dopasowanie klucza otwiera drzwi do uwierzytelnienia, a manipulacja maską uprawnień daje pełen dostęp administracyjny po drugiej stronie.

Właśnie połączenie CVE-2026-67276 i CVE-2026-86060 tworzy MikroTrick. Efektem nie jest jedynie dostęp do SSH, ale możliwość uzyskania pełnej kontroli administracyjnej nad RouterOS bez prawidłowego uwierzytelnienia.

Pozostałe cztery luki, cztery różne mechanizmy

Reszta błędów działa niezależnie od SSH-owego duetu, choć część też dotyka tego samego protokołu.

Błąd oznaczony jako CVE-2026-67279 tkwi w maszynie stanów samego protokołu SSH. SSH ma swoją kolejność: transport, wymiana kluczy, uwierzytelnienie, dopiero potem kanały i polecenia typu exec. RouterOS gubił ten porządek przy renegocjacji kluczy (rekeyingu) zainicjowanej przed zakończeniem uwierzytelnienia. Stan sesji przestawał wtedy odpowiadać rzeczywistości, a system zaczynał obsługiwać komunikaty z późniejszej fazy protokołu. Nieuwierzytelniony klient mógł w ten sposób otworzyć kanał i wysłać exec, co dawało możliwość tworzenia, nadpisywania i odtwarzania plików.

Inny charakter ma CVE-2026-67281, umiejscowiony w WebFig, dokładnie w komponencie /jsproxy. Łączy dwa problemy naraz. Pierwszy to niezainicjalizowany wskaźnik (CWE-824): nowo zaalokowana struktura sesji mogła odziedziczyć fragment pamięci po innym obiekcie, w tym pozostałość wskaźnika do danych o uprawnieniach. Drugi to klasyczne path traversal w obsłudze URI. Razem dawały nieuwierzytelniony odczyt plików należących do roota, poza sandboxem, w którym WebFig normalnie się porusza.

Trzeci przypadek, CVE-2026-67277, dotyczy usługi bandwidth-test i sam w sobie jest zestawem kilku drobniejszych błędów. Połączenie btest mogło przejść do obsługi testu, zanim sesja nadrzędna skończyła uwierzytelnianie. Do tego dochodzi niepełna inicjalizacja bufora pakietu testowego: część bajtów trafiała do sieci bez nadpisania, więc razem z pakietem wyciekały fragmenty pamięci jądra. Osobny błąd w walidacji długości pakietu, integer underflow na wartości bez znaku, mógł zamienić bardzo małą liczbę w bardzo dużą i doprowadzić do awarii urządzenia.

Ostatni z tej czwórki, CVE-2026-67278, to luka po stronie kryptografii certyfikatów. Weryfikacja podpisów RSA PKCS#1 v1.5 w implementacji X.509 była zbyt liberalna. Nie sprawdzała rygorystycznie całej struktury zdekodowanego bloku: paddingu, separatora, identyfikatora algorytmu i skrótu. Przy kluczu z małym wykładnikiem, na przykład e = 3, dało się przygotować wartość, która przechodziła kontrolę, mimo że nie była prawidłowym podpisem. RouterOS mógł w efekcie zaakceptować certyfikat, którego nikt zaufany faktycznie nie podpisał. Samo w sobie nie otwiera to dostępu do routera, ale podważa integralność weryfikacji TLS tam, gdzie RouterOS sam sprawdza certyfikat drugiej strony.

Dlaczego to więcej niż zwykły biuletyn bezpieczeństwa

Sześć CVE w jednym poście to nie jest rzadkość. Rzadkością jest to, że dotykają niemal wszystkich podstawowych mechanizmów naraz: uwierzytelniania, autoryzacji, stanu protokołu, izolacji plików, zarządzania pamięcią i walidacji kryptograficznej. RouterOS w kilku miejscach podejmował decyzje bezpieczeństwa na podstawie danych, które nie zostały porządnie zweryfikowane. A tam, gdzie błędy dotyczą SSH, dają się łączyć. Właśnie dlatego MikroTrick trafił na listę rzeczy, które trzeba załatać od razu, a nie przy najbliższej okazji.

Ataki już trwają

CERT Polska potwierdził aktywne wykorzystanie tych luk przeciwko urządzeniom z SSH dostępnym publicznie. W obserwowanej kampanii pojawiało się konto ops, a wśród źródeł ataków CERT wskazał adresy 82.192.72.4 i 103.102.31.18. W logach warto szukać wpisów w rodzaju login failure for user -2 from <ip> via ssh albo user <name> added by ssh:-2@<ip>. To ślady konkretnej obserwowanej kampanii, nie pełna lista możliwych oznak. Ich brak niczego nie gwarantuje.

Aktywność nie ogranicza się do obserwacji CERT Polska. 6 września słoweński SI-CERT poinformował, że również otrzymał informacje o przypadkach wykorzystania urządzeń MikroTik posiadających publicznie dostępną usługę SSH.

Które wersje są podatne

Podatność obejmuje szeroki zakres wydań RouterOS. Według informacji CERT Polska podatne są RouterOS od 6.0.0 do wersji wcześniejszych niż 6.49.21 oraz RouterOS od 7.0.0 do wersji wcześniejszych niż 7.23.4. Podatna jest również linia 7.24 przed wydaniem 7.24.2. Oznacza to, że samo korzystanie ze starszej wersji Long-term nie chroni przed opisanymi podatnościami.

Poprawki bezpieczeństwa zostały wprowadzone w RouterOS 6.49.21 Long-term, 7.23.4 Long-term oraz 7.24.2 Stable, a także w późniejszych wydaniach zawierających te poprawki.

W przypadku gałęzi 7.23 nie rekomendujemy jednak zatrzymywania się na wersji 7.23.4. MikroTik opublikował RouterOS 7.23.5, ponieważ 7.23.4 wprowadził dodatkowy problem związany z IPv6 DHCP. Administratorzy korzystający z gałęzi Long-term powinni więc aktualizować urządzenia co najmniej do 7.23.5.

W przypadku RouterOS 6 warto potraktować aktualizację do 6.49.21 jako rozwiązanie przejściowe. MikroTik nie rozwija już aktywnie gałęzi RouterOS 6 i zaleca migrację urządzeń do RouterOS 7, o ile dany model sprzętu ją obsługuje.

Aktualizacja to dopiero początek

Jeśli urządzenie było kiedykolwiek dostępne z internetu, samo wgranie poprawki nie zamyka sprawy. Trzeba jeszcze sprawdzić, czy ktoś zdążył je wcześniej zmodyfikować. Nowe wersje RouterOS mają wbudowany mechanizm wykrywający część znanych śladów nieautoryzowanej ingerencji. Status sprawdza się poleceniem /system/device-mode/print, a uwagę powinno zwrócić flagged: yes. należy traktować jako wskazanie możliwej wcześniejszej kompromitacji i podstawę do uruchomienia procedury reagowania na incydent. Jednocześnie brak flagi nie jest dowodem bezpieczeństwa, ponieważ mechanizm wykrywa tylko wybrane, znane ślady ingerencji. Warto przy okazji przejrzeć użytkowników, skrypty, scheduler, konfigurację proxy, tunele VPN, firewall, NAT i routing.

Jeżeli po aktualizacji RouterOS zgłasza flagged: yes, urządzenie należy traktować jako skompromitowane. Nie powinno się od razu usuwać flagi ani podejrzanych elementów konfiguracji. Najpierw trzeba zabezpieczyć logi i materiał potrzebny do analizy incydentu.

Po zabezpieczeniu materiału CERT Polska rekomenduje przywrócenie urządzenia do ustawień fabrycznych i ponowną konfigurację na podstawie zaufanej, zweryfikowanej konfiguracji. Należy również zmienić hasła, klucze i inne sekrety, do których atakujący mógł uzyskać dostęp.

Nie należy automatycznie odtwarzać pełnego backupu wykonanego z potencjalnie skompromitowanego routera. Backup może zawierać konta, skrypty, tunele lub inne zmiany pozostawione przez atakującego. Konfiguracja powinna zostać wcześniej zweryfikowana.

Jak ograniczyć ryzyko na przyszłość

Usługi administracyjne RouterOS, czyli SSH, WinBox, WWW i WWW-SSL, nie powinny wisieć bezpośrednio w internecie bez żadnego ograniczenia. Sensowniej jest wpuszczać do nich ruch przez VPN, dedykowany segment zarządzania albo z konkretnej, ograniczonej puli adresów IP. Do tego dochodzi coś, co często bywa pomijane: centralne zbieranie logów. Jeśli router zostanie później zmodyfikowany albo wyczyszczony, historia zdarzeń i tak zostaje po drugiej stronie.

Jak może pomóc BOIT

W naszej codziennej pracy przy audytach sieci trafiamy na routery brzegowe, które latami stały z domyślną konfiguracją i otwartym dostępem administracyjnym. MikroTik nie jest tu wyjątkiem. Możemy zrobić inwentaryzację urządzeń MikroTik w Twojej sieci, sprawdzić wersje RouterOS i ekspozycję usług administracyjnych, a następnie wykonać aktualizację i zweryfikować konfigurację po jej wgraniu.

Jeśli podejrzewasz, że urządzenie mogło zostać już wykorzystane, możemy przeprowadzić pełniejszy przegląd, obejmujący użytkowników, skrypty, scheduler, VPN, routing, firewall, NAT i pozostałe elementy konfiguracji. Robimy też coś więcej niż łatanie: pomagamy przebudować sposób zarządzania siecią tak, żeby urządzenia brzegowe, zwykle najbardziej uprzywilejowany punkt całej infrastruktury, nie były wystawione na kolejny podobny incydent.

Źródła:

Bartłomiej Ożóg

Spis treści