Trzeciego września 2026 roku producent MikroTik opublikował poprawki bezpieczeństwa dla kilku gałęzi swojego systemu operacyjnego RouterOS 1. Komunikat był lakoniczny: ważna aktualizacja, bez technicznych szczegółów, aby dać administratorom czas na działanie 2. Za kulisami rozgrywał się wyścig z czasem. Część zidentyfikowanych podatności zgłosił producentowi badacz z zespołu CERT Polska 3. Jednocześnie w sieci pojawiały się już doniesienia użytkowników, których logi wskazywały na aktywne ataki, trwające jeszcze przed udostępnieniem łatek 4.

Zestawiliśmy publiczne dane z raportu technicznego CERT Polska, aby zrekonstruować łańcuch ataku nazwany MikroTrick 5. Analiza pokazuje, jak połączenie dwóch podatności pozwalało na całkowite ominięcie mechanizmów uwierzytelniania i uzyskanie pełnej kontroli administracyjnej nad popularnymi na całym świecie, w tym w Polsce, routerami. To studium przypadku ataku typu 0-day, gdzie napastnicy wykorzystali lukę, zanim producent zdążył ją załatać.

Najważniejsze liczby

  • 2 podatności: Łańcuch MikroTrick składał się z dwóch luk: CVE-2026-67279 oraz CVE-2026-86060 6.
  • 0 uwierzytelnienia: Połączenie obu luk pozwalało na uzyskanie pełnych uprawnień administracyjnych bez znajomości hasła czy klucza SSH 6.
  • 4 gałęzie RouterOS: Poprawki zostały wydane jednocześnie dla wersji 7.25beta3, 7.24.2, 7.23.4 oraz 6.49.21 1.
  • 1 godzina: Tyle czasu zajęło analitykom CERT Polska zidentyfikowanie drugiej, krytycznej podatności po analizie publicznych logów i różnic w kodzie 7.
  • 1 wskaźnik kompromitacji (IoC): Wbudowana w poprawkę reguła wykrywająca konto użytkownika o nazwie ops w grupie full była kluczową wskazówką o naturze ataków 8 9.

Metodologia raportu

Niniejszy raport to analiza oparta w całości na publicznym opracowaniu technicznym „MikroTrick – analiza techniczna łańcucha podatności w oprogramowaniu MikroTik RouterOS” opublikowanym przez CERT Polska. Nie zawiera danych z wewnętrznej telemetrii ani informacji niejawnych. Celem jest dekonstrukcja łańcucha ataku i przedstawienie jego implikacji dla administratorów i firm w Polsce. Wszystkie fakty są opatrzone odnośnikami do materiału źródłowego.

Cichy patch i pierwsze ślady

Reakcja producenta na wykryte podatności była dwutorowa. Z jednej strony, opublikowano aktualizacje dla wspieranych wersji RouterOS, określając je jako krytyczne 1 2. Z drugiej, aby zwiększyć zasięg komunikatu, wykorzystano powiadomienia push w aplikacji mobilnej MikroTik, co jest działaniem niestandardowym i podkreślającym powagę sytuacji 10. Producent celowo wstrzymał się z publikacją szczegółów technicznych, stosując praktykę skoordynowanego ujawniania podatności (ang. Coordinated Vulnerability Disclosure, CVD), w ramach której współpracował m.in. z CERT Polska 3.

Jednak niemal natychmiast po ogłoszeniu na forach internetowych, w tym na oficjalnym forum MikroTika oraz na platformie Reddit, administratorzy zaczęli publikować fragmenty logów swoich urządzeń 11. Wskazywały one na próby włamań, które miały miejsce jeszcze przed 3 września, czyli przed dniem wydania poprawek 4. To klasyczny scenariusz ataku 0-day, w którym atakujący dysponują wiedzą o luce przed jej publicznym ujawnieniem i załataniem.

Analiza samych poprawek dostarczyła kolejnych poszlak. Producent dodał do mechanizmu Flagged — służącego do wykrywania śladów kompromitacji — specyficzną regułę 8. Sprawdzała ona podczas startu systemu, czy istnieje konto użytkownika o nazwie ops z pełnymi uprawnieniami (grupa full) 8. Jeśli tak, konto było automatycznie wyłączane, a w logach pojawiało się ostrzeżenie 12. Wprowadzenie tak konkretnego wskaźnika kompromitacji (IoC, ang. Indicators of Compromise) silnie sugerowało, że producent posiadał przynajmniej częściową wiedzę o metodach stosowanych przez atakujących 9.

Rekonstrukcja ataku: od logów do exploita

Kluczem do zrozumienia ataku okazało się zestawienie publicznie dostępnych logów z analizą zmian w kodzie RouterOS. W wielu raportach administratorów powtarzała się charakterystyczna sekwencja zdarzeń: najpierw w logach pojawiała się nieudana próba logowania dla nieistniejącego użytkownika o nazwie -2, a zaraz po niej, w ramach tej samej sesji, tworzone było konto ops 11.

Ta sprzeczność — nieudane logowanie, po którym następuje udana akcja administracyjna — była punktem zaczepienia dla analityków. Analiza różnicowa kodu (porównanie wersji przed i po poprawce) wykazała, że załatana wersja RouterOS wprowadziła dodatkową walidację nazwy użytkownika przekazywanej do aplikacji /nova/bin/login 13. Przed poprawką zmanipulowana nazwa użytkownika mogła wpływać na sposób, w jaki program interpretował swoje argumenty startowe 14.

Połączenie tych faktów pozwoliło zespołowi CERT Polska w ciągu zaledwie godziny zidentyfikować drugą, nieznaną wcześniej podatność krytyczną 7. Otrzymała ona identyfikator CVE (Common Vulnerabilities and Exposures, standard nazewnictwa publicznie znanych luk) CVE-2026-86060 i została natychmiast zgłoszona producentowi wraz z działającym kodem dowodzącym istnienia luki (PoC, ang. Proof of Concept) 7. W połączeniu z wcześniej zgłoszoną podatnością CVE-2026-67279, tworzyła ona kompletny łańcuch ataku, nazwany MikroTrick 6 5.

Anatomia MikroTrick: Jak obejść uwierzytelnianie SSH

Aby zrozumieć, jak działał atak, musimy przyjrzeć się budowie protokołu SSH (Secure Shell). Zgodnie z dokumentami RFC 4252, 4253 i 4254, protokół ten składa się z trzech warstw 15 16:

  1. Warstwa transportowa: Po nawiązaniu połączenia sieciowego (TCP, ang. Transmission Control Protocol), klient i serwer negocjują algorytmy kryptograficzne i wymieniają klucze, aby ustanowić bezpieczny, szyfrowany kanał komunikacji 17. Na tym etapie serwer uwierzytelnia się przed klientem, używając swojego klucza hosta, ale użytkownik nie jest jeszcze zweryfikowany 18 19.
  2. Warstwa uwierzytelniania użytkownika: Klient próbuje udowodnić swoją tożsamość, używając np. hasła lub klucza kryptograficznego 20. Jeśli próba się powiedzie, serwer wysyła komunikat SSH_MSG_USERAUTH_SUCCESS 21.
  3. Warstwa połączeń: Dopiero po pomyślnym uwierzytelnieniu użytkownika klient może zażądać otwarcia kanału, np. w celu uzyskania dostępu do powłoki systemowej lub wykonania polecenia 22.

Podatność tkwiła w obsłudze mechanizmu rekey (ponownego uzgodnienia kluczy). Protokół SSH pozwala na zmianę kluczy szyfrujących w trakcie trwania sesji, bez zrywania połączenia i bez wpływu na stan wyższych warstw 23. Rekey może zostać zainicjowany również w trakcie fazy uwierzytelniania użytkownika, zanim zostanie ona zakończona 24.

Podatne wersje serwera SSH w RouterOS nieprawidłowo obsługiwały ten scenariusz 25. Gdy klient inicjował rekey w trakcie próby uwierzytelnienia, serwer po zakończeniu ponownego uzgadniania kluczy błędnie zakładał, że proces logowania zakończył się sukcesem. Zamiast wrócić do przerwanego procesu weryfikacji użytkownika, bezwarunkowo przechodził do fazy obsługi kanałów 26. W efekcie atakujący, który nigdy nie podał prawidłowego hasła ani klucza, uzyskiwał dostęp do systemu tak, jakby był w pełni uwierzytelnionym administratorem.

Implikacje dla polskiego biznesu

Urządzenia MikroTik są wszechobecne w polskiej infrastrukturze sieciowej. Korzystają z nich mali i średni dostawcy internetu (ISP), firmy z sektora MŚP, instytucje publiczne, a także użytkownicy domowi. Ich popularność wynika z dobrego stosunku ceny do możliwości. Podatność umożliwiająca zdalne przejęcie kontroli bez uwierzytelnienia stanowi zatem krytyczne zagrożenie dla stabilności i bezpieczeństwa ogromnej części polskiego internetu.

Przejęty router staje się dla atakującego bramą do sieci wewnętrznej. Może służyć do podsłuchiwania ruchu, kradzieży danych, przeprowadzania dalszych ataków na inne systemy w sieci (ruch lateralny) lub do włączenia urządzenia do botnetu w celu prowadzenia ataków DDoS (rozproszony atak odmowy usługi). W kontekście MŚP, gdzie często brakuje dedykowanych zespołów bezpieczeństwa, niezałatany router brzegowy wystawiony na działanie internetu jest otwartymi drzwiami do całej firmowej infrastruktury. Ataki 0-day na infrastrukturę sieciową pokazują, że samo posiadanie procedur aktualizacji może nie wystarczyć. Kluczowa staje się szybkość reakcji oraz zdolność do proaktywnego monitorowania i wykrywania anomalii, które mogą świadczyć o nieznanym wcześniej wektorze ataku.

Rekomendacje

Dla administratorów IT i zespołów SOC

  1. Natychmiastowa aktualizacja: Sprawdź wersje wszystkich urządzeń MikroTik w infrastrukturze i zaktualizuj je do jednej z załatanych wersji: 7.25beta3, 7.24.2, 7.23.4, 6.49.21 lub nowszej 1.
  2. Audyt kont użytkowników: Sprawdź listę użytkowników na wszystkich routerach pod kątem obecności podejrzanych kont, w szczególności konta ops z pełnymi uprawnieniami 8.
  3. Analiza logów: Przeszukaj logi systemowe pod kątem charakterystycznej sekwencji zdarzeń: nieudanej próby logowania użytkownika -2, po której następuje utworzenie nowego konta lub inna akcja administracyjna 11.
  4. Ograniczenie dostępu: Jeśli to możliwe, zablokuj dostęp do interfejsów zarządzania (WinBox, SSH, WebFig) od strony publicznego internetu. Dostęp powinien być realizowany wyłącznie z zaufanych sieci lub poprzez VPN (Virtual Private Network).

Dla CISO i menedżerów

  1. Weryfikacja inwentarza zasobów: Upewnij się, że posiadasz kompletną i aktualną listę wszystkich urządzeń sieciowych, w tym routerów MikroTik, wraz z ich wersjami oprogramowania i statusem ekspozycji na internet.
  2. Przegląd polityki aktualizacji: Oceń, czy obecne procedury zarządzania podatnościami pozwalają na szybką reakcję w przypadku krytycznych luk w infrastrukturze brzegowej. Atak 0-day pokazuje, że okno na działanie może być zerowe.
  3. Zwiększenie monitoringu: Rozważ wdrożenie centralnego zbierania logów z krytycznych urządzeń sieciowych. Może to umożliwić szybsze wykrywanie anomalii i korelowanie zdarzeń z różnych systemów.

Disclaimer

Niniejszy artykuł ma charakter informacyjny i analityczny. Przedstawione rekomendacje są ogólnymi wskazówkami i nie zastępują pełnego audytu bezpieczeństwa ani profesjonalnej konsultacji. Wszystkie działania na infrastrukturze produkcyjnej powinny być przeprowadzane z należytą ostrożnością.

Źródła

Zobacz też

Przypisy

  1. 3 września 2026 r. MikroTik opublikował poprawki dla kilku gałęzi RouterOS: 7.25beta3, 7.24.2, 7.23.4 oraz 6.49.21. — cert.pl › mikrotrick analiza techniczna ↩ ↩2 ↩3 ↩4

  2. Producent MikroTik określił wydanie poprawek jako ważną aktualizację bezpieczeństwa, ale tymczasowo nie ujawnił szczegółów podatności. — cert.pl › mikrotrick analiza techniczna ↩ ↩2

  3. Część poprawek dotyczyła podatności odnalezionych przez Sławomira Rozbickiego z zespołu CERT Polska. — cert.pl › mikrotrick analiza techniczna ↩ ↩2

  4. Użytkownicy publikowali logi ze swoich urządzeń, które wskazywały, że ataki mogły rozpocząć się jeszcze przed udostępnieniem poprawek. — cert.pl › mikrotrick analiza techniczna ↩ ↩2

  5. Łańcuch podatności CVE-2026-67279 i CVE-2026-86060 został nazwany MikroTrick. — cert.pl › mikrotrick analiza techniczna ↩ ↩2

  6. Połączenie CVE-2026-86060 z CVE-2026-67279 pozwalało uzyskać pełne uprawnienia administracyjne bez znajomości hasła, klucza SSH ani uwierzytelniania. — cert.pl › mikrotrick analiza techniczna ↩ ↩2 ↩3

  7. CERT Polska zidentyfikował nową podatność krytyczną, nadał jej identyfikator CVE-2026-86060 i przekazał szczegóły producentowi wraz z działającym skryptem PoC. — cert.pl › mikrotrick analiza techniczna ↩ ↩2 ↩3

  8. W mechanizmie Flagged, służącym do detekcji wpisów konfiguracyjnych świadczących o kompromitacji, dodano regułę wykrywającą konto ‘ops’ należące do grupy ‘full’. — cert.pl › mikrotrick analiza techniczna ↩ ↩2 ↩3 ↩4

  9. Wprowadzenie specyficznych wskaźników kompromitacji (IoC) mogło oznaczać, że producent miał częściową wiedzę o szczegółach ataków. — cert.pl › mikrotrick analiza techniczna ↩ ↩2

  10. Producent MikroTik zdecydował się na wykorzystanie powiadomień push w aplikacji MikroTik, aby podkreślić konieczność podniesienia wersji. — cert.pl › mikrotrick analiza techniczna ↩

  11. W logach publikowanych przez administratorów na forum MikroTika i Reddicie występowały wpisy o nieudanej próbie logowania użytkownika ‘-2’ i utworzeniu konta ‘ops’. — cert.pl › mikrotrick analiza techniczna ↩ ↩2 ↩3

  12. Po wykryciu konta ‘ops’ z grupy ‘full’, RouterOS wyłączał konto, rejestrował ostrzeżenie i ustawiał status Flagged. — cert.pl › mikrotrick analiza techniczna ↩

  13. Poprawione wersje RouterOS sprawdzały nazwę użytkownika przed przekazaniem jej do aplikacji /nova/bin/login. — cert.pl › mikrotrick analiza techniczna ↩

  14. Przed poprawką nazwa użytkownika mogła wpływać na sposób interpretowania argumentów programu /nova/bin/login. — cert.pl › mikrotrick analiza techniczna ↩

  15. Protokół SSH składa się z trzech warstw: transportowej, uwierzytelniania użytkownika oraz obsługi połączeń i kanałów. — cert.pl › mikrotrick analiza techniczna ↩

  16. Dokumenty RFC 4253, RFC 4252 i RFC 4254 opisują podział protokołu SSH. — cert.pl › mikrotrick analiza techniczna ↩

  17. Po nawiązaniu połączenia TCP, klient i serwer SSH negocjują algorytmy kryptograficzne i przeprowadzają wymianę kluczy. — cert.pl › mikrotrick analiza techniczna ↩

  18. Serwer SSH podpisuje parametry wymiany kluczy swoim kluczem hosta, co pozwala klientowi zweryfikować jego tożsamość. — cert.pl › mikrotrick analiza techniczna ↩

  19. Po wymianie kluczy, komunikacja SSH jest szyfrowana i chroniona przed modyfikacją, co uwierzytelnia serwer wobec klienta. — cert.pl › mikrotrick analiza techniczna ↩

  20. Klient SSH przeprowadza uwierzytelnienie użytkownika za pomocą hasła lub klucza publicznego. — cert.pl › mikrotrick analiza techniczna ↩

  21. Jeśli uwierzytelnienie użytkownika zakończy się pomyślnie, serwer wysyła komunikat SSH_MSG_USERAUTH_SUCCESS. — cert.pl › mikrotrick analiza techniczna ↩

  22. Dopiero po pomyślnym uwierzytelnieniu użytkownika rozpoczyna się faza obsługi kanałów SSH. — cert.pl › mikrotrick analiza techniczna ↩

  23. Rekey w SSH pozwala zmienić klucze transportowe bez zrywania połączenia TCP i bez zmiany stanu protokołów wyższych warstw. — cert.pl › mikrotrick analiza techniczna ↩

  24. Protokół SSH dopuszcza wykonanie rekey również przed zakończeniem uwierzytelniania użytkownika. — cert.pl › mikrotrick analiza techniczna ↩

  25. Podatne wersje serwera SSH w RouterOS nieprawidłowo obsługiwały rekey zainicjowany podczas uwierzytelniania użytkownika. — cert.pl › mikrotrick analiza techniczna ↩

  26. Po zakończeniu rekey, serwer SSH w RouterOS bezwarunkowo przechodził z tymczasowego stanu rekey do fazy obsługi kanałów, zamiast kontynuować przerwane uwierzytelnienie. — cert.pl › mikrotrick analiza techniczna ↩