Wstęp

3 września 2026 r. MikroTik opublikował niemal równocześnie poprawki dla kilku utrzymywanych gałęzi RouterOS: 7.25beta3, 7.24.2, 7.23.4 oraz 6.49.21. Producent określił wydanie jako ważną aktualizację bezpieczeństwa, ale tymczasowo nie ujawnił szczegółów podatności, aby dać administratorom czas na aktualizację urządzeń. Zalecił jednak możliwie szybką instalację poprawionej wersji.

Część poprawek dotyczyła podatności odnalezionych przez Sławomira Rozbickiego z zespołu CERT Polska, zgłoszonych producentowi w ramach skoordynowanego ujawniania podatności (ang. coordinated vulnerability disclosure, CVD). Ich publikację planowaliśmy zsynchronizować z wydaniem aktualizacji, jednak nowe wersje ukazały się wcześniej, niż oczekiwaliśmy. Producent zdecydował się ponadto na wykorzystanie powiadomień push w aplikacji MikroTik, aby podkreślić konieczność podniesienia wersji.

Pilny charakter komunikatu i brak konkretnych informacji o zagrożeniach wywołały falę spekulacji na oficjalnym forum MikroTika. Jednocześnie użytkownicy publikowali w komentarzach logi ze swoich urządzeń, które wskazywały, że ataki mogły rozpocząć się jeszcze przed udostępnieniem poprawek.

Identyfikacja CVE-2026-86060

Wraz z udostępnieniem nowych wersji RouterOS rozpoczęliśmy analizę różnicową, aby sprawdzić, czy nowe wersje usuwały zgłoszone przez nas podatności. W pakietach znaleźliśmy również zmiany w mechanizmach, których nie dotyczyły nasze zgłoszenia.

Poprawione wersje RouterOS sprawdzały nazwę użytkownika przed przekazaniem jej do aplikacji /nova/bin/login. Zakres wprowadzonej walidacji wskazywał, że przed poprawką nazwa użytkownika mogła wpływać na sposób interpretowania argumentów tego programu. Wynik dekompilacji wyglądał następująco:

Zidentyfikowaliśmy dodatkowo zmiany w mechanizmie Flagged, służącym do detekcji wpisów konfiguracyjnych mogących świadczyć o kompromitacji. Dodano regułę, która podczas uruchamiania wykrywała konto ops należące do uprzywilejowanej grupy full. Po spełnieniu tego warunku RouterOS wyłączał konto, rejestrował ostrzeżenie i ustawiał status Flagged. Wprowadzenie tak specyficznych wskaźników kompromitacji (ang. Indicators of Compromise, IoC) mogło oznaczać, że producent miał przynajmniej częściową wiedzę o szczegółach ataków.

Następnie zbadaliśmy logi publikowane przez administratorów na forum MikroTika i Reddicie. W wielu raportach występowały dwa charakterystyczne wpisy:

login failure for user -2 from 82.192.72.4 via ssh
user ops added by ssh:[email protected]

Zwróciliśmy uwagę na sprzeczną sekwencję zdarzeń w logach - nieudaną próbę logowania użytkownika -2, a następnie utworzenie konta ops (w ramach tej samej sesji).

Zestawienie tych informacji z wynikami analizy różnicowej pozwoliło nam w ciągu godziny zidentyfikować nową podatność krytyczną, nadać jej identyfikator CVE-2026-86060 i przekazać szczegóły (wraz z działającym skryptem PoC) producentowi.

W połączeniu z CVE-2026-67279 podatność ta pozwalała uzyskać pełne uprawnienia administracyjne bez znajomości hasła, posiadania klucza SSH ani ukończenia uwierzytelniania. Łańcuch ten nazwaliśmy MikroTrick.

CVE-2026-67279

SSH udostępnia wiele funkcji administracyjnych, takich jak zdalny terminal, wykonywanie poleceń, przesyłanie plików czy tunelowanie połączeń wewnątrz szyfrowanego kanału komunikacji. Protokół składa się z trzech następujących po sobie warstw:

1. transportowej,
2. uwierzytelniania użytkownika,
3. obsługi połączeń i kanałów.

Po nawiązaniu połączenia TCP klient i serwer negocjują algorytmy kryptograficzne, a następnie przeprowadzają wymianę kluczy, w ramach której uzgadniają wspólny sekret. Serwer podpisuje parametry tej wymiany swoim kluczem hosta, co pozwala klientowi zweryfikować jego tożsamość. Przy pierwszym połączeniu często stosowana jest zasada „zaufania przy pierwszym użyciu” (ang. Trust on First Use, TOFU). Następnie strony wyprowadzają ze wspólnego sekretu materiał kluczowy dla dalszej komunikacji. Od tego momentu jest ona szyfrowana i chroniona przed modyfikacją. Ten etap uwierzytelnia serwer wobec klienta, ale jeszcze nie użytkownika wobec serwera.

Następnie klient przeprowadza uwierzytelnienie użytkownika za pomocą jednej z dozwolonych metod, np. hasła lub klucza publicznego. Jeżeli proces ten zakończy się pomyślnie, serwer wysyła komunikat SSH_MSG_USERAUTH_SUCCESS. Dopiero wtedy rozpoczyna się faza obsługi kanałów, w której klient może uzyskać dostęp do powłoki, wykonać polecenie lub skorzystać z innych funkcji administracyjnych zgodnie z uprawnieniami przypisanymi użytkownikowi SSH. Podział ten opisują dokumenty RFC 4253, RFC 4252 i RFC 4254.

Po początkowej wymianie kluczy każda ze stron może zainicjować ich ponowne uzgodnienie, czyli rekey. Pozwala to zmienić klucze transportowe bez zrywania połączenia TCP i bez zmiany stanu protokołów wyższych warstw. Zwykle następuje to dopiero po przesłaniu ustalonej ilości danych albo po upływie określonego czasu, ale protokół dopuszcza wykonanie rekey również przed zakończeniem uwierzytelniania użytkownika.

Podatne wersje serwera SSH w RouterOS nieprawidłowo obsługiwały rekey zainicjowany podczas uwierzytelniania użytkownika. Po jego zakończeniu serwer bezwarunkowo przechodził z tymczasowego stanu rekey do fazy obsługi kanałów, zamiast kontynuować przerwane uwierzytelnienie. W efekcie akceptował otwarcie kanału sesji i związane z nim żądania, pomimo braku komunikatu SSH_MSG_USERAUTH_SUCCESS.

Podatność nie tworzyła uwierzytelnionej tożsamości ani nie przypisywała jej uprawnień. Pozwalała jednak przejść z fazy uwierzytelniania do obsługi kanałów, co było warunkiem wykorzystania CVE-2026-86060.

CVE-2026-86060

Po prawidłowym uwierzytelnieniu klient może otworzyć kanał session (wykorzystanie CVE-2026-67279 likwiduje ten wymóg). Następnie, aby utworzyć zdalną konsolę, klient zazwyczaj wysyła kolejno żądania pty-req i shell. Serwer tworzy wtedy pseudoterminal i uruchamia podłączony do niego proces potomny. W RouterOS jest nim /nova/bin/login, uruchomiony według poniższego schematu:

/nova/bin/login -ssh -trace <trace> -h <adres klienta> [-c <polecenie>] <nazwa użytkownika> <maska uprawnień>

W typowym przebiegu dwa ostatnie argumenty pozycyjne zawierają nazwę uwierzytelnionego użytkownika i jego efektywną maskę uprawnień (policy mask), przekazywaną w postaci liczby dziesiętnej. Program login nie powtarza wówczas weryfikacji hasła lub klucza, lecz ufa decyzji procesu nadrzędnego i na tej podstawie tworzy konsolę.

Nazwa użytkownika jest przesyłana w komunikacie SSH_MSG_USERAUTH_REQUEST przed zakończeniem uwierzytelniania i zapisywana przez proces sshd. Następnie sshd przekazuje ją bez walidacji jako jeden z elementów tablicy argv programu login. Wartość rozpoczynająca się od znaku - jest interpretowana jako opcja programu, a nie nazwa użytkownika.

Aplikacja login interpretuje specjalną składnię -N, w której liczba naturalna N oznacza numer deskryptora. Po napotkaniu takiego argumentu proces odczytuje z wybranego deskryptora rekord zawierający dwa pola rozdzielone bajtem zerowym (ang. NUL). Pierwsze pole jest interpretowane jako nazwa użytkownika, a drugie jako maska efektywnych uprawnień (gdy występuje argument -ssh). Po zakończeniu odczytu parser zamyka wskazany deskryptor i kontynuuje analizę pozostałych argumentów wywołania.

Użycie nazwy użytkownika -2 nakłania więc proces login do odczytania tych wartości z deskryptora numer 2, który wskazuje na ustanowiony wcześniej pseudoterminal (pty). Deskryptory 0, 1 i 2 procesu login korzystają ze wspólnej kolejki wejściowej powiązanej z tym właśnie pseudoterminalem. W ten sposób atakujący nadpisuje efektywną maskę uprawnień wartością przesłaną przy użyciu kanału SSH.

MikroTrick

Połączenie obu podatności skutkowało pełnym dostępem do konsoli administracyjnej bez uwierzytelnienia. CVE-2026-67279 pozwalała utworzyć kanał session bez uwierzytelnienia, a CVE-2026-86060 umożliwiała przekazanie procesowi login kontrolowanej maski uprawnień.

Wykorzystanie obu podatności zgodnie z tym schematem pozostawia w logach wpis o nieudanej próbie logowania użytkownika -2, co odpowiada przytoczonym wcześniej publicznym wpisom. Na tej podstawie uważamy, że MikroTrick był wykorzystywany przed publikacją aktualizacji.

Niektóre publikacje błędnie łączyły CVE-2026-67276 z łańcuchem MikroTrick. Jest to odrębna podatność pozwalająca podszyć się pod użytkownika korzystającego z klucza RSA. Jej wykorzystanie wymaga znajomości nazwy konta i modułu przypisanego do niego klucza publicznego, a udany atak daje dostęp wyłącznie do tego konta. Wariant ten jest więc znacznie trudniejszy do wykorzystania w masowym ataku niezależnym od konfiguracji urządzenia.

Agent LLM w laboratorium badawczym

Badania RouterOS prowadziliśmy z wykorzystaniem modeli o obniżonym progu odmów GPT-5.5-cyber i GPT-5.6-sol w ramach dostępu do programu OpenAI GTAC. Dodatkowo CERT Polska dysponuje własną infrastrukturą, na której lokalnie uruchamiamy duże modele o otwartych wagach, w tym GLM, DeepSeek, Qwen oraz polski model PLLuM. Skuteczność badań nad RouterOS zależała od przygotowania izolowanego laboratorium, w którym agent mógł samodzielnie sterować maszynami wirtualnymi, oraz właściwego określenia zakresu eksperymentów.

Za pośrednictwem libvirt agent przygotowywał maszyny wirtualne, tworzył i przywracał snapshoty, uruchamiał testy oraz zbierał artefakty. Pod koniec badań laboratorium zawierało 40 maszyn CHR, 39 snapshotów i 24 wydania RouterOS, od 6.43.11 do 7.25beta3. Przed każdym eksperymentem testowane urządzenie było doprowadzane do konfiguracji i stanu odpowiadających badanej hipotezie. Narzędzia wykonujące te czynności wytworzył i obsługiwał LLM, zastępując pracę wykonywaną wcześniej ręcznie.

Agent prowadził statyczną analizę plików binarnych wyodrębnionych z systemu plików RouterOS CHR x86 za pomocą radare2 i Ghidry. Wyniki zestawiał z dokumentacją analizowanych protokołów, w szczególności z dokumentami RFC. Porównanie kolejnych wydań pozwalało ustalić, w której wersji błąd został wprowadzony i w której go usunięto.

Modele szczególnie dobrze sprawdziły się w analizie protokołów jako maszyn stanów. Systematycznie testowały powtarzanie etapów, pomijanie komunikatów, zmianę ich kolejności oraz przedwczesne otwieranie zależnych kanałów. Jeden z takich testów obejmował rekey przed zakończeniem uwierzytelniania SSH i doprowadził do wykrycia nieprawidłowego przejścia stanu.

Po publikacji poprawek agenci LLM monitorowali forum MikroTika, Reddit i inne publiczne źródła, pomagając nam śledzić doniesienia o wykorzystaniu podatności oraz próby odtworzenia exploita.

Najwięcej czasu wymagały przygotowanie kontekstu (precyzyjnych informacji dla agenta) i laboratorium, rozstrzyganie niejednoznacznych wyników oraz walidacja na rzeczywistych wersjach RouterOS. Każdą podatność uznawaliśmy za potwierdzoną dopiero po uzyskaniu powtarzalnych wyników, wykonaniu testów negatywnych, analizie artefaktów i porównaniu kilku wersji systemu.

Ataki w internecie

Najwcześniejsze publicznie dostępne logi ataków pochodziły z 2 września, sprzed udostępnienia poprawek. W połączeniu ze zgłoszeniami otrzymanymi przez CERT Polska pozwoliły odtworzyć sposób działania obserwowanego aktora.

Publiczne raporty zawierały powtarzalny zestaw wskaźników: połączenia z adresu 82.192.72.4, próbę uwierzytelnienia jako -2 oraz utworzenie konta ops z pełnymi uprawnieniami. Raport diagnostyczny opublikowany na forum MikroTika dokumentował odrzucenie uwierzytelnienia, rekey, otwarcie kanału i przekazanie polecenia przez exec. Na tym urządzeniu atak zakończył się awarią procesu SSH. Inna relacja potwierdzała skuteczne utworzenie konta administracyjnego na urządzeniach korzystających wyłącznie z kluczy SSH i trybu strong-crypto, a kolejny administrator odnalazł takie konto na wielu zarządzanych urządzeniach.

Logi opublikowane na forum trzepak.pl dokumentowały utworzenie pliku diagnostycznego RIF i wysłanie danych na adres 82.192.72.4 za pomocą polecenia fetch. Analogiczną sekwencję opublikowano na Reddicie. W obu przypadkach transfer następował krótko po utworzeniu pliku, co z wysokim prawdopodobieństwem wskazuje na eksfiltrację plików diagnostycznych.

Analiza poprawek

Po publikacji poprawek 3 września administratorzy rozpoczęli aktualizację urządzeń, a niezależni badacze analizę nowych pakietów. Kluczowe elementy podatności zostały publicznie odtworzone w ciągu kilkudziesięciu godzin.

Administratorzy wskazywali na forum MikroTika, że aktualizacja części urządzeń wymaga fizycznego dostępu lub okna serwisowego. Zgłoszenia regresji oznaczały ponadto konieczność przetestowania nowej wersji i przygotowania planu wycofania przed jej szerszym wdrożeniem.

Pakiety NPK umożliwiały bezpośrednie porównanie plików podatnych i poprawionych wersji. Publiczny artykuł analizujący te różnice ukazał się 4 września o 03:22 UTC (npratley.net). Autor opisał swoją pracę jako wspartą przez AI i zweryfikowaną w laboratorium. Pierwsza wersja analizy nie odtwarzała pełnego łańcucha MikroTrick, ale identyfikowała główne zmiany implementacji serwera SSH i naprowadzała czytelników na potencjalne obszary dalszych badań.

Do 5 września publicznie powiązano nazwę -2 z deskryptorem programu login, a niezależni badacze informowali o odtworzeniu nieuwierzytelnionego dostępu przez SSH, nie publikując pełnej procedury wykorzystania (Reddit, forum MikroTika, dalsza analiza). Dostępne materiały zawierały już większość informacji potrzebnych do rekonstrukcji ataku.

Publikację rekordów CVE rozpoczęliśmy 5 września o 20:00:55 UTC (CVE-2026-67276, CVE-2026-86060). Na tym etapie utrzymywanie szczegółów wyłącznie w kanałach CVD nie stanowiło już istotnej przeszkody dla osób rekonstruujących exploit, ograniczało natomiast informacje dostępne administratorom.

10 września dwa odnalezione przez nas błędy, CVE-2026-67277 i CVE-2026-86060, trafiły do prowadzonego przez CISA katalogu aktywnie wykorzystywanych podatności (ang. Known Exploited Vulnerabilities, KEV). Termin remediacji wyznaczono na trzy dni.

Wnioski

Szybkość analizy poprawek przy wykorzystaniu LLM zaciera różnicę między wydaniem aktualizacji a publikacją technicznych szczegółów podatności. W przypadku MikroTrick kluczowe elementy błędów zidentyfikowano publicznie w ciągu kilkudziesięciu godzin. Obniżenie kosztu analizy kodu nie skróciło jednak czasu potrzebnego na przetestowanie i wdrożenie aktualizacji ani na sprawdzenie ewentualnych śladów kompromitacji.

Ta asymetria nie uzasadnia opóźniania publikacji poprawek, ale należy zakładać, że analiza wprowadzonych zmian rozpocznie się bezpośrednio po ich udostępnieniu, również z wykorzystaniem AI. W tych warunkach rośnie odpowiedzialność producentów, którzy powinni dołączać do aktualizacji rzetelne informacje o powierzchni ataku, możliwych środkach ograniczających ryzyko, wskaźnikach kompromitacji i regułach detekcji, aby użytkownicy mogli szybciej podjąć działania obronne.