Ce s-a întâmplat
Cercetătorii au identificat un nou botnet IoT, denumit Cling, care își ascunde canalul de comandă și control (C2) în trafic conceput să semene cu răspunsuri de la serviciul public Google STUN (Session Traversal Utilities for NAT) — același protocol folosit zilnic de aplicațiile de videoconferință și browsere pentru a afla adresa IP publică și portul unui dispozitiv. Pentru că schimburile STUN reprezintă zgomot de fond obișnuit în majoritatea rețelelor, traficul fals de înregistrare și comenzile Cling se amestecă printre activitatea legitimă în loc să declanșeze alerte.
Cling se răspândește exploatând vulnerabilități cunoscute, nepatchuite, în routere, access point-uri, repetoare și echipamente de înregistrare video expuse pe internet care rulează cod Realtek SDK vulnerabil, în special CVE-2021-35394. Analiștii au găsit în probă și cod de exploatare pentru alte câteva CVE-uri, extinzând raza de acțiune a malware-ului la o gamă largă de echipamente de rețea pentru consumatori și firme mici.
Cum funcționează deghizarea
STUN în sine este un protocol inofensiv — comunică unui dispozitiv adresa IP publică și portul, pentru ca două sisteme să se poată conecta peste NAT. Cling abuzează exact de această încredere. Odată ce infectează un dispozitiv, contactează 13 servere STUN codate static, la aproximativ fiecare cinci secunde, colectează porturile raportate de aceste servicii, apoi trimite un al doilea mesaj, non-standard: un pachet de „înregistrare” care raportează porturile mapate, împreună cu o etichetă ce descrie modul în care dispozitivul a fost compromis.
Majoritatea celor 13 servere ignoră pur și simplu acest trafic fals de înregistrare — dar cercetătorii au găsit unul care nu a făcut-o. Acesta a returnat un răspuns malformat, care nu a reflectat corect identificatorul cererii, un semn clar că se întâmpla ceva neobișnuit. Trimițând acelui server, în teste controlate, seturi unice de porturi, cercetătorii au confirmat că, ore mai târziu, comenzi au ajuns exact la acele porturi — dovadă că serverul „STUN” respectiv retransmitea de fapt instrucțiuni către dispozitivele infectate. Operatorul ascunde aceste comenzi în câmpul de 12 octeți pe care STUN îl folosește în mod normal pentru a asocia cererile cu răspunsurile.
Pachetele care transportau comenzi păreau chiar să provină din infrastructura reală Google STUN. Cercetătorii consideră că explicația cea mai probabilă este falsificarea adresei IP sursă (spoofing), nu o compromitere a serverelor Google — valorile duratei de viață a pachetelor diferă de traficul autentic Google, iar dovezi că infrastructura Google a fost implicată sau compromisă nu există.
De ce contează
Odată instalat, Cling se ancorează temeinic: se copiază în locații ascunse, adaugă intrări de pornire în mai multe mecanisme init pentru a supraviețui unei reporniri, iar, într-o mișcare deosebit de persistentă, înlocuiește utilitarul standard de descărcare al dispozitivului cu o versiune trojanizată care continuă să îndeplinească funcția originală — ceea ce înseamnă că întreținerea de rutină sau descărcările viitoare pot redeclanșa silențios infecția.
De acolo, dispozitivele infectate devin infrastructură de unică folosință pentru operatorul botnetului: descarcă payload-uri suplimentare, retransmit trafic, deschid tuneluri, funcționează ca proxy sau lansează atacuri de tip denial-of-service la comandă. Cercetătorii au observat instrucțiuni de atac îndreptate către un furnizor de internet, o rețea universitară și servicii de gaming, deși nu a fost publicat niciun număr confirmat de infecții sau o întrerupere de serviciu confirmată. Tiparul este similar altor botnet-uri IoT recente care transformă dispozitivele de margine compromise în rețele proxy controlate de atacatori.
Ce aveți de făcut
- Actualizați dispozitivele expuse. Prioritizați routerele, access point-urile, repetoarele și camerele IP construite pe cod Realtek SDK, în special orice echipament încă vulnerabil la CVE-2021-35394 sau la celelalte CVE-uri incluse în această probă.
- Restricționați accesul de intrare la interfețele de administrare ale dispozitivelor care nu pot fi actualizate imediat și segmentați dispozitivele IoT/de margine față de segmentele critice de rețea.
- Urmăriți anomalia, nu doar destinația. Traficul care pare legitim către un serviciu de încredere precum Google STUN nu este automat sigur — semnalați cererile STUN frecvente cu identificatori de tranzacție complet zero, mesajele UDP de „înregistrare” neașteptate și dispozitivele care se abat de la comportamentul lor normal de comunicare.
- Auditați configurația de pornire și utilitarele de bază (scripturi init, fișiere rc, instrumente de descărcare) de pe dispozitivele expuse, pentru a detecta modificări neautorizate, care pot indica persistență chiar și după o repornire.