Mostanában számos kérdést kaptunk vállalati ügyfelektől, döntéshozóktól hálózati biztonság, biztonságos távelérés témakörében. Ezúttal ezt a témát próbáljuk meg kicsit jobban körüljárni. Választ kaphatunk arra hogyan tudjuk akár fillérekből is nagyvállalati szintre növelni a biztonságot, egyúttal felhívjuk a figyelmet számtalan buktatóra is. A téma most különösen aktuális, amikor a pandémiás időszakban a támadók első számú célpontjaivá éppen a távoli elérésű dolgozók váltak.
Elsőként kezdeném is ezzel a témával, a home office-ban dolgozó felhasználóval. A cyber bűnözők rendszerint nagyon rafinált és okos emberek. A régi számítástechnikai megoldásoktól ma már elérkeztünk olyan védelmi szintre a vállalatok esetében, ami komoly kihívások elé állítja a behatolókat, akik természetesen mindig mindenhol a leggyengébb pontot keresik meg és első körben azt támadják. Ez a leggyengébb pont pedig legtöbbször maga a felhasználó. Adathalász próbálkozások, zsaroló levelek tömegei landolnak minden pillanatban az e-mail fiókokban vagy pattannak le a spamszűrőről. Rengeteg ilyen sajnos célba is ér és a 2020-as év tapasztalatai alapján azt mondhatom egyre több és több jár ezek közül sikerrel. Ilyenkor ugye valamelyik jelszavát a gyanútlan dolgozó megadja egy harmadik félnek, így adott esetben megszerzik a hozzáférést munkáltatója valamelyik rendszeréhez. Ez ellen egyetlen igazán jó megoldás az oktatás, ezt jellemzően nagyvállalatok meg is teszik rendszeresen, ezért fizetnek embereket vagy cégeket, akik megtartják időről-időre az oktatást és tesztelik is néha a felhasználókat. Az adathalász spam levelek ellen pedig lehet spamszűrőkkel és olyan vírusvédelemmel is védekezni, ami a tipikus jelekről felismeri ezeket, pl. mikor a levélben található link más, mint ami a képernyőn megjelenik.
A tavalyi évvel kezdődően elindult egy „cyber pandémia” is, az otthoni gépeket célzó támadások. Mivel sokan home office-ba kényszerültek, tartósan távolról dolgoznak, amihez nem minden cég tud biztosítani megfelelő eszközöket, így sok esetben a munkavállaló a saját gépén dolgozik, amihez kap valamilyen szoftveres megoldást a munkáltatótól. Ez lehet egy VPN kliens program vagy sok esetben a Windows saját VPN kliense. Azt már sokkal nehezebben ellenőrzik a cég biztonsági emberei, hogy a gép milyen állapotban van, pl. a gyerek, aki lehet egy órával előtte játszott rajta kikapcsolta a vírusirtót, hogy a kedvenc játékát egy trójai vírusos crack segítségével aktiválni tudja, esetleg vírusvédelem sincs a gépen, miközben a számára kiadott VPN hozzáférés segítségével be lehet jutni a cég belső hálózatába. Szerintem nem kell magyaráznom milyen probléma hegyeket görget ez minden résztvevő elé, a munkáltató nehezen szólhat bele a magán gép dolgaiba, sokszor nem csak hardveres, vagy szoftveres, de még elegendő humán erőforrás (rendszergazda munkaidő) sem áll rendelkezésére ahhoz, hogy ezeket a nehezen felügyelhető külsős gépeket megfelelően, naprakészen védeni tudja. Nagyon nehéz erre bármilyen ajánlást megfogalmazni, mindenképpen ki kell alakítani cégre szabottan egy IT biztonsági protokollt, a felhasználókat oktatni kell a felmerülő problémákra, és a cég lehetőségeihez mérten hardveres, szoftveres erőforrásokkal is segíteni kell a védelmet. Jobb helyeken adnak egy VPN képes routert, ami magától felcsatlakozik a céges hálóra, ezen az előre konfigurált eszközön pedig számos biztonsági megoldás is fut, és csak az erre rákötött géppel lehet a vállalati hálózatba csatlakozni. A szoftveres VPN kliens már egy sokkal problémásabb megoldás, amellé mindenképpen javasolt valamilyen központilag felügyelt védelmi megoldást is telepíteni. Ilyen lehet egy felhő technológiás vírus- és egyéb védelem, vagy az általunk is használt központi konzolos GData Business megoldások, amikor a cég szerverén, egy központi felületen ellenőrizhető a rendszergazda által a védelem állapota. Offline kapcsolat esetén a definíciós fájlokat közvetlenül a gyártótól is le tudja tölteni, amikor online kapcsolatba lép (tehát a felhasználó VPN-en keresztül dolgozik), akkor pedig jelent a központ felé. Egy időközben problémássá váló gép csatlakozását ez önmagában nem akadályozza még meg, de a gép biztonsági állapota már ellenőrizhetővé válik központilag. Természetesen költségekkel jár, további licencek beszerzését igényli, de viszonylag olcsón és könnyen kivitelezhető.
Mindezeken felül fontos megemlíteni a normál, békeidőben is fontos biztonsági intézkedéseket. Erről a korábbi, zsarolóvírusos cikkben már tettem említést, a jelszó protokollról lesz szó. A gyártók nem véletlen akarnak minket arra kényszeríteni, hogy nehezen megjegyezhető, bonyolult és hosszú jelszavakat kelljen megjegyeznünk. Nem ellenünk, hanem értünk van. A csak kis vagy csak nagybetűkből álló, számoktól és egyéb karakterektől mentes jelszavakat mai technikával már sok esetben brute force módszerekkel fel lehet törni. A kis és nagybetűk, számok kombinálása és egy kellően hosszú jelszó megkövetelése hatványozottan megnöveli az ehhez szükséges időt. Javasolt a gyári felhasználói fiókok, rendszergazda és vendég tiltása is, így a felhasználónevet is ki kell először találni a támadáshoz. A rendszeres jelszócserét pedig szintén javasolt a felhasználóktól kikényszeríteni, ami pedig az adathalászoktól védi a rendszerünket. Ha kitudódik egy jelszó, akkor is legkésőbb a jelszó lejáratával már nem lesz felhasználható.
A következő fejezet pedig szóljon akkor a mostanában legtöbb kérdést kiváltó kérdéskörről, a belső hálózat biztonságáról és lássuk azt is miben segíthet nekünk egy vállalati tűzfal. Kezdeném a hétköznapi kisvállalati hálózatok felépítésével és a benne rejlő veszélyek bemutatásával. Egy átlagos kis cég hálózata rendszerint egy kisvállalati SOHO (Small Office-Home Office) router megoldással csatlakozik az internethez. A külső eléréshez szükséges portokat ezzel az eszközzel egyszerűen továbbítják a belső hálózaton lévő, fix IP címes eszköz irányába. Ilyen lehet pl. egy (vagy több) webes felülettel rendelkező NAS, vagy egy kamera felvevő (DVR) egység, mert a kameráinkat szeretnénk a telefonunkról is elérni bárhol és bármikor. Ehhez portokat irányítunk be az eszköz irányába. Sokszor a fizikai hálózatot csak ez a WIFI-s router biztosítja, ha kevés a port akkor egy olcsó, pár ezer forintért kapható switch ad nekünk további csatlakozási lehetőségeket. Nos, első körben például nincs lehetőségünk a SOHO router-en a port továbbítások szűrésére forrás IP cím alapján. Egy vállalati tűzfal esetében megadható, hogy a portot csak akkor továbbítsa, hogyha a kapcsolatot kezdeményező cím ez és ez vagy éppen mindenhonnan engedélyezzük, csak adott helyekről, országokból nem. Ehhez lehet GeoDB alapú szűréseket alkalmazni. Ha pl. lekapcsoljuk a térképről Dél-Amerikát, Oroszországot, Kínát és Ázsia egy részét, ahonnan garantáltan nem kell majd soha kapcsolódnunk a céges hálózatra, amik a világon tapasztalt támadások kb. 2/3-áért felelősek, ezeket meg is előztük vele. Ezek ellen már nem is kell tovább foglalkoznunk. Aztán jön az, hogy a SOHO és a „buta” (management felülettel nem rendelkező) eszközökön nincs lehetőség VLAN-ok (virtuális alhálózatok) kialakítására. Van ahol több router-rel, több fizikai hálózatra bontva van ez megoldva, szintén lehet egy jó megoldás, de messze nem az igazi. A fentebb felvázolt esetben pl. a távoli eléréshez használt NAS-unk kint kell legyen a neten, ha annak szoftverében található egy olyan sebezhetőség amivel az azon futó linuxos rendszerbe valaki be tud jutni az egész rendszerünket feltörhetik miatta. Gondoljunk bele, a belső hálózaton lényegesen védtelenebbek vagyunk, ott számos olyan szolgáltatásunk futhat, amit sose szeretnénk a netre tenni, pl. a fájlmegosztásaink. Ha köztük bármelyik a mindenki csoporttal van megosztva (nagyon gyakran találkozunk ilyennel) az azonnal hozzáférhető is egy sebezhetőségnek köszönhetően. Ha azonban továbbiakat is találnak már mennek is tovább eszközről-eszközre, szolgáltatásról-szolgáltatásra és szép lassan az egész rendszerünk megnyílhat előttük. Itt érdemes felhívni a figyelmet a különböző hardver elemek firmware-ének és szoftvereinek rendszeres frissítéseire is. Az ilyen jellegű sebezhetőség ellen pedig a leghatékonyabb védelem a DMZ. Ilyenkor lényegében egy elszeparált zónát hozunk létre a nyilvánosan elérni kívánt eszköz számára, egy külön virtuális hálózatra helyezzük el, aminek a forgalmát a tűzfalunkon keresztül szabályok útján kontrolláljuk. Tehát pl. a NAS-unkról indítva kéréseket semmit ne lehessen a belső hálózatban elérni, fordítva igen, az internet irányába pedig működjenek a szükséges portok. Ugyanígy egy külön hálózatra le lehet választani a kamerákat (sajnos nem mindig támogatott az eszközökön a VLAN), és csak a kamerát elérni kívánó gépről engedni hozzáférést, így a belső hálózatról nem lehet próbálkozni sem a kamerákon, fordított irányban viszont minden kiinduló kapcsolatot letiltunk, így egy esetleges sebezhetőséget kihasználva a támadó annak az eszköznek a szoftverébe bejut, de a belső hálózatra már onnan nem lát rá. Ugyanígy megtehetjük a WIFI-vel is, hogy a vállalati gépeket egy jobban védett, akár központi hitelesítéses (tehát nem kulcsos) WIFI megoldásra csatlakoztatjuk, míg a vendégeket egy teljesen elszeparált VLAN-ban, csak az internet irányába engedjük ki és semmire nem láthatnak rá a hálózatunkon. Természetesen ezt a belső hálózatot is van lehetőség többfelé, akárhány részre bontani.
Végül essen szó a biztonságos távelérésről is. A VLAN-okhoz hasonlóan lehetőség van többféle VPN példányok konfigurálására, ezek különböző címzést kapnak és ezekhez tudunk szabályokat definiálni. A hitelesítés pedig történhet akár központi címtárból is LDAP vagy Radius segítségével, így a név/jelszó cserét egy helyen a VPN szolgáltatásra is meg lehet oldani. A különböző példányokat pedig ilyen esetben úgy állítjuk be, hogy az egyiknek szinte korlátlan hozzáférése van a hálózati erőforrásokhoz, és/vagy minden VLAN-ra rálát (ez jellemzően a rendszergazdai vagy ügyvezetői VPN), az átlagos dolgozó pedig munkakörei alapján csak a munkájához szükséges erőforrásokhoz kap a tűzfalon hozzáférést. Tehát pl. ha van több szerver és valakinek elegendő csak az egyikhez hozzáférnie, akkor az Ő VPN-jén nem engedélyezzük annak az IP című gépnek az elérését. Ha valaki mégis feltörné a VPN-jét és be tudna vele csatlakozni, akkor is az az adott gép védett maradna. Ilyen VPN-ből pedig tetszőleges számút le lehet gyártani, mindegyiket egyedi beállításokkal. Akár még vendég felhasználót is beengedhetünk egy szolgáltatást elérni valamelyik gépen, akkor csak annak az adott gépnek az IP címét kell engedélyezni, vagy csak adott gépnek az IP címét és az azon futó adott szolgáltatásnak a portját, mert ezt is lehet még tovább finomítani. Természetesen ilyenkor is fontos, ahogy fentebb írtam, a távolról elérni kívánt gép ha így engedünk hozzáférni távolról potenciális veszélyforrást, akkor egy DMZ-ben, külön privát hálózatban legyen elkülönítve, ha valamelyik vendég rossz szándékkal akárhogy bejut az egy szem szerverre, akkor arról ne lásson rá a hálózat többi részére.
Technikailag az ilyen típusú hálózatok kialakításához management felülettel rendelkező eszközök kellenek, a tűzfal és a hálózati switch-ek is kell tudják ezt kezelni. A SOHO eszközökön ezzel szemben csak egyetlen hálózat van, a fentebb leírtakból egyet sem lehet alkalmazni. Pontosabban a vendég WIFI megoldására a jobb router-ek adnak könnyen alkalmazható megoldásokat, de ezek kétes biztonságúak, nem VLAN alapú megoldások szoktak lenni, szimplán a címzéssel szoktak bűvölni ugyanazon fizikai hálózaton. Ettől függetlenül ha más lehetőségünk nincs, érdemes lehet azt a funkciót is kiaknázni. Egy egyszerűbb web managed típusú switch manapság már könnyedén elérhető bárki számára, nem csak egy cég életében nem tétel, de sokszor még magánemberek is otthonra megveszik, mert nem csak biztonságosabb, de stabilabb megoldásokat is nyújtanak. Maga a tűzfal, ami ezeket nekünk összefogni képes már nagyon sok féle megoldásban és felállásban elérhető, számos brand gyártó hardveres megoldása közül választhatunk, ezeknek még külön extra biztonsági lehetőségei is vannak (pl. együttműködik a kliensoldali vírusvédelemmel, teljes biztonsági megoldást nyújt, lehetőség van újabb generációs tűzfalmegoldások használatára, ahol már nem csak port szinten zajlik a szűrés, de azon belül, protokoll szinten is, stb.), a legtöbb helyen azonban az ingyenesen elérhető linuxos megoldások is nagy előrelépést jelenthetnek. Érdemes tehát megfontolni cégvezetőként, mert nem jelentenek manapság akkora ráfordítást egy cég életében, viszont a hálózatunk biztonságán rengeteget lehet vele fejleszteni.
Az alábbi történetet elsősorban céges ügyfeleknek ajánlom figyelmébe, de rengeteget tanulhatnak belőle a magán felhasználók is. Nehéz tapasztalatokkal indult a 2021-es évünk, sok átvirrasztott éjszakával, reménytelennek tűnő adathelyreállítási próbálkozásokkal, majd végeredményben egy tökéletesen kivitelezett zsaroló vírus támadás szinte szó szerint minden tapasztalatával. Ezeket a tapasztalatokat szeretném most megosztani mindenkivel, egyrészt segíteni felkészülni, másrészt kicsit jobban megérteni, belelátni abba hogyan is dolgoznak a csalók. Mivel ezúttal számtalan technikai tapasztalatot is szereztünk így a cikknek egyes részei, bekezdései kicsit száraz szakmai leírások lesznek, hogy ne maradjanak ki azok se a részletekből akik erre is kíváncsiak és értik is amiről beszélek. Azok számára, akiknek ezek a részek érdektelenek lehetnek majd igyekszem mindig felhívni a figyelmet hol érdemes tovább lépni. A szigorúan szakmai témakörrel rendelkező paragrafusokat ezért igyekszem majd piros háttérrel jelölni. Akit ez a rész nem érdekel nyugodtan ugorjon tovább a következő fejezetre.
Január első napjaiban történt meg egy ügyfelünk rendszerén, hogy egy sikeres behatolást követően zsarolóvírus áldozatává vált a szerver. Amit felhasználói oldalról tudni érdemes, hogy a gépen két ügyviteli szoftver volt használatban kb. 170GB-nyi adatbázissal, ezen felül kb. 500GB-nyi adat a fájl szerveren. Továbbiakban pár további technikai információ, akik számára nem releváns nyugodtan átugorható.
A gépen egy szinte teljesen naprakész Windows Server 2016 Essentials futott, ami legutóbb november végén volt frissítve, tehát mindössze a decemberi frissítések hiányoztak csak róla. A gépet a Windows Defender védte a vírusoktól, a Windows saját tűzfalával együtt ez felelt a védelemért. A külső tűzfal egy szolgáltató által biztosított router volt, mindössze az SSTP alapú VPN és egy RDP port volt továbbítva rajta a szerver felé, ezek közül az RDP a Windows saját tűzfalán korlátozva volt a helyi hálózat és egy publikus IP cím irányából. A brute force támadások ellen pedig egy RDP Defender szolgáltatás védte a gépet. A gépben egy RAID1 tükör védte a hardveres meghibásodástól az adatokat, a napi szintű biztonsági mentés a Windows saját beépített mentő szoftverével helyben készült egy különálló lemezre.
Magáról a támadás kezdetéről sajnos kevés információnk van, mivel a rendszer napló tanulsága szerint a hacker a támadás befejeztével egy külön erre a célra szolgáló programmal törölte a naplókat. Egy dolog biztos, hogy az egyik ügyvezető profiljával távoli asztaloztak be a gépre, tehát megtudták a név/jelszavát, nála a letöltések mappában megtaláltuk azokat az eszközöket, amiket a hacker használt a munkája során. A mappák időbélyege és a napló törlés alapján az egész tevékenysége kb. 20-25 percet vett igénybe.
Ez alatt az idő alatt a gépre belépve letöltött oda egy mappát néhány hasznos segédprogrammal. Első körben egy kis program segítségével kikapcsolta a Windows Defendert és a tűzfalat, így a védelem inaktív lett, ezt megelőzően pedig belenyúlhatott a tűzfal konfigurációjába is, mivel ott is találtunk több ismeretlen elemet. (A Defender egyébként a később telepített vírust felismerte volna, tehát ennek komoly jelentősége volt.) Vélhetően a következő körben tölthette le a többi, már kártékonynak is minősülő segédprogramot, melyek közül a legfontosabb elem a hacker körökben nagyon népszerű mimikatz.exe volt. Ez a kis segédprogram nem csinál mást, mint a gép memóriájából kiszedi az ott tárolt jelszó hash-eket (titkosított jelszavakat) és azokat elküldi a címtárnak. (Normál esetben egy billentyűzeten begépelt jelszót a gép titkosítva tárol be a memóriába, ezt a változatot küldi el és hasonlítja össze a címtár a saját, szintén titkosítva tárolt változatával. Ha egyezik, akkor megvan a hozzáférés.) Így már a következő körben sikerült a legmagasabb szintű admin jogosultságot is megszerezni a géphez, amivel megnyíltak a támadási lehetőségek. Több módosítást is felfedeztünk a címtárban, pl. a VPN-hez szinte minden címtárban lévő felhasználónak hozzáférést adtak, vélhetően egy esetleges visszatéréshez. Végezetül letöltöttek a gépre egy Disk wipe nevű, kimondottan adatmegsemmisítésre kifejlesztett segédprogramot, és elindították a mentéseket tároló lemezen, majd ezzel nagyjából egy időben indították a gépre töltött zsarolóvírust és közvetlen a kapcsolat bontása előtt egy naplókat módszeresen törlő alkalmazással törölték a nyomokat. A vírus elvégezte a feladatot (majdnem teljesen, de erről majd később), a Disk wipe pedig gyakorlatilag ment egy kört a backup lemezen.
A gépre való belépéskor nagyjából másfél órája futhatott a vírus, ami elég volt neki az adatok kb. 80-90%-ának a titkosítására, a biztonsági mentéseket tároló lemezen pedig akkor váltott 99%-ra a Disk wipe folyamat, amikor leállítottuk. Az első dolog, amit ilyenkor az ember ellenőriz és ezt ajánlom is mindenki figyelmébe, az a feladatkezelő. Miután az ügyvezető profilja be volt jelentkezve távoli asztallal és a neve alatt futott egy halom kártékony program így természetesen első körben a felhasználó került kijelentkeztetésre, majd következett a feltört tartományi adminisztrátor felhasználó futó folyamatainak ellenőrzése, ahol szintén volt egy futó példány a vírusból, ez is azonnal leállításra került. A javasolt eljárás ilyenkor mindig az, hogy a lehető legrövidebb idő alatt le kell állítani a gépet teljesen, ha nem értünk hozzá és biztosra akarunk menni (ez az otthoni felhasználóknak is egy jó tanács!), akkor inkább tépjük ki a gépből a tápkábelt és áramtalanítsuk le, a lényeg, hogy a vírus minden másodpercben adatot semmisít meg a gépen, így minden másodperc számít! Itt jól látható volt melyik folyamat végzi ezt, így annak kilövése után még pár perc gyors adatbegyűjtés következett, amivel elő lehet készülni míg a gép hozzánk kerül. Így végül távolról leállítottuk a gépet és jeleztük az ügyfélnek, hogy semmi esetre se kapcsolja vissza. Ezt követően egy olyan 3-4 nap vette kezdetét, amit az ellenségünknek sem kívánnánk.
A szervizbe szállítást követően első körben több helyreállító programmal is átvizsgáltuk a biztonsági másolatokat tároló lemezt, hiszen annak egy esetleges helyreállításával egy előző napi időpontra visszaállítható lett volna a teljes rendszer, adatokkal együtt. Ehhez végigpróbálgattuk a jól bevált GetDataBack, majd az R-Studio és az Easeus nevű gyártó legjobb adathelyreállító szoftvereit is, sajnos mindet reménytelenül. A legidegőrlőbb az egészben, hogy ezek a szoftverek egy teljes, mélyreható elemzést a lemezen (ami egy 1TB-s winchester volt jelen esetben) több órán át csinálnak, majd egyes esetekben a talált fájlstruktúra megnyitása is 1-1,5 órát igénybe vehet, a helyreállítás szintén és a végén legtöbbször kapunk egy kupac szemetet, sok haszontalan sérült adatot. Ez esetben még azt sem, mivel a Disk wipe-ot olyan jellegű adatmegsemmisítésre szokás használni, ami véletlenszerűen beleírva vagy különböző katonai szintű megoldásokkal, algoritmusokkal teszi tönkre a lemezen lévő adatokat. Később a piacon legnagyobb múltú adathelyreállítással foglalkozó cégtől, a Kürt Kft-től is ezt az információt kaptuk, de erről majd lentebb.
Amíg a backup lemezzel küzdött egy gépünk, addig utána jártunk pontosan, hogy mivel is állunk szemben. A RAID tükröt megbontottuk első körben és az egyik lemezt eredeti állapotában, egy esetleges későbbi adathelyreállítás céljából félretettük, a másik lemezen pedig egy teljes, offline vírusellenőrzést végeztünk el egy GData által készített boot lemezzel. A vírusirtó Crisys.E néven azonosította, később több témában jártas szakértő viszont a Phobos/Dharma egy Roger nevű variánsaként azonosította, ezt a nevét pedig onnan kapta, hogy .roger kiterjesztésűek voltak a fájlok, amiket generált. Ahogyan az ilyenkor lenni szokott és a témában jártas szakértők is egyből ezt javasolják, mi is ezt tettük, felkerestük a www.nomoreransom.org oldalt, ahol egyébként minta feltöltéssel is lehet segítséget kérni és ellenőrizhető pillanatok alatt, hogy az éppen aktuális vírusunk ellen van-e valami ellenszer. Ahogyan a legtöbb ilyen esetben szokott lenni, természetesen nem volt, illetve a pontos az, hogy jelenleg nincs. Ebből a vírus törzsből ugyanis 2016 óta heti 2-3 variáns jelenik meg, számos ilyennek közülük már felkerültek a titkosító kulcsai a netre, így tudtak rájuk decryptert (visszakódoló programot) írni. Itt ez sajnos nem volt meg. Mivel az eredeti Crisys és a Dharma vírusokra is vannak már különböző decrypter programok, gyártott ilyet az ESET, a Kaspersky, a Trend Micro, az Avast és még sokan mások, így természetesen ezeket is egyenként végigpróbálgattuk, de teljesen reménytelenül. Néhány órányi próbálkozás után sajnos bebizonyosodott az, amit jó néhány fórumon írtak, köztük legutóbb 2020. decemberében, ennek a vírusnak egyelőre nincsen megoldása. (Később lehet lesz, ilyenkor tehát érdemes egy időre elrakni a kódolt fájljainkat, mert egy nap még visszakaphatjuk őket.)
Végül kb. 20 munkaórányi adathelyreállítási kísérlet után fel kellett adni a harcot a backup lemezzel is, egyetlen program sem volt képes bármi használhatót visszanyerni belőle. Következhetett tehát az eltitkosított fájlokkal teleírt adatlemez, majd újabb többször több órás körök, melyek során a GetDataBack talált számtalan állapotot a fájlrendszerről, amiket egyenként kb. 1-1,5 óra alatt nyitott meg és kezdetben biztató eredményekkel, ugyanis néhány apróbb fájlt, az ügyviteli szoftverek konfigurációs állományait sikerült helyreállítani, de az öröm így sem tartott sokáig, ugyanis a nagyobb fájlok esetében jól láthatóan más állományok adatai jöttek vissza, azok is legtöbbször sérülten, tehát pl. egy szemmel láthatóan PDF állományt PDF-re átnevezve sem lehetett megnyitni, mert sérült volt.
Közben a közel egy nap alatt teljes vírusirtáson átesett másik lemezen elindult a Windows, számos, de nem végzetes sérüléssel, a vírus ugyanis a Windows mappát csak itt-ott bántotta, jellemzően ikonokat tett benne tönkre, így pl. egyes konzolok csak kikeresve a programokat voltak indíthatóak, viszont működtek. Fentebb esett róla szó, hogy szépen sorban mennyi módosítást találtunk a rendszeren, módosított VPN csoportot, módosított tűzfalkonfigurációt, a csoportházirend beállításokat teljesen hazavágta a vírus, kérdés előtte mihez nyúltak benne. Gyaníthatóan ezeken kívül is több aknát elhelyeztek a gépen, így egy néhány órás vizsgálat és helyreállítási próbálkozás után végül a teljes újraépítés mellett döntöttünk.
2 napnyi, mintegy 40 órányi reménytelen adathelyreállítási próbálkozás után, illetve még annak befejezése előtt elkezdtük a vészforgatókönyveket is végigjárni. Felvettük a kapcsolatot a Kürt Kft-vel, és egy ehhez hasonló vírusokra specializálódott ausztrál adathelyreállító céggel is. Még a második nap éjszakáján elment a levél a támadónak is, akinek a figyelmeztető üzenete a leírással, hogy mit kellene csinálnunk nem jelent meg, mivel a vírus még nem végzett, de az e-mail címe benne volt minden fájlnévben. A Kürt Kft-nél azt mondták ha nincsen visszafejtő kulcsunk az adatokhoz, akkor nem fognak tudni benne segíteni, a Disk wipe után a mentések biztosan nem jönnek vissza, a másik lemezre halvány reményt látnak, de nem sokat. Talán labor körülmények között a winchester megbontásával. Az ausztrál cég már biztatóbb volt, a kapcsolatfelvételt követően kértek tőlünk mintákat, majd visszaírtak, hogy 99% valószínűséggel vissza tudják állítani. Mindezt 4-7 munkanapos átfutással 6 ezer USA dollárból, vagy 48 órával picit több, mint 8 ezerből. A zsarolók mindössze 2 nappal később írtak csak vissza, előbb mintákat kértek, majd amint azt megkapták másnap megírták a követelést, 0.3 bitcoin (jelen árfolyamon picivel több, mint 3 millió forint) 2 napon belül fizetve, vagy 0.55 2 napon túl. Időközben egy személyes ismeretség útján beszéltünk egy szakértővel, aki a támadás módját is segített rekonstruálni, ezen kívül számos hasznos tanáccsal ellátott minket. Többek közt azzal is, hogy addig ne fizessünk senkinek, még adathelyreállító cégeknek sem, amíg nem láttunk rá bizonyítékot, hogy vissza is tudják állítani. Az ausztrálok sem ígértek ilyesmit, mindössze annyit ha nem sikerül nem kell fizetni, de vélhetően a módszerükből adódóan, hogy a helyreállítási kulcs megfejtésébe nem kevés számítási teljesítményt, egy szerver parkot fektetnek be, így a minta visszaküldése pont annyira munkaigényes, mint maga a visszafejtés. Nehéz dilemma, de tényleg nagy kérdés kiben és hogyan bízhatunk ezek után, kinek és hogyan merjünk ekkora pénzeket fizetni ilyen esetekben.
Végül egyiket sem választottuk, így ez a tapasztalat ezúttal elmaradt. 2 napnyi idegőrlő helyreállítási próbálkozás után a visszafejtést és az adathelyreállítást is fel kellett adni, és időközben a cégnek már dolgoznia is kellett volna, így sürgőssé vált a rendszer mielőbbi helyreállítása. Szerencsére a levelezésük nem sokkal korábban költözött át O365-be, így az végig biztonságban volt, belegondolni is rossz mi van, ha a korábbi rendszer szerint gépre vannak letöltve a levelek és azt is elintézi a vírus. Offline mentésük egy NAS-on volt, 1 évvel korábbról. A gyors beavatkozásnak köszönhetően az egyik ügyviteli program adatbázisait csak a 2010-es évig intézte el a vírus, így azokat a 2019. decemberi mentésből vissza lehetett állítani, így ez a szoftver, a cég szempontjából legfontosabb teljesen helyreállt. A fájl szerveren tárolt adatok esetében az R betűig jutott a mappák sorában, így az azt követőek megmenekültek, az R betű előttiek pedig szintén 2019-es állapotra voltak csak visszaállíthatóak. Szerencsére ezen állományok egy jó része már vagy feldolgozásra vagy elküldésre került, esetleg nyomtatva megvan, mások pedig itt-ott levélcsatolmányokból pótolhatóak. Ami nagyobb veszteség az a másik ügyviteli program, amiben így 1 évnyi adat hiányzik, önmagában ezért viszont már nem éri meg az adathelyreállító cégekkel kockáztatni. Azt pedig mi is, minden esetben hangsúlyozzuk, hogy aki csak teheti vagy nem az élete múlik rajta az ne fizessen soha bűnözőknek! Nem csak azért, mert ez motiválja ezeket az embereket, de szakértők arra figyelmeztetnek, hogy nagyon gyakran, az esetek 99%-ában csak a névtelen címre a bitcoin vándorol el, helyreállító kulcsot már nem kapunk. Az pedig a legrosszabb forgatókönyv.
Frissítés: a cikk írását követően, az eset után bő 2 héttel ismét írt a zsaroló, ezúttal alkut ajánlott, első körben 6.000 dollárért teljes visszaállítást kínálva.
Szomorú tapasztalatok, tanulságok
Sajnos a támadás kiindulási pontját továbbra is homály fedi. Az eredeti beállítások alapján túl sok opció viszont nem jöhet számításba, így ezek maradtak:
Adathalász módszerrel megszerezték az ügyvezető admin jogú fiókjának név/jelszavát.
Az egyik kliens gépet támadták meg és a belső hálózat irányából a szerzett jelszóval bejutottak a szerverre.
A home office miatt korábban beállított VPN elérések valamelyikét használták, egy betárolt és visszafejtett név/jelszóval bejutottak a belső hálózatra, ahonnan már elérhető volt a szerver távoli asztala.
Egy harmadik féltől származó eszköz sérülékenységét kihasználva jutottak a belső hálózatba.
A legelső opció a legvalószínűbb és sajnos az ellen a felhasználók biztonságtudatosságának oktatása mellett nem nagyon van más védekezési módunk. Ha kiadja valaki a felhasználónév/jelszavát egy olyan átverős levélre vagy weboldalra, amiből egyre profibb és egyre rafináltabbakkal találkozni, azzal nem sok mindent lehet kezdeni. A tavalyi évben az volt a tapasztalatunk, hogy rengeteg ilyen eset fordult elő, olyan is, amiről utólag tudomást szereztünk és félő, hogy számos olyan is van, amiről nem. A biztonságtudatos felhasználót már említettem, ezen felül jelen esetben két olyan dolog is van, amivel csökkenthető lett volna a kockázata ennek a lehetőségnek. Az egyik, hogyha rendszeresen jelszót kell cserélni. Ha kitudódik egy jelszó, akkor annak hosszabb távú felhasználását így lehet gátolni, persze nagy valószínűséggel ez esetben semmit sem segített volna. Viszont ha az ügyvezető nem rendelkezik admin jogokkal a rendszeren vélhetően a probléma nem áll elő, tehát az ügyvezetői profil admin jogkörrel való felruházása helyett érdemesebb lett volna egy különálló felhasználót (ami nem egy gyári fiók) ellátni inkább egy erős jelszóval, majd azt elzárva tartani olyan esetekre, amikre az ügyvezető a magasabb jogkört is kapta. Mivel ez a profil garantáltan nem lett volna sehol betárolva és adathalászattal se tudták volna kideríteni így megakadályozhatott volna egy sikeres támadást. A következő tanulság pedig, hogy nem szabad engedni a felhasználók nyomásának a biztonság terén. Nem csak ők, de mi magunk is komoly árat fizethetünk érte, jelen esetben számtalan átvirrasztott éjszakát és megszámlálhatatlan mennyiségű munkaórát, illetve elvesztett, nehezen visszaszerezhető adatokat. Számtalan esetben fordult már elő velünk, hogy a felhasználók nem akartak bonyolult jelszót, sőt jelszót sem, vagy mindenkinek ugyanazt, persze sose járjon le és ne is változzon. Ha nem erőltetjük rájuk akkor megváltoztatni sem fogják soha, ez is tapasztalat. A Microsoft ugyanakkor gyárilag nem véletlen követel meg bonyolult jelszavakat, nem engedi ugyanazokat jó darabig újra beállítani, a név egy részét megadni, és kötelezően változtatgatni kell rendszeresen. Ez nem ellenünk, éppen hogy értünk van. A brute force (próbálgatásos) támadások ellen ezek védenek csak. Nem szabad hagyni tehát magunkat és felpuhítani a jelszó biztonságot.
A céges kliens gépről történő betörésnek látom a 4 közül a legkisebb valószínűségét. Egyrészt a gépeket egy fizetős GData Business védte (egyedül magán a szerveren működött Windows Defender), ami egyrészt a piacon elérhető legjobb hatásfokú védelmet nyújtja és kifogástalan állapotban volt mindvégig, a rendszer visszaállításakor az ügynök program ismét jelentett az újratelepített szervernek és kifogástalan állapotban, aktív volt a védelem a gépen. A naplókban és a gépen magán sem volt semmi nyoma behatolásnak. Ráadásul a támadás egy vasárnap esti időszakban történt (bár lehetett időzített is) amikor elvileg nem tartózkodnak bent senki és ha jók az információink, akkor gép sem maradt bekapcsolva.
Sokkal nagyobb a valószínűsége hogyha kliens gépről érkezett a támadás akkor egy tartományon kívüli gépről, ami újabb kérdéseket és problémákat is felvet. Egyrészt amire szakértők is figyelmeztetnek most a világjárvány kapcsán, hogy a rengeteg home office munkavégzés arra ösztönzi a bűnözőket, hogy nagyobb hangsúlyt fektessenek a céges betörések, adatlopások során a sokkal gyengébben védett, támadhatóbb otthoni gépekre, amiket feltörve az azon tárolt hozzáférésekkel be lehet jutni a céges hálózatokba. Ugyan nagyvállalati környezetben régóta vannak ilyen jellegű megoldások is, pl. a Microsoft esetében ott van a NAP, ami nagyon régóta, a 2008-as Windows Server óta része a szerver rendszereiknek és lehetőség van korlátozni a hozzáférését pl. olyan gépeknek, amiken nincs naprakész vírusvédelem. Nagyon részletesen lehet szabályozni, de jellemzően nagyvállalati környezetben használt megoldás, a KKV-k esetében viszont gyakran még az sincs meg, hogy a dolgozójuk biztonságtudatosan használja a gépét, ne adja meg ismeretlen helyeken, levelekre a jelszavait, ne tárolja le őket, pláne ne jegyezze fel egy fájlban olvasható formában és mindig legyen a gépen naprakész vírusvédelem, anélkül egy lépést se tegyen. Abból is lehetőleg valami jobb fajta, de minimum a Windows 10-ben már alapból elérhető Defender. Sokszor ezek az alap dolgok sincsenek meg, viszont a gépre tárolva van egy szerverre csatlakozáshoz használt jelszó, ami így illetéktelen kezekbe kerülhet. A jelenlegi esetben akár egy tetszőleges felhasználó név/jelszava is kikerülhetett első körben, mivel a home office-ok miatt szinte mindenkinek volt VPN joga a rendszerhez. Amint valakinek kitudódott a jelszava a támadó máris házon belülre kerülhetett, ahol már számos kapu nyílt meg előtte. Ezen a ponton pedig muszáj megemlíteni még egy fontos és elég ijesztő dolgot. Nincs hibátlan szoftver, és feltörhetetlen operációs rendszer sem. Semmilyen. Korábbi cikkünkben írtunk egy ügyfélről, akinek konkrétan a D-Link NAS-át törték fel, ott szintén egy rendszer hibát tudtak kihasználni. Ugyanígy különböző protokollok és maga a Windows sem törhetetlen, ez ellen csak a rendszer naprakészen tartásával, rendszeres karbantartásával tudunk tenni. Viszont nagyon sok esetben például a fájl megosztást biztosító protokoll, a régi, erősen sebezhető SMB1 be van kapcsolva a szervereken, mivel egy régebbi hálózati szkenner nem hajlandó csak azzal működni. Sajnos ezt a protokollt pedig nem véletlen, hogy nem lehet szimplán visszakapcsolni, hanem szerepkörként telepíteni is kell a Windows-okra, ugyanis egy hatalmas biztonsági lyukat ütünk vele a rendszerre. Persze kihasználni csak egy helyi hálózaton futó vírus vagy egy bejutott hacker fogja tudni, egyébként nem férne senki hozzá. Az ilyen sebezhetőségek és azok a portok, amiket direkt nem publikálunk ki a netre viszont így mind támadhatóvá válnak, mivel a belső hálózatról érkezik a támadás, amitől védtelen a rendszer.
A negyedik pont is ide kapcsolódik. Amikor egy eszközt rákötünk a hálózatra, majd ahhoz az internet irányából hozzá szeretnénk férni, ahogy jelen esetben van egy felügyeletünkön kívül eső NAS, ami a tudtunk és megkérdezésünk nélkül kerülhetett be a hálózatba, ki tudja milyen jelszóval és hozzáféréssel, illetve egy szintén távoli elérésekre tervezett kamerarendszer is, az ilyen eszközök ugyanúgy lehetnek veszélyforrások. Jobb helyeken vállalati tűzfalakkal ezeket szokás VLAN-okkal elszeparálni, vagy ún. DMZ-be tenni, ami azért fontos, mert amikor egy ilyen eszközt egy ismert sérülékenységet kihasználva feltörnek és bejutnak rá, akkor arról nem tudnak a belső hálózaton további támadásokat indítani. A hálózatot több, egymástól elkülönített virtuális hálózatra lehet bontani, köztük a kommunikációt egy tűzfal ellenőrzi és ez akár portonként és IP címenként is korlátozható. Ezekről a témákról rövidesen egy újabb cikkben jelentkezünk, ahol részletezni fogjuk és bemutatjuk hogyan működik, miért fontos és egyre fontosabb téma ez manapság.
A jelenlegi incidenssel kapcsolatban pedig megfogalmazódnak még további ajánlások is. A SOHO eszközökkel szemben a profi, vállalati tűzfalak szerepét röviden érintettük is, ez szintén ide tartozik. Ezen felül viszont talán még fontosabb pár szót ejteni a mentésről is. A helyi mentés alapvetően egy jó dolog, stabil és gyors, a Windows beépített biztonsági mentés készítője is tökéletesen lekezeli, pillanatok alatt lehet belőle nagyobb mennyiségű adatot is helyreállítani és nem kell nagy mennyiségű adatot hálózaton keresztül küldeni. Ezzel szemben viszont nem véd a fizikai károktól (tűz, víz, betörés, stb.) és sajnos azokban az esetekben is bajba kerülhetünk hogyha a gépre magára jutnak be. Én azt szoktam mondani az már régen rossz, ha a szerverre be tudnak jutni, azt minden lehetséges módszerrel akadályozni kell, onnantól egyébként a helyi mentés is biztonságban van. Viszont amikor egy ilyen jellegű támadás ér minket, akkor csak ez a 3 dolog húzhat ki minket a bajból: 1. mentés 2. mentés 3. mentés
Ha nem áll rendelkezésünkre biztonsági másolat, akkor a mai zsarolóvírusok esetében szinte biztos, hogy vesztettünk. Az árnyékmásolatokat az első pillanatban elintézik. A fájlok eredeti törölt változatai pedig felül fognak íródni a kódolt változatokkal, bár komoly adathelyreállító cégek csillagász összegekért ha szerencsénk van még lehet tudnak benne segíteni. A decrypter eszközök használatára pedig ugyancsak nagyon minimális az esély, hacsak nem valami nagyon elavult vírust szedtünk össze, aminek volt valami hibája és így tudtak rá visszafejtő programot írni. Fizetni pedig csak a legreménytelenebb helyzetben fizessünk, semmi garancia rá, hogy vissza is kapjuk az adatokat, ráadásul a támadókat arra fogjuk vele ösztönözni, hogy folytassák ezt a tevékenységet és mások is ugyanígy járhassanak másnap. Az egyetlen mentőöv, ami ilyenkor segíthet az egy offline mentés vagy egy olyan megoldás, ami a szervertől távol, külső eszközön tárolja az adatokat és a gépnek nincs közvetlen hozzáférése ehhez a területhez, így a vírus nem tudja elintézni. Számos backup szoftver nyújt ilyen megoldásokat és megfelelő sávszélesség mellett a felhő is egy kiváló alternatíva lehet. Jó esetben itt lehetnek a legnagyobb biztonságban az adataink. Ha bizonyos időközönként mi magunknak készítünk egy külső adathordozóra manuális mentést az is lehet egy jó opció, bár ezt sajnos sok esetben, pl. adatbázisok mentésekor nehéz kivitelezni, inkább csak fájl szerveren tárolt adatok mentésére alkalmas megoldás. A lényeg, hogy legyen valamilyen elzárt mentésünk, mert amikor egy ilyen baj ér minket nincs nagyon más kapaszkodó. Az idő előrehaladtával pedig egyre kifinomultabbak lesznek a módszerek, és ahogyan a fenti példából, a számos esetből is látszik egyre gyakoribbak is az ilyen jellegű támadások.
A weboldalunkon sütiket használunk a felhasználói élmény fokozása céljából, hogy megjegyezzük a beállításokat és az ismételt megtekintéseket. Az elfogadásra kattintva minden ilyen süti használatát elfogadod.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.