MikroTik uzbrukumi jau Latvijā: 12 kompromitētas iekārtas un tūkstošiem potenciālu mērķu

MikroTik uzbrukumi jau Latvijā: 12 kompromitētas iekārtas un tūkstošiem potenciālu mērķu

Latvijā jau identificēti 12 MikroTik iekārtu kompromitēšanas gadījumi, bet vairāki tūkstoši ierīču ir eksponētas internetam. CERT.LV brīdina, ka uzbrucēji aktīvi izmanto divu RouterOS ievainojamību kombināciju, lai pārņemtu ierīces, kuru SSH pārvaldības serviss ir sasniedzams no publiskiem tīkliem.

Uzņēmumiem jārīkojas nekavējoties: jāatjaunina RouterOS, jāierobežo pārvaldības servisu pieejamība un jāpārbauda, vai uzbrucējs jau nav izveidojis jaunus lietotājus, skriptus, plānotus uzdevumus, starpniekserverus vai tuneļus.

Kas Latvijā jau ir konstatēts?

CERT.LV 2026. gada 7. septembra atjauninājumā norāda, ka Latvijā identificēti 12 MikroTik iekārtu kompromitēšanas gadījumi. Vienlaikus konstatēti vairāki tūkstoši internetam eksponētu ierīču, kuru uzturētāji tiek apzināti un informēti.

3. septembrī CERT.LV par apdraudējumu informēja Latvijas kritiskās infrastruktūras uzturētājus un aicināja nekavējoties atjaunināt iekārtas. Atsevišķi apzināti arī citi uzturētāji, kuru ierīces bija pakļautas augstam uzbrukuma riskam.

Skaitlis “vairāki tūkstoši” nenozīmē, ka visas šīs ierīces jau ir kompromitētas. Tas raksturo internetam eksponētas iekārtas, kuras atkarībā no RouterOS versijas un konfigurācijas var būt pakļautas riskam.

Kas ir MikroTrick ievainojamību ķēde?

CERT Polska identificēja sešas MikroTik RouterOS ievainojamības. Tās skar SSH serveri un klientu, joslas platuma testēšanas pakalpojumu, X.509 sertifikātu apstrādi un WebFig pārvaldības saskarni.

Bīstamākā kombinācija, kurai dots nosaukums MikroTrick, apvieno divas SSH ievainojamības:

  • CVE-2026-67276 — SSH publiskās atslēgas autentifikācijas apiešana ar CVSS novērtējumu 9,2;
  • CVE-2026-86060 — SSH sesijas privilēģiju manipulācija, kas ļauj iegūt pilnas administratora tiesības un kuras CVSS novērtējums arī ir 9,2.

Apvienojot abas ievainojamības, novērotajos uzbrukumos iespējams bez derīgiem autentifikācijas datiem pārņemt pilnu RouterOS administratīvo kontroli.

Vai apdraudēta ir katra MikroTik ierīce?

Nē. Pilnīgas pārņemšanas scenārijs, kuru apstiprinājuši CERT Polska un CERT.LV, attiecas uz ierīcēm ar ievainojamu RouterOS versiju, kuru SSH pārvaldības serviss ir pieejams no publiska vai cita neuzticama tīkla.

MikroTik rūpnīcas noklusējuma konfigurācija bloķē SSH piekļuvi no interneta. Lielāks risks rodas, ja administrators šo piekļuvi ir manuāli atvēris, izveidojis pārāk plašu ugunsmūra noteikumu vai pieļāvis pārvaldības servisa publicēšanu nepareizas konfigurācijas dēļ.

Tomēr tikai SSH pārbaude nav pietiekama. Pārējās atklātās ievainojamības skar arī bandwidth-test, X.509 sertifikātu apstrādi, RouterOS iebūvēto SSH klientu un WebFig saskarni.

Kuras RouterOS versijas jāinstalē?

CERT.LV 7. septembra atjauninājumā kā jaunākās publicētās versijas norāda:

  • 7.24.2 stabilajā kanālā;
  • 7.23.5 ilgtermiņa kanālā;
  • 6.49.21 RouterOS 6 ilgtermiņa atzarā;
  • 7.25beta3 beta kanālā.

MikroTik sākotnējā drošības biļetenā norādīts, ka labojums jau bija iekļauts versijās 7.24.2, 7.23.4, 6.49.21 un 7.25beta3. Tā kā pēc tam publicēta 7.23.5, administratoriem jāinstalē jaunākā atbilstošā kanāla versija, ko konkrētajai ierīcei piedāvā RouterOS atjaunināšanas mehānisms.

Beta kanālu nevajadzētu izvēlēties produkcijas ierīcei tikai tādēļ, ka tajā ir lielāks versijas numurs. Jāsaglabā uzņēmuma izmantotais stabilais vai ilgtermiņa kanāls, bet tas jāatjaunina līdz jaunākajai pieejamajai versijai.

Kā uzņēmumam pārbaudīt savu MikroTik ierīci?

  1. Noskaidrot, kas ierīci pārvalda. Ja rūteri pārvalda interneta pakalpojumu sniedzējs, jāsaņem apstiprinājums, ka atjauninājums ir uzstādīts.
  2. Pārbaudīt RouterOS versiju. Pašpārvaldītai ierīcei nekavējoties jāinstalē jaunākā labotā versija izvēlētajā atjauninājumu kanālā.
  3. Pārbaudīt pārvaldības servisus. SSH, WWW, WWW-SSL, WinBox un citi administrēšanas servisi nedrīkst būt brīvi pieejami no interneta.
  4. Pārbaudīt “Flagged” statusu. Pēc atjaunināšanas jāizskata sistēmas žurnāls un ierīces “Flagged” marķieris.
  5. Pārbaudīt lietotājus un konfigurāciju. Jāmeklē nezināmi konti, skripti, scheduler uzdevumi, starpniekserveri, tuneļi, interfeisi un ugunsmūra izmaiņas.
  6. Pārbaudīt savienotās sistēmas. Ja rūteris bijis kompromitēts, jāizvērtē, vai uzbrucējs varēja piekļūt iekšējam tīklam, serveriem, kamerām, darba stacijām vai mākoņpakalpojumu autentifikācijas datiem.

Kādas pazīmes var liecināt par kompromitāciju?

CERT.LV un CERT Polska norāda vairākas novērotajos uzbrukumos konstatētas pazīmes:

  • kritisks ieraksts sistēmas žurnālā un aktivizēts “Flagged” statuss;
  • SSH pieteikšanās kļūdas lietotājam ar nosaukumu “-2”;
  • žurnāla ieraksti par lietotāja pievienošanu SSH sesijā, kas saistīta ar “-2”;
  • nezināms, privileģēts lietotājs ar nosaukumu “ops”;
  • neatpazīti skripti, plānotie uzdevumi, starpniekserveri vai tuneļi;
  • neizskaidrotas DNS, maršrutēšanas, ugunsmūra vai attālās piekļuves izmaiņas.

Šo pazīmju neesamība nepierāda, ka ierīce nav kompromitēta. “Flagged” mehānisms atpazīst tikai noteiktas zināmas izmaiņas, un uzbrucējs var mēģināt savas darbības pēdas dzēst.

Ko darīt, ja ir aizdomas par kompromitāciju?

  1. Izolēt ierīci no interneta un uzņēmuma iekšējā tīkla.
  2. Pirms atiestatīšanas saglabāt žurnālus, konfigurāciju un analīzei nepieciešamo Supout.rif failu.
  3. Ziņot par incidentu CERT.LV un nodot saglabātos materiālus analīzei.
  4. Pēc pierādījumu saglabāšanas atiestatīt ierīci uz rūpnīcas iestatījumiem.
  5. Instalēt labotu RouterOS versiju un konfigurēt ierīci no pārbaudītas konfigurācijas.
  6. Neatjaunot pilnu potenciāli kompromitētas ierīces rezerves kopiju.
  7. Nomainīt paroles, SSH atslēgas, API piekļuves datus, VPN noslēpumus un citus ierīcē glabātos autentifikācijas datus.
  8. Pārbaudīt iekšējās sistēmas, kurām rūteris varēja nodrošināt piekļuvi vai kuru datplūsmu tas apstrādāja.

“Flagged” marķieri nedrīkst dzēst pirms incidenta analīzes un nepieciešamo materiālu saglabāšanas.

Ko darīt, ja atjauninājumu nevar uzstādīt uzreiz?

Līdz atjaunināšanai CERT.LV iesaka atspējot publiski pieejamos pārvaldības pakalpojumus vai ar ugunsmūri ierobežot piekļuvi tikai uzticamām administrēšanas adresēm. Īpaši jāierobežo SSH, WWW, WWW-SSL un bandwidth-test serveris.

RouterOS pārvaldībai drošāk ir izmantot VPN, piemēram, WireGuard, nevis publicēt administrēšanas portus internetā. Neatjauninātā ierīcē nevajadzētu izmantot arī iebūvēto SSH klientu savienojumiem ar neuzticamiem resursdatoriem.

Šie ir tikai pagaidu riska samazināšanas pasākumi. Tie neaizstāj RouterOS atjaunināšanu un ierīces pārbaudi.

Biežākie jautājumi

Vai parasts mājas MikroTik rūteris ir nekavējoties jāatvieno?

Ne obligāti. MikroTik noklusējuma konfigurācija bloķē SSH piekļuvi no interneta, tomēr ražotājs iesaka atjaunināt visas ierīces. Ja rūteri pārvalda operators, jāsazinās ar operatoru un jānoskaidro atjauninājuma statuss.

Vai ar RouterOS atjaunināšanu pietiek?

Nē. Atjauninājums novērš zināmās ievainojamības, bet neatsauc uzbrucēja jau veiktās konfigurācijas izmaiņas. Pēc atjaunināšanas jāpārbauda žurnāli, lietotāji, skripti, scheduler uzdevumi, starpniekserveri un tuneļi.

Vai “Flagged=no” nozīmē, ka rūteris ir drošs?

Nē. “Flagged” marķiera neesamība neizslēdz iepriekšēju kompromitāciju, jo mehānisms identificē tikai noteiktas zināmas pazīmes.

Vai pietiek nomainīt administratora paroli?

Nē. Novērotā ievainojamību ķēde var apiet autentifikāciju un piešķirt administratora tiesības. Nepieciešams atjaunināt RouterOS, slēgt publisko pārvaldības piekļuvi un pārbaudīt visu konfigurāciju.

Vai rūtera konfigurācijas rezerves kopiju drīkst atjaunot pēc atiestatīšanas?

Potenciāli kompromitētas ierīces pilno rezerves kopiju nevajadzētu akli atjaunot, jo tajā var būt saglabātas uzbrucēja izmaiņas. Ierīce jākonfigurē no uzticamas un pārbaudītas konfigurācijas.

Informācija aktualizēta 2026. gada 8. septembrī. Drošības ieteikumi un pieejamās RouterOS versijas var tikt papildinātas.

Oficiālie informācijas avoti

Komentāri

Vēl nav neviena komentāra. Jūsu komentārs varētu būt pirmais!

Pievienot komentāru