Na początku września MikroTik opublikował ważną aktualizację bezpieczeństwa dla RouterOS. Dwa dni później CERT Polska ujawnił szczegóły sześciu podatności i potwierdził, że część z nich jest już wykorzystywana przeciwko urządzeniom dostępnym z internetu.
Najpoważniejszy scenariusz otrzymał nazwę MikroTrick. To połączenie dwóch błędów związanych z SSH, które w odpowiednich warunkach pozwala przejść od zdalnego połączenia do pełnych uprawnień administracyjnych RouterOS.
Nie oznacza to, że każdy MikroTik podłączony do internetu można automatycznie przejąć. Największe ryzyko dotyczy urządzeń, na których SSH jest osiągalne z publicznych sieci, a wykorzystanie jednej z podatności wymaga dodatkowo informacji związanych z kontem i jego kluczem RSA. Nie zmienia to jednak najważniejszego faktu: CERT Polska potwierdził skuteczne ataki na rzeczywiste urządzenia RouterOS.
Najważniejsze działanie: zaktualizuj RouterOS do poprawionej wersji odpowiedniej dla używanej gałęzi, a następnie sprawdź logi i konfigurację. Sam brak statusu flagged nie jest potwierdzeniem, że router nie został wcześniej przejęty.
Aktualizacja, której nie warto odkładać
MikroTik opublikował poprawki 3 września 2026 roku i określił aktualizację jako istotną z punktu widzenia bezpieczeństwa. Poprawione wydania to:
| Gałąź RouterOS | Wersja zawierająca poprawki |
|---|---|
| Stable | 7.24.2 |
| Long-term | 7.23.4 |
| RouterOS 6 Long-term | 6.49.21 |
| Beta | 7.25beta3 |
Zakres podatnych wersji nie jest identyczny dla wszystkich sześciu błędów, dlatego nie należy sprowadzać problemu do jednej konkretnej gałęzi RouterOS. Najprostsza zasada jest taka: urządzenie powinno pracować na poprawionej wersji odpowiedniej dla używanego kanału.
Czym jest MikroTrick?
CERT Polska opisał sześć podatności w RouterOS. Dwie z nich można połączyć w łańcuch nazwany MikroTrick:
- CVE-2026-67276 - błąd w uwierzytelnianiu SSH przy użyciu kluczy RSA.
- CVE-2026-86060 - możliwość manipulacji uprawnieniami sesji SSH za pomocą odpowiednio przygotowanej nazwy użytkownika.
Pierwszy problem dotyczył sposobu, w jaki RouterOS porównywał klucz RSA przypisany do użytkownika. System nie sprawdzał wszystkich parametrów klucza. W określonych warunkach napastnik znający nazwę użytkownika i publiczną część informacji potrzebnych do identyfikacji jego klucza mógł przygotować inny klucz i przejść uwierzytelnienie bez posiadania właściwego klucza prywatnego.
Druga podatność znajdowała się już na dalszym etapie obsługi logowania SSH. Odpowiednio przygotowana nazwa użytkownika mogła wpłynąć na politykę uprawnień sesji, prowadząc do uzyskania pełnych praw administracyjnych RouterOS.
Dlaczego przejęcie routera jest szczególnie groźne?
Przejęcie routera nie jest tym samym co przejęcie jednego komputera w sieci. Router stoi pomiędzy użytkownikami, serwerami, sieciami VLAN, tunelami VPN i internetem. To on decyduje, którędy popłynie ruch i które segmenty mogą się ze sobą komunikować.
Administrator RouterOS może między innymi:
- Zmieniać reguły firewalla i NAT.
- Modyfikować routing.
- Tworzyć lub zmieniać tunele VPN.
- Zmieniać konfigurację DNS.
- Dodawać konta użytkowników.
- Modyfikować dostęp pomiędzy VLAN-ami.
- Uruchamiać skrypty i zadania schedulera.
Załóżmy, że firma rozdziela komputery pracowników, serwery i monitoring na osobne VLAN-y. Firewall ogranicza komunikację między nimi. Osoba, która uzyska pełną administrację nad routerem, może te zasady zmienić i otworzyć sobie drogę do kolejnych systemów.
Nie oznacza to automatycznego odszyfrowania ruchu chronionego TLS. Przejęta brama sieciowa daje jednak bardzo dobrą pozycję do dalszego rozpoznania infrastruktury, zmiany tras, otwierania dostępu i pozostawienia mechanizmu powrotu do sieci.
Samo włączone SSH nie oznacza jeszcze, że jest wystawione do internetu
W RouterOS usługę SSH można sprawdzić w IP > Services.
Po otwarciu szczegółów usługi widać również pole Available From.
To ważne rozróżnienie. Pokazany router jest urządzeniem laboratoryjnym pracującym wyłącznie w prywatnej sieci i nie jest wystawiony do internetu. Dlatego pustego Available From nie należy traktować jako dowodu publicznej dostępności SSH.
Przy audycie trzeba sprawdzić cały tor dostępu: czy router ma publiczny adres lub przekierowanie z publicznej sieci, jakie reguły obowiązują w łańcuchu input, z jakich interfejsów przyjmowany jest ruch i czy po drodze nie znajduje się inne urządzenie wykonujące NAT lub filtrowanie.
MikroTik zaleca, aby SSH nie było dostępne z niezaufanych sieci. Jeżeli potrzebne jest zdalne zarządzanie, lepszym rozwiązaniem jest ograniczenie dostępu do zaufanych adresów albo dostęp przez VPN, na przykład WireGuard, bez publicznego wystawiania portów administracyjnych.
MikroTrick to nie wszystkie problemy poprawione we wrześniu
CERT Polska opisał łącznie sześć podatności. Poza dwoma błędami tworzącymi MikroTrick znalazły się wśród nich również problemy dotyczące serwera bandwidth-test, obsługi certyfikatów X.509, stanu protokołu SSH oraz WebFig.
CVE-2026-67276 - obejście uwierzytelnienia SSH, CVSS 9.2
RouterOS nie porównywał kompletnego klucza publicznego RSA podczas dopasowywania go do klucza przypisanego użytkownikowi. W określonych warunkach umożliwiało to zalogowanie się bez właściwego klucza prywatnego.
CVE-2026-86060 - manipulacja uprawnieniami sesji SSH, CVSS 9.2
Błąd w obsłudze nazwy użytkownika mógł doprowadzić do zmiany maski uprawnień sesji i uzyskania pełnych praw administracyjnych.
CVE-2026-67277 - wyciek pamięci i restart przez bandwidth-test, CVSS 8.8
Nieuwierzytelnione połączenie mogło wejść w stan, który powinien być dostępny dopiero po zalogowaniu. W połączeniu z dodatkowymi błędami pozwalało to ujawnić fragmenty pamięci jądra albo doprowadzić do restartu systemu.
CVE-2026-67278 - nieprawidłowa walidacja podpisów X.509
Błąd dotyczył weryfikacji podpisów RSA/PKCS#1 v1.5. W określonych warunkach napastnik mający możliwość kontrolowania lub przekierowania wychodzącego połączenia TLS routera mógł podszyć się pod zaufany serwer.
CVE-2026-67279 - przejście SSH do kolejnego stanu bez uwierzytelnienia
RouterOS mógł wejść w etap protokołu SSH przeznaczony dla uwierzytelnionej sesji mimo braku wcześniejszego logowania. Na podatnych wersjach umożliwiało to operacje na plikach zarządzanych przez RouterOS.
CVE-2026-67281 - nieuwierzytelniony odczyt plików przez WebFig
Podatność w ścieżce obsługiwanej przez WebFig mogła umożliwić odczyt plików bez uwierzytelnienia, w tym danych należących do roota i informacji konfiguracyjnych.
To właśnie dlatego wyłączenie publicznego SSH jest bardzo ważne, ale nie zastępuje aktualizacji. Wrześniowe wydania poprawiają szerszy zestaw błędów niż sam MikroTrick.
Aktualizacja to pierwszy krok, nie ostatni
Na testowym urządzeniu po instalacji poprawki RouterOS wskazuje już wersję 7.24.2 jako zainstalowaną i aktualną.
Jeżeli router wcześniej miał usługi administracyjne dostępne z publicznych sieci, samo przejście na poprawioną wersję nie odpowiada na pytanie, czy urządzenie nie zostało przejęte przed aktualizacją.
Dlatego po instalacji poprawki CERT Polska zaleca sprawdzenie logów oraz konfiguracji pod kątem nieznanych użytkowników, skryptów, zadań schedulera, serwerów proxy, tuneli i innych zmian, których administrator nie rozpoznaje.
Sprawdź flagged, ale nie traktuj go jak certyfikatu bezpieczeństwa
Po aktualizacji warto wykonać:
/system/device-mode/print
flagging-enabled: yes oraz flagged: no.RouterOS może podczas uruchamiania analizować konfigurację w poszukiwaniu znanych oznak nieautoryzowanych zmian. Jeżeli wykryje podejrzaną konfigurację, może ją dezaktywować, zapisać krytyczny komunikat w logu i ustawić urządzenie w stanie flagged.
Brak flagi nie jest dowodem bezpieczeństwa. Mechanizm wykrywa wybrane, znane ślady. CERT Polska podkreśla, że flagged: no nie wyklucza wcześniejszej nieautoryzowanej aktywności.
Jeżeli urządzenie zostanie oznaczone jako flagged, nie powinno się od razu kasować tego stanu. Najpierw trzeba przeanalizować konfigurację, zabezpieczyć potrzebne dane i potraktować router jako potencjalnie skompromitowany.
Sprawdź użytkowników
Jednym z pierwszych miejsc do kontroli jest System > Users.
CERT Polska podał konkretny wskaźnik kompromitacji związany z obserwowanymi atakami: wysoko uprzywilejowane konto o nazwie ops.
W logach obserwowano również zdarzenia związane z użytkownikiem -2, między innymi nieudane logowanie SSH oraz utworzenie nowego użytkownika przez sesję opisaną jako ssh:-2@<ip>.
CERT powiązał obserwowane skuteczne ataki, w tym tworzenie konta ops, z adresem IP 82.192.72.4. Adres 103.102.31.18 pojawiał się przy próbach wykorzystania opisywanego łańcucha. Aktywność była obserwowana co najmniej od 2 września 2026 roku.
Obecność któregoś z tych śladów wymaga dalszego sprawdzenia. Ich brak nadal nie wyklucza wcześniejszej kompromitacji.
Skrypty i Scheduler też trzeba przejrzeć
Pełne uprawnienia administracyjne dają możliwość pozostawienia na urządzeniu zmian, które przeżyją zakończenie pierwotnego ataku. Dlatego kontrola nie powinna kończyć się na liście użytkowników.
Warto sprawdzić System > Scripts:
oraz System > Scheduler:
Do tego dochodzą konfiguracje proxy, SOCKS, tunele VPN, reguły firewalla, pliki oraz inne elementy, które mogły zostać zmienione przez osobę z pełnymi uprawnieniami.
Praktyczne pytanie po aktualizacji brzmi więc nie tylko: „czy mam już poprawioną wersję RouterOS?”, ale również: „czy ufam konfiguracji, która znajduje się obecnie na tym urządzeniu?”
Co zrobić, jeśli są ślady przejęcia?
Jeżeli flagged, logi, nieznany użytkownik albo zmiany w konfiguracji wskazują na możliwość kompromitacji, CERT Polska zaleca odizolowanie urządzenia od sieci i potraktowanie go jako przejętego.
Przed resetem należy zabezpieczyć logi oraz konfigurację. Dopiero po zebraniu materiału urządzenie powinno zostać przywrócone do ustawień fabrycznych i skonfigurowane ponownie na podstawie zaufanej, zweryfikowanej konfiguracji.
Trzeba również zmienić używane hasła, klucze oraz inne sekrety.
Nie przywracaj bezrefleksyjnie pełnego backupu z potencjalnie skompromitowanego urządzenia. Jeżeli napastnik pozostawił w konfiguracji dodatkowego użytkownika, skrypt, scheduler, tunel albo inną furtkę, można w ten sposób odtworzyć problem razem z backupem.
Nie możesz zaktualizować od razu?
To powinien być tylko stan przejściowy. Do czasu instalacji poprawki CERT Polska zaleca ograniczenie dostępu z niezaufanych sieci do wystawionych usług, w szczególności:
- SSH.
- WWW i WWW-SSL.
- Bandwidth-test.
Na niezałatanym urządzeniu należy też unikać inicjowania połączeń TLS przez niezaufane sieci oraz używania wbudowanych klientów /system ssh i /system ssh-exec do niezaufanych hostów.
Te działania zmniejszają powierzchnię ataku, ale nie zastępują instalacji poprawionej wersji RouterOS.
Najważniejsza rzecz po tej aktualizacji
MikroTrick jest konkretnym błędem i został poprawiony. Znacznie bardziej uniwersalna lekcja dotyczy jednak sposobu zarządzania routerem.
SSH, WinBox czy WebFig nie powinny być publicznie dostępne tylko dlatego, że tak jest wygodniej. Jeśli administrator potrzebuje zdalnego dostępu, bezpieczniejszym modelem jest wejście przez VPN do zaufanej sieci administracyjnej i dopiero wtedy dostęp do usług zarządzania.
Dzisiaj problem dotyczy konkretnego łańcucha błędów w RouterOS. Kolejna podatność może znajdować się w zupełnie innym miejscu. Ograniczenie powierzchni administracyjnej działa również przeciwko błędom, których jeszcze nie znamy.
Po aktualizacji RouterOS dobrze więc sprawdzić nie tylko numer wersji. Sprawdź również, które usługi routera są rzeczywiście osiągalne z internetu i czy każda z nich musi tam być.
Źródła
- MikroTik - September 2026 vulnerability
- CERT Polska - Critical vulnerabilities in MikroTik RouterOS are being actively exploited
- CERT Polska - Vulnerabilities in MikroTik RouterOS software
- MikroTik RouterOS Manual - Device mode i status Flagged
Stan informacji i zaleceń zweryfikowany 7 września 2026 roku.
Czy po aktualizacji RouterOS sprawdzacie tylko numer wersji, czy również użytkowników, skrypty, scheduler, logi i faktyczną dostępność usług administracyjnych?
