MikroTik RouterOS „MikroTrick“: kritinės SSH spragos jau aktyviai išnaudojamos

Kas įvyko?

2026 m. rugsėjo 5 d. CERT Polska paskelbė apie šešis MikroTik RouterOS pažeidžiamumus ir patvirtino, kad dalis jų jau naudojama realiose atakose. CERT stebėti sėkmingi bandymai prieš viešai pasiekiamą SSH paslaugą fiksuoti mažiausiai nuo rugsėjo 2 d.

Didžiausia rizika kyla tiems RouterOS įrenginiams, kurių SSH valdymo paslauga yra pasiekiama iš viešo interneto. Dviejų SSH spragų kombinaciją CERT pavadino „MikroTrick“. Sėkmingas išnaudojimas gali baigtis pilna administratoriaus kontrole.

MikroTik savo rugsėjo 3 d. saugumo biuletenyje patvirtino svarbų RouterOS saugumo atnaujinimą ir rekomenduoja atnaujinti įrenginius. Gamintojas taip pat primena, kad numatytoji MikroTik ugniasienės konfigūracija paprastai neleidžia SSH iš interneto – rizika ypač aktuali ten, kur administravimo prievadai buvo atverti rankiniu būdu.

Kokie pažeidžiamumai svarbiausi?

CERT Polska išskyrė tris reikšmingiausias spragas. Dvi iš jų susijusios su SSH ir gali sudaryti itin pavojingą atakos grandinę.

Be šių spragų CERT tyrime aprašyti ir kiti RouterOS pažeidžiamumai, susiję su SSH klientu, X.509 sertifikatų apdorojimu ir WebFig. Todėl vien tik uždaryti SSH nėra pilnavertis sprendimas – būtinas pats RouterOS atnaujinimas.

Kurios RouterOS versijos turi pataisas?

Oficialiame MikroTik saugumo pranešime pataisos nurodytos šiose versijose:

Kodėl viešai atidarytas SSH yra tokia didelė problema?

SSH pats savaime nėra nesaugus protokolas. Problema atsiranda tada, kai administravimo servisas be būtinybės publikuojamas visam internetui. Tokį servisą nuolat gali pasiekti automatizuoti skeneriai ir atakų infrastruktūra.

INTERNETAS
    ↓
Viešai pasiekiamas MikroTik SSH
    ↓
Pažeidžiamumo grandinės išnaudojimas
    ↓
RouterOS administratoriaus teisės
    ↓
Ugniasienės / NAT / DNS / VPN konfigūracijos pakeitimai
    ↓
Vidinio tinklo perėmimo arba srauto peradresavimo rizika

Maršrutizatorius yra vienas jautriausių infrastruktūros taškų: jis valdo eismą tarp interneto, serverių, darbo vietų, kamerų, gamybos tinklų ir VPN. Todėl maršrutizatoriaus kompromitavimas gali būti daug rimtesnis nei vieno vartotojo kompiuterio pažeidimas.

Kokius kompromitavimo požymius nurodo CERT Polska?

CERT pateikė kelis konkrečius indikatorius, kurių reikia ieškoti. Jie nėra vieninteliai galimi požymiai, tačiau jų radimas turi būti laikomas rimtu incidento signalu.

• žurnalo įrašai su login failure for user -2 ... via ssh;
• vartotojo sukūrimo įrašai, kuriuose matomas šaltinis ssh:-2@...;
• nežinomas aukštų privilegijų vartotojas ops;
• nepažįstami scripts arba scheduler darbai;
• netikėtos proxy konfigūracijos;
• nežinomi tuneliai arba kiti konfigūracijos pakeitimai.

CERT stebėtuose incidentuose sėkmingos atakos, tarp jų ir ops paskyros sukūrimas, buvo siejamos su IP 82.192.72.4, o bandymuose taip pat matytas 103.102.31.18. Šiuos adresus verta naudoti kaip tyrimo indikatorius, bet vien jų blokavimas nėra apsauga nuo pažeidžiamumo.

Kas yra RouterOS „Flagged“ būsena?

Pataisytos RouterOS versijos paleidimo metu tikrina konfigūraciją dėl tam tikrų žinomų neautorizuotų pakeitimų požymių. Aptikus įtartiną konfigūraciją, RouterOS gali ją išjungti, parašyti kritinį įrašą žurnale ir pažymėti įrenginį kaip Flagged.

Būseną galima patikrinti administravimo terminale:

/system/device-mode/print

Tačiau tai nėra pilnavertis kompromitavimo skeneris. CERT aiškiai nurodo, kad Flagged nebuvimas nereiškia, jog įrenginys tikrai švarus. Mechanizmas aptinka tik pasirinktus žinomus pėdsakus.

Ką patikrinti MikroTik administratoriams?

Po atnaujinimo rekomenduojame atlikti bent bazinę konfigūracijos peržiūrą. Žemiau pateiktos komandos skirtos gynybinei patikrai; jų rezultatus reikia vertinti jūsų konkrečios infrastruktūros kontekste.

# RouterOS versija ir paketai
/system/resource/print
/system/package/print

# Ar nėra nepažįstamų vartotojų
/user/print detail

# Scripts ir automatinės užduotys
/system/script/print detail
/system/scheduler/print detail

# Valdymo servisai ir jų prieigos ribojimai
/ip/service/print detail

# Bandwidth test serverio būsena
/tool/bandwidth-server/print

# Device mode / Flagged būsena
/system/device-mode/print

# Aktualūs žurnalo įrašai
/log/print where message~"ssh"
/log/print where message~"Flagged"

Taip pat būtina rankiniu būdu peržiūrėti ugniasienės, NAT, DNS, proxy, VPN, interface ir maršrutizavimo konfigūraciją. Automatinis palyginimas su anksčiau saugiai išsaugotu tekstiniu export gali padėti pastebėti neplanuotus pakeitimus.

Kaip apriboti valdymo paslaugas?

Geriausias modelis – maršrutizatoriaus valdymo servisų išvis nepublikuoti į internetą. Administratorius pirmiausia prisijungia prie saugaus VPN, pavyzdžiui, WireGuard, o tik tada pasiekia WinBox, SSH ar WebFig per administravimo tinklą.

Administratorius
      ↓
WireGuard VPN
      ↓
Administravimo VLAN / trusted subnet
      ↓
MikroTik WinBox / SSH / WebFig

Jeigu SSH jums nereikalingas, jį galima išjungti. Jei reikalingas – apriboti tik konkretiems administravimo IP ar tinklams. Tokius pakeitimus atlikite atsargiai, kad neužblokuotumėte savo administravimo prieigos.

Jeigu įtariate, kad MikroTik jau kompromituotas

Tokiu atveju vien „pakeisti slaptažodį ir atnaujinti“ gali būti nepakankama. CERT rekomenduoja incidentą vertinti kaip realų įrenginio perėmimą.

1. Izoliuokite įrenginį nuo nepatikimų tinklų ir sustabdykite galimą tolimesnį naudojimą atakai.
2. Išsaugokite įrodymus – logus, tekstinį konfigūracijos export ir kitą tyrimui reikalingą informaciją prieš reset.
3. Nevalykite „Flagged“ ir nenaikinkite žurnalų prieš išsaugodami medžiagą.
4. Atstatykite gamyklinius nustatymus ir konfigūraciją sukurkite iš patikimo, patikrinto šaltinio.
5. Neatkurkite aklai pilno binary backup iš galimai kompromituoto maršrutizatoriaus – kartu galite sugrąžinti nepageidaujamus pakeitimus.
6. Pakeiskite slaptažodžius, raktus ir kitus secret, kuriuos galėjo pasiekti užpuolikas.
7. Patikrinkite gretimas sistemas: VPN peer'us, administravimo darbo vietas, serverius ir kitus įrenginius, kuriuos kompromituotas routeris galėjo pasiekti.

Kuo ši situacija svarbi įmonėms?

Ataka prieš maršrutizatorių gali būti naudojama ne tik pačiam įrenginiui perimti. Užpuolikas gali bandyti išnaudoti jį kaip atramos tašką vidinio tinklo žvalgybai, srauto peradresavimui, tuneliams ar tolesniam sistemų kompromitavimui. Todėl tinklo įranga turi būti įtraukta į bendrą įmonės atnaujinimų, stebėsenos ir incidentų valdymo procesą.

INsec rekomendacijos MikroTik aplinkoms

• Nedelsiant atnaujinti RouterOS į pataisytą, jūsų kanalui tinkamą leidimą.
• Nepalikti WinBox, SSH ar WebFig viešai prieinamų iš viso interneto.
• Administravimui naudoti WireGuard/IPsec VPN arba atskirą administravimo tinklą.
• Jei valdymo servisas turi būti pasiekiamas – riboti jį pagal patikimus šaltinio IP.
• Išjungti nenaudojamas paslaugas, ypač bandwidth-test server.
• Naudoti atskiras administravimo paskyras ir mažiausių būtinų teisių principą.
• Reguliariai saugoti tekstinį RouterOS export saugioje, nuo routerio nepriklausomoje vietoje.
• Stebėti konfigūracijos pakeitimus ir RouterOS logus centralizuotai.
• Segmentuoti vartotojų, serverių, kamerų, IoT ir valdymo tinklus VLAN bei ugniasienės taisyklėmis.
• Periodiškai atlikti išorinę inventorizaciją: kokie valdymo prievadai realiai pasiekiami iš interneto.

Trumpa patikros atmintinė

1. RouterOS pataisytas?              → TAIP / NE
2. SSH pasiekiamas iš interneto?     → TAIP / NE
3. WWW / WWW-SSL viešai atidarytas?  → TAIP / NE
4. Bandwidth-test įjungtas?           → TAIP / NE
5. /system/device-mode/print švarus?  → TAIP / NE
6. Nežinomi vartotojai?               → TAIP / NE
7. Nežinomi scripts/scheduler?        → TAIP / NE
8. Keistos NAT/DNS/proxy/VPN taisyklės?→ TAIP / NE
9. Loguose ssh:-2@ arba user -2?      → TAIP / NE
10. Yra patikimas konfigūracijos export?→ TAIP / NE

Ką daryti, jei administruojate daug MikroTik įrenginių?

Valdant dešimtis ar šimtus maršrutizatorių didžiausia problema yra ne pats vieno įrenginio atnaujinimas, o inventorizacija: reikia žinoti, kokia versija veikia kiekviename įrenginyje, kokie servisai atviri, kas turi administratoriaus prieigą ir ar konfigūracija atitinka jūsų standartą.

Tokioje aplinkoje verta turėti centralizuotą RouterOS versijų ir konfigūracijų kontrolę, monitoringo perspėjimus, saugų administravimo IP/VPN modelį ir periodinį viešai pasiekiamų servisų auditą. Saugumo procesas turi būti pakartojamas – ne vienkartinis veiksmas po naujienos apie CVE.