„Cling“ botnetas slepia valdymo srautą STUN paketuose: ką tikrinti maršrutizatoriuose ir kamerose?
Nozomi Networks Labs aprašė „Cling“ kenkėją, kuris išnaudoja senas tinklo įrenginių spragas, o komandas slepia įprastai atrodančiuose STUN ryšiuose. „Google“ adreso matymas sraute savaime nereiškia, kad „Google“ paslauga pažeista ar dalyvauja atakoje.
Kas yra „Cling“ ir kaip jis patenka į įrenginius?
2026 m. spalio 1 d. „Nozomi Networks Labs“ paskelbė apie „Cling“ – Linux pagrindu veikiančių tinklo ir IoT įrenginių botnetą. Tyrėjai pastebėjo išaugusį bandymų išnaudoti CVE-2021-35394 skaičių. Ši sena Realtek Jungle SDK diagnostinio komponento „MP Daemon“, dažnai kompiliuojamo kaip UDPServer, nuotolinio komandų vykdymo spraga leidžia neautentifikuotam užpuolikui vykdyti komandas paveiktoje sistemoje.
Nozomi aprašytame pavyzdyje išnaudojimo užklausa atsiunčia komandą, kuri parsisiunčia ir paleidžia Linux kenkėjo failą. Tyrėjų analizėje taip pat aptikta kelių kitų žinomų maršrutizatorių, vaizdo įrašymo įrenginių ir kitų tinklo produktų spragų išnaudojimo logika. Tai nereiškia, kad visi įrenginiai su Realtek mikroschema ar kiekvienas konkretaus gamintojo produktas yra pažeidžiamas: svarbus tikslus modelis, jame įdiegti SDK komponentai ir gamintojo programinės įrangos pakeitimai.
Kodėl čia minimas „Google“ ir STUN?
STUN – standartinis protokolas, padedantis įrenginiams nustatyti viešą IP adresą ir prievadą už NAT maršrutizatoriaus. Jį teisėtai naudoja vaizdo konferencijų, VoIP ir naršyklinės realaus laiko komunikacijos programos. Todėl STUN ryšys pats savaime nėra įrodymas apie kenkėją.
Nozomi išanalizuotame „Cling“ pavyzdyje reguliariai siuntė STUN tipo užklausas keliems viešiems serveriams, o valdymo komandas užkodavo STUN paketo operacijos identifikatoriuje. Tyrėjai taip pat nustatė, kad komandas nešę UDP paketai atrodė atėję iš IP adreso, siejamo su „Google“ viešuoju STUN vardu. Pagal paketų požymius jie tai vertino kaip tikėtiną šaltinio IP klastojimą. Tai nėra įrodymas, kad „Google“ serveris buvo įsilaužtas ar kad „Google“ perdavė botneto komandas.
Tyrėjų bandyme vienas kitas STUN serveris atsakė netinkamai pagal įprastą STUN elgseną ir vėliau į jį skirti testiniai prievadai sulaukė komandų. Šis techninis požymis svarbus tyrimui, tačiau apsaugos sprendimų nereikėtų grįsti vien IP reputacija ar vieno adreso blokavimu. Botneto operatorius gali pakeisti infrastruktūrą, o įprastos STUN paslaugos reikalingos verslo programoms.
Kaip kenkėjas išlieka sistemoje?
Analizuotame mėginyje „Cling“ įrašė savo kopijas į paslėptus failus, pridėjo paleidimo įrašus prie Linux/BusyBox pradžios scenarijų ir perėmė „wget“ vykdymą, išsaugodamas originalų įrankį atskiru vardu. Taip kenkėjas galėjo grįžti po perkrovimo ar būti vėl paleistas, kai sistemoje naudojamas failų atsisiuntimo įrankis. Konkretūs pėdsakai priklauso nuo mėginio ir įrenginio, todėl jų nebuvimas nėra garantija, kad įrenginys švarus.
Verta atskirti „Nozomi“ aprašytą „Cling“ mėginį nuo „FortiGuard Labs“ spalio 5 d. paskelbtos analizės, kurioje vartojamas pavadinimas „ClingSTUN“. Pastarojoje pateikiamos ir kitos pradinio patekimo grandinės bei mėginių versijos. Abiejų tyrimų pavadinimai ir panašūs elgesio požymiai nereiškia, kad visi jų indikatoriai yra sukeičiamieji. Incidento tyrime naudokite konkretaus šaltinio mėginiui priskirtus duomenis.
Ką įmonė turėtų patikrinti?
- Inventorizuokite kraštinius įrenginius. Patikrinkite maršrutizatorius, prieigos taškus, kartotuvus, DVR ir kameras: tikslų modelį, programinės įrangos versiją, palaikymo pabaigą ir interneto pasiekiamumą.
- Atnaujinkite arba pakeiskite. Įdiekite konkrečiam modeliui skirtą gamintojo pataisą. Jei įrenginys nebepalaikomas, apribokite jo pasiekiamumą ir suplanuokite keitimą; SDK tiekėjo pataisa ne visada automatiškai pasiekia galutinį įrenginį.
- Pašalinkite nereikalingą viešą prieigą. Išjunkite iš interneto pasiekiamas administravimo, diagnostikos ir kitas nenaudojamas paslaugas. Nuotolinei priežiūrai rinkitės kontroliuojamą VPN ar kitą įmonės valdomą prieigos būdą.
- Atskirkite IoT tinklą. Kameras, įrašymo įrenginius ir tinklo įrangą laikykite atskirame segmente. Apribokite, prie kurių vidinių sistemų jie gali jungtis, ir neleiskite iš jų pasiekti darbuotojų darbo vietų, jei to nereikia.
- Vertinkite srautą pagal elgesį. Ieškokite įrenginių, kurie siunčia pasikartojančias STUN užklausas su nuliniais identifikatoriais, ne STUN formato UDP duomenis į STUN serverius arba ryšius, neatitinkančius įprasto įrenginio profilio. Netikėtą STUN srautą tikrinkite su programų savininkais prieš blokuodami, nes Teams, Zoom, Webex ir WebRTC gali jį naudoti teisėtai.
- Tirkite įrenginį, ne tik adresą. Jei įtariate užkrėtimą, apribokite įrenginio ryšį, išsaugokite turimus tinklo ir sistemos žurnalus, tikrinkite paleidimo konfigūraciją bei „wget“ failus. Atstatymas į gamyklinius nustatymus gali pašalinti tyrimui svarbius įrodymus.
Pirmas praktinis žingsnis: sudarykite interneto pasiekiamų maršrutizatorių, kamerų ir įrašymo įrenginių sąrašą. Senas, neatnaujinamas įrenginys kraštiniame tinkle gali tapti keliu į kitus įmonės išteklius.
Šaltiniai
- Nozomi Networks Labs: A STUNning Disguise: Cling Malware Masquerades as Google
- FortiGuard Labs: ClingSTUN Linux Backdoor Abuses Public STUN Infrastructure
- CVE Program: CVE-2021-35394
- IETF RFC 8489: Session Traversal Utilities for NAT (STUN)
- HackingPassion: Cling Botnet Turns Home Routers and Video Recorders Into Hidden Proxies
Techniniai „Cling“ teiginiai šiame straipsnyje daugiausia paremti „Nozomi Networks Labs“ mėginio analize. „ClingSTUN“ aptariamas atskirai, nes „FortiGuard Labs“ analizėje aprašomos kitos mėginių versijos ir patekimo grandinės. Apsaugos rekomendacijos – INsec praktinės gairės.