SECTOR16 – aktív kampány hazai OT és vezérlési rendszerek ellen
A mai nappal hivatalossá vált, hogy a SECTOR16 kampányba kezdett és magyar vezérlési környezeteket céloz meg. Publikáltak ugyanis egy újabb meghekkelt, hazai vezérlési környezettel kapcsolatos bizonyítékot, és szerintem több lehetséges áldozat is ott van már a csőben.
A képen egy épület HVAC – hűtés, fűtés, ventillálás - (valószínűleg BACNet-alapú) vezérlése látszik, amely tartalmazza a hőközponti és légtechnikai és klímavezérlést.
Az áldozat jelen esetben (valószínűleg) egy ismertebb fitness/wellnes központ, és ma már a figyelmeztetés is másképp szól:
Mi vagyunk a SECTOR16, és ma átvettük az irányítást a klímarendszeretek felett!
Helyszín: Budapest város, MagyarországMit „optimalizáltunk”?
– A hőmérséklet most inkább a Nap felszínére emlékeztet: 264 °C bent, 200 °C kint (kösz a „kreatív” beállítási megközelítésünknek).
– A ventilátorok csutkán pörögnek – 3506 m³/óra.
– Radiátorok: 0% – teljesen kiiktatva.
– A meleg víz most konkrétan forr – 85 °C – tökéletes azonnali teafőzéshez.Mi ment tönkre?
– Fertőtlenítés – kiiktatva.
– A mikrobák mostantól a lakótársaitok.
– Az „automata mód” most azt jelenti: azt csinálunk, amit akarunk.
– Fagyvédelmi rendszer – a rendszer most fagyásveszélyben van.
Mit lehet tudni?
Tulajdonképpen most már mindent.
A SECTOR-nak - bármennyire is szofisztikált képességekkel rendelkezik - az előző és a mostani történetben sem kellett megerőltetnie magát.
Az áldozatok szerepelnek egy olyan oldalon, ahova azokat az IP címeket gyűjtik, amelyeken hozzáférhető – és egyébként már kompromittált távelérés működik.
Az érintett IP címeket egy automata kompromittálja – pontosabban a távelérés gyenge jelszavait kihasználva bejelentkezik ezekbe a rendszerekbe, képernyőképet készít róluk és a képet, valamint a hozzáférési adatokat publikálja.
A SECTOR16 tehát ezt a listát böngészi és az ezen a listán szereplő címeket kompromittálja újra, viszont már a mögöttes alkalmazásba is bejelentkezve készíti el róluk a bizonyíték videókat és képeket.
Akkor meg lehet mondani, hogy kik lesznek a következő áldozatok?
Amennyiben ezt a módszert követik továbbra is, szerintem igen. Az oldal tartalma legyűjthető és feldolgozható, és ezt meg is tettük.
Jelenleg 110 olyan magyar rendszert tartalmaz az oldal, amelyekre az automata be tudott lépni – valamilyen nagyon gyenge, sok esetben 1-8 karakteres vagy egyéb nagyon egyszerű jelszóval. Mivel az oldal tartalmazza a jelszavakat is, ezért gyakorlatilag ezekbe a hosztokba bárki be tud jelentkezni.
A feldolgozott lista alapján jelenleg 44 olyan hoszt van, amely most is elérhető és amelynek a hozzáférési adatait az oldal publikálja. A 44 hosztból kettő az, amit a SECTOR16 publikált, a tegnapi geotermikus és a mai HVAC rendszer. Azaz van 43 lehetséges jövőbeli áldozat.
Sok rendszer van, ami valamilyen dinamikus IP-t használ, ezek akár többször is megjelennek a listában, az éppen aktuális IP címükön (ezeket távolról nem IP, hanem jellemzően valamilyen dinamikus DNS alapján érik el az aktuális címükön).
Hogy kerül fel a rendszer egy ilyen listára vagy oldalra?
Sajnos elég egyszerűen. Tipikusan a rossz konfiguráció és a kiberbiztonság teljes semmibevétele az oka. Elég az hozzá, hogy kipublikálunk egy ilyen távelérést – mindenféle védelem, és megfelelő jelszóhigiénia nélkül.
Az ilyen automaták bejárják az internetet és megpróbálkoznak az ismertebb táveléréses protokollokon keresztül kapcsolódni a hosztokhoz. Ha van kapcsolat, akkor megpróbálja a jelszót „feltörni” – általában valamilyen szótárba gyűjtött ismert, gyenge és sokszor használt jelszavakkal próbálkozik. Vannak olyan automaták is, amelyek nem nyers erő és szótár alapon próbálnak bejelentkezni, hanem a távelérési protokoll sérülékenységét kihasználva jelentkeznek be a rendszerbe.
Hogy kik vannak most a listán?
Elég szomorú kép alakul ki bennünk ezzel kapcsolatban.
A 44 jelenleg is elérhető rendszer között sajnos vannak vízművek, állami intézmény, gyárak és egyéb termelőkörnyezetek (kémiai gyártó, szörpgyártó, üvegházi termelő, stb – és persze akadnak közöttük lakások, otthonok kipublikált vezérlései is.
A listákat átadtuk az NKI-nek és folyamatosan kommunikálunk az NKI szakembereivel, akik gőzerővel dolgoznak az azonosításokon és a lehetséges kiértesítéseken.
Azt mindenkinek meg kell azonban értenie (ez szigorúan a saját véleményem), hogy az NKI elkötelezett és profi munkája ebben az esetben sem tud csodát teremteni: nagyon sokszor csak IP címek azonosíthatóak, amelyekből legfeljebb a szolgáltatót lehet megállapítani. Ebben az esetben az NKI sem tud mást tenni, minthogy megkeresi a szolgáltatót és a segítségét kéri a konkrét érintett azonosításában. Ez pedig idő és bürokrácia. A bürokrácia pedig tulajdonképpen adatvédelem, az ilyen információ kikérésnek megfelelő jogalappal és dokumentáltsággal kell rendelkeznie. Az nem úgy van, hogy Analiszt Lajos az NKI-tól ráír az XY szolgáltató ügyvezetőjére, hogy Bélám, ki ez az IP cím? Szerencsére tudom, hogy a szolgáltatók is elkötelezettek ezekben az ügyekben és bízom abban, hogy gyorsan tud a szakma reagálni erre a kampányra.
Tehetünk-e mi magunk valamit?
Igen. Sőt, ez a legfontosabb és leghatékonyabb.
Ellenőrizzük a tűzfalainkat és a táveléréseket. Ha publikáltunk távelérési szolgáltatást, akkor vizsgáljuk meg, hogyan tettük, milyen védelmi szabályok mellett, illetve, hogy a jelszóhigiénia milyen azokon az eszközökön. (Ezt egyébként amúgy is szükséges időnként ellenőrizni, most azonban – szerintem – kötelező).
Ha működtetünk ipari rendszerekhez ilyen táveléréseket – ellenőrizzük!
(Igazából nem csak ipari vezérlések esetén van erre szükség, csak most ilyen kampányt csinálnak feltehetően orosz barátaink).
Intelem
Hányszor de hányszor fordul az elő, hogy ilyen esetekben azzal védekezik valaki, hogy „hát de azon keresztül nem lehet beavatkozni, az csak monitorozásra jó”.
Nem.
Egyrészt az, hogy szerinted mire jó és hogy a támadó mit fog csinálni, sokszor nem függ össze. Természetesen, ha egy ilyen proof videóban az látszik, hogy a támadó operátor felhasználóval jelentkezik be, az nem jelenti azt, hogy:
- az az operátor nem tud beavatkozni
- nem tud a támadó másképp is bejelentkezni, magasabb privilégiummal
- vagy éppen az alacsony privilégiumból – valamilyen sérülékenységet kihasználva – nem csinál magának magasabb privilégiumú hozzáférést (privilege escalation)
Persze lehetnek olyan felületek, amelyek funkcionálisan nem tartalmaznak beavatkozási funkciókat és tényleg csak monitorozásra, felügyeletre jók.
Azonban a támadó már bent van a hoszton, a tevékenysége tehát nem biztos, hogy csak az adott alkalmazáshoz fog kötődni, arról a hosztról már akár hozzáférhet más eszközökhöz vagy rendszerekhez. Ezért nem lehet egyszerűen elintézni azzal a dolgot, hogy szerintem ott nem tud beavatkozni a támadó a folyamatba. Ez ennél sokkal komplexebb dolog, amit tényleg vizsgálni és értékelni kell.
Egyébként – az, hogy egy orosz barátunk bejelentkezik a mi rendszerünkbe – ez már akkor is súlyos incidens, ha éppen nem csinál a rendszerben semmi galádságot.
Ez ugyanis bűncselekmény, akárhogy is nézzük. Ipari rendszerek esetében pedig óriási kockázatot hordozhat – hiszen az esetleges beavatkozása a fizikai világban csapódik le, ott fog nem kívánt eseményt okozni.