Jurnal HAVOC IT

Două conturi pe care nu le cunoșteam. Ce am găsit într-un MikroTik expus la internet

Două conturi admin necunoscute pe un router expus și decizia de a reconstrui configurația.

Autor
Bogdan CostanCofondator și consultant IT principal
Ultima revizie tehnică

Totul a început cu un avertisment primit de unul dintre clienții noștri de la furnizorul de internet.

Nu căzuse conexiunea. Routerul funcționa, utilizatorii aveau internet, iar din exterior nu exista niciun semn evident că s-ar fi întâmplat ceva. Avertismentul indica însă că anumite porturi ale routerului MikroTik erau accesibile din internet într-un mod în care nu ar fi trebuit să fie.

Configurația fusese realizată înainte să preluăm administrarea infrastructurii de rețea și nu aveam un motiv operațional pentru ca serviciile respective să rămână expuse public.

Primul lucru pe care l-am făcut când am intrat pe router a fost să închidem accesul care nu era necesar.

Apoi am început să verificăm configurația.

Și am găsit două conturi de utilizator pe care nu le recunoșteam.

Ambele aveau drepturi complete asupra routerului.

Din momentul acela, problema nu mai era doar „avem niște porturi deschise”.

Două conturi necunoscute nu îți spun automat ce s-a întâmplat

Este tentant să vezi două conturi administrative necunoscute și să tragi imediat concluzia că routerul a fost compromis.

Noi nu putem demonstra asta doar din existența lor.

Nu știm cine le-a creat, când au fost create sau prin ce metodă. Ar fi putut proveni dintr-o intervenție mai veche care nu fusese documentată. Ar fi putut avea o explicație legitimă pe care noi nu o mai puteam reconstrui.

Dar nici nu le puteam ignora.

Două conturi cu privilegii complete, pe un router care avea servicii expuse către internet și a cărui configurație fusese administrată anterior de altcineva, erau suficiente pentru ca noi să nu mai considerăm configurația existentă drept una de încredere.

În securitate există o diferență importantă între „știm că sistemul a fost compromis” și „nu mai putem demonstra că sistemul este curat”.

În cazul nostru eram în a doua situație.

Între timp, CERT Polska publicase ceva mult mai interesant despre RouterOS

Momentul a coincis cu publicarea unor vulnerabilități importante descoperite de cercetătorii CERT Polska în MikroTik RouterOS.

Pe 5 septembrie 2026, CERT Polska a publicat informații despre șase vulnerabilități identificate în RouterOS. Analiza tehnică publicată ulterior clarifică faptul că două dintre ele, CVE-2026-67279 și CVE-2026-86060, formează lanțul de atac MikroTrick. Acesta poate permite preluarea completă a unui dispozitiv fără autentificare atunci când serviciul SSH al routerului este accesibil din rețele publice. CERT Polska a confirmat și atacuri reale împotriva dispozitivelor RouterOS cu SSH expus la internet.

Cele mai importante dintre vulnerabilitățile descrise sunt greu de ignorat.

CVE-2026-67279 permite, în anumite condiții de renegociere a cheilor, unei conexiuni SSH să ajungă la etapa de sesiune fără finalizarea autentificării. Singură nu stabilește un utilizator autentificat și nu acordă privilegii. CVE-2026-86060, evaluată de CERT Polska cu CVSS 9.2, folosește un nume de utilizator special construit și poate conduce la drepturi administrative complete. Împreună, cele două vulnerabilități formează lanțul MikroTrick.

Separat, CVE-2026-67276 (CVSS 9.2 în analiza CERT Polska) afectează verificarea cheilor publice RSA folosite pentru autentificarea SSH. În anumite condiții, un atacator care cunoaște numele contului și modulul cheii RSA publice asociate se poate autentifica fără cheia privată corespunzătoare. Această vulnerabilitate nu face parte din MikroTrick.

O altă vulnerabilitate importantă, CVE-2026-67277, afectează serviciul bandwidth-test și poate permite divulgarea unor fragmente de memorie sau provocarea unui restart al sistemului. Vulnerabilitățile descoperite nu se limitează însă la aceste trei; cercetarea CERT Polska a inclus și probleme în alte componente RouterOS, inclusiv WebFig și procesarea certificatelor X.509.

MikroTik a publicat actualizări de securitate și a recomandat explicit administratorilor să nu permită accesul SSH din rețele neîncrezătoare și, preferabil, să nu expună deloc interfețele de management direct în internet.

Înseamnă că routerul clientului nostru fusese atacat prin MikroTrick?

Nu știm.

Și este important să spunem asta.

Faptul că un router are două conturi necunoscute nu demonstrează că acestea au fost create prin vulnerabilitățile descoperite de CERT Polska. Nu aveam suficiente dovezi pentru a lega direct situația clientului de MikroTrick și nu vrem să transformăm o suspiciune într-o certitudine doar pentru că cele două evenimente se potrivesc bine într-o poveste. Din avertismentul primit nu putem demonstra nici că serviciul SSH al acelui router era expus.

CERT Polska a publicat inclusiv indicatori concreți pentru atacurile observate de ei, printre care anumite mesaje în loguri și apariția unui utilizator foarte privilegiat numit ops. Organizația avertizează însă și că absența acestor indicatori nu demonstrează că un dispozitiv nu a fost compromis.

Pentru noi întrebarea relevantă era alta.

Mai puteam avea suficientă încredere în configurația routerului încât să schimbăm două parole și să mergem mai departe?

Răspunsul a fost nu.

Un update repară vulnerabilitatea. Nu repară neapărat ce s-a întâmplat înainte

Am actualizat RouterOS la o versiune care conținea corecțiile de securitate.

Era un pas necesar, dar nu era suficient.

Dacă un sistem a fost într-adevăr compromis înainte de instalarea unui patch, actualizarea elimină vulnerabilitatea prin care atacatorul ar fi putut intra, dar nu înseamnă automat că dispar utilizatorii, scripturile, tunelurile sau alte modificări făcute anterior.

MikroTik recomandă chiar verificarea configurației după actualizare pentru utilizatori necunoscuți, scripturi sau alte elemente care nu sunt recunoscute de administrator. CERT Polska merge mai departe: atunci când există indicii rezonabile de compromitere, recomandă păstrarea dovezilor disponibile, resetarea dispozitivului și reconstruirea lui pornind de la o configurație în care administratorul poate avea încredere, urmată de schimbarea parolelor, cheilor și a celorlalte secrete utilizate.

În cazul nostru aveam deja cele două conturi administrative necunoscute.

Așa că am preferat să nu ne bazăm doar pe update.

De la o configurație necunoscută la una în care puteam avea din nou încredere

Am închis serviciile de management care nu aveau niciun motiv să fie disponibile public.

Am schimbat parola contului administrativ și am actualizat RouterOS.

Apoi am reinstalat RouterOS curat.

Motivul era simplu: nu voiam să continuăm să administrăm o configurație despre care nu puteam spune cu certitudine cine și ce modificase înainte.

În paralel am început rotația credențialelor care ar fi putut fi cunoscute sau stocate pe router. Nu ne-am limitat la parola administratorului MikroTik. Au fost schimbate și celelalte credențiale relevante pentru infrastructură, inclusiv cele asociate conexiunii furnizate de RDS.

Dacă presupui că un dispozitiv de rețea ar fi putut fi compromis, schimbarea unei singure parole nu rezolvă neapărat problema.

Routerul poate avea acces la alte parole, chei, configurații VPN, credențiale PPPoE sau alte informații pe care nu vrei să continui să le consideri secrete doar pentru că nu ai dovada că au fost citite.

Rotația lor a fost, în cazul acesta, varianta prudentă.

Porturile deschise nu sunt vulnerabilitatea, dar pot transforma una într-o problemă

Probabil aceasta este partea cea mai utilă a întregii intervenții.

Un port deschis nu înseamnă automat că cineva îți poate compromite routerul. SSH, HTTPS sau alte servicii de management există tocmai pentru a putea fi folosite.

Problema este de unde pot fi accesate și dacă există cu adevărat un motiv pentru ca ele să răspundă oricui din internet.

În cazul vulnerabilităților MikroTrick diferența este foarte concretă: CERT Polska spune că atacurile confirmate vizează dispozitive RouterOS al căror serviciu SSH este accesibil din rețele publice. MikroTik recomandă blocarea accesului din rețele neîncrezătoare și sugerează utilizarea unui VPN precum WireGuard pentru administrarea de la distanță, în locul publicării directe a porturilor de management.

Asta nu înseamnă că un router actualizat și bine configurat nu poate avea niciodată un serviciu accesibil din exterior.

Înseamnă doar că „avem nevoie de portul acesta deschis?” ar trebui să fie o întrebare cu un răspuns, nu o stare rămasă dintr-o configurație făcută cu câțiva ani în urmă.

Ce am păstrat din incident

Nu putem spune că am demonstrat cum au apărut cele două conturi.

Nu putem spune nici că vulnerabilitățile MikroTrick au fost folosite împotriva clientului nostru.

Putem spune însă ce am găsit: servicii care nu trebuiau să fie expuse public și două conturi cu drepturi complete pe care nu le puteam asocia unei persoane sau unei intervenții cunoscute.

Într-o asemenea situație, am preferat să tratăm routerul ca pe un dispozitiv a cărui integritate nu mai putea fi garantată. Am limitat expunerea, am actualizat RouterOS, am schimbat credențialele, am reinstalat sistemul și am reconstruit o stare în care puteam avea din nou încredere.

Asta este partea mai puțin spectaculoasă a unui incident de securitate.

De multe ori nu afli cine a intrat, de unde sau ce intenționa să facă.

Uneori nici măcar nu poți demonstra că a intrat cineva.

Dar poți decide ce nivel de incertitudine accepți într-un dispozitiv prin care trece traficul întregii companii.

În cazul acesta, două conturi administrative necunoscute au fost suficiente ca răspunsul nostru să fie: prea multă incertitudine ca să lăsăm configurația așa.

Publicat:

Surse

WhatsApp