Egy zsarolóvírus támadás története, tanulságai

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.

Vírustámadás

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.

Roger zsarolóvírus
Az Attila felhasználó letöltések mappájában megtalálható a payload.exe, a kódolást végző vírus egyik példánya, néhány, a támadáshoz használt segédprogram társaságában. A háttérben pedig a mentések „biztonsági” törléséhez használt Disk wipe program.
A post mappa név vélhetően arra utal, hogy a támadást követően az „utómunkát” ezekkel a programokkal végezték el, az egyik akadályozza a felhasználó hozzáférését a géphez, a másik pedig a naplók törlésével a nyomokat takarítja el.

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:

  1. Adathalász módszerrel megszerezték az ügyvezető admin jogú fiókjának név/jelszavát.
  2. 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.
  3. 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.
  4. 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.

Gondolatok az IT biztonságról 2. – egy majdnem bekövetkezett katasztrófa története

A „Gondolatok az IT biztonságról” című cikk folytatásaként most ismét zsarolóvírus témával jelentkezünk, ezúttal ismét egy kicsit más incidenssel kapcsolatban. A tapasztalat még nagyon friss és számtalan tanulsággal szolgál, cégtulajdonosnak, felhasználónak és üzemeltetőnek egyaránt. Ezt a cikket főleg nekik ajánlom, de legfőképpen a cégtulajdonosok figyelmét szeretném vele felhívni, ugyanis a most következő történetből jól látszik majd hogyan kerül veszélybe egy egész cég élete pillanatok alatt. Azok közül pedig akik ezt elolvassák jó eséllyel nagy számban lesznek olyanok, akik legalább ekkora (ha nem nagyobb) veszélynek vannak kitéve jelen pillanatban is, legfeljebb nem tudnak róla.

Zsarolóvírus

A most következő történet egy hónapja történt egyik ügyfelünkkel. A probléma alapját a korábbi cikkünkből jól ismert támadási módszer (RDP támadás) jelentette, ami több kisebb-nagyobb hiba együttállásával majdnem katasztrófába torkollott. A cikk végén végigvesszük majd részletesen is ezeket a hibákat és a lehetséges megoldási alternatívákat, megelőzési módszereket is pontokba szedjük, de még mielőtt erre kitérnénk engedjenek meg nekem egy kis kitérőt. Számtalanszor felmerült már az a kérdés, hogy mennyit ér meg nekünk adataink biztonsága. 2019-et írunk, réges-rég az információ korában élünk, adataink a legnagyobb értékeink. Egy cég fennmaradását alapjaiban rengetheti meg, ha nagyobb mennyiségű adatot veszít. A jelenlegi cikkben szereplő cégünk mérnöki tervezéssel foglalkozik, ipari projektekbe tervez 3D-s CAD alkalmazásokkal, mérnökök egész hadát foglalkoztatja, akik szoros határidőkkel készítik el és küldik meg a különböző projektekhez tartozó rajzokat. A projektek elnyerése nem kevés munkával jár, a különböző szabványokhoz mindent alaposan dokumentálni kell, tárolni, meg kell tudni őrizni és a megadott határidőre le kell azt adni. Ebből működik a cég, az ezért járó díjakból fizeti a dolgozóit, családok megélhetése múlik rajta. Aztán bekerül a rendszerbe egy új vírus és mindezeket egy pillanat alatt veszélybe sodorja, mert ha elvesznek az adatok és a cég nem tudja a projektre beküldeni a rajzokat határidőre, munkákat veszít el emiatt, akkor mindez alapjaiban kerül veszélybe. Azért ajánlom most vezetők figyelmébe ezt a cikket, mert a végére mindenki számára világos lesz, hogy vannak hatékony megoldások a kockázatok csökkentésére, a legtöbbje még csak nem is pénz kérdése, de mivel sokan szimplán nem foglalkoznak ezekkel, amíg fájdalmas gyakorlati tapasztalatot nem szereznek, így nagyon sok cég van ezek miatt veszélyben.

A jelen cikkben szereplő partnerünknél 4-5 évvel ezelőtt telepítettünk egy kisvállalati Windows Server-t, ami az Essentials változatnak megfelelően tartományvezérlő, fájl szerver, WSUS (frissítés) kiszolgáló szerepköröket lát el, emellett a Windows Server biztonsági másolat készítő programját használja, amivel egy különálló (de fizikailag a szerverben lévő) merevlemezre készít mentéseket. A szervert annak idején a megszokott pontossággal, precizitással telepítettük, elkészítettük a rendszer teljes dokumentációját (amit nagyon sok rendszergazda szimplán kifelejt, mi sem szeretünk dokumentációkat írni), a kliens gépeket tartományba léptettük, majd átadtuk az elkészült rendszert a megrendelőnek. A havi átalánydíjas karbantartási szerződés ötlete már ekkor felmerült, de mivel több olyan műszaki beállítottságú ember is volt a cégnél, így végül közülük ketten kaptak rendszergazda jogokat és évekig ellátták a feladatokat. Néha kaptunk megkeresést komolyabb problémák esetén, de a napi feladatokat, a gép esetleges ellenőrzését ők végezték, ha végezték. A kezdetben szereplő két rendszergazda közül valamelyik 2015. októberében létrehozott egy Admin nevű felhasználót, ami nem csak túl általános nevű volt (elsők között fognak a támadók admin és administrator nevű felhasználókra jelszavakat próbálni), de vélhetően nagyon egyszerű jelszóval is lett ellátva, ez adta ugyanis a támadás alapját, a címtár szerint kb. 1300 hibás próbálkozás előzte meg a támadást és a jelszótörő program betalált a szerverre. Mivel az az audit funkció nem volt bekapcsolva a szerveren, ami naplózná a felhasználó létrehozásának körülményeit (bár ez annyira régen volt, hogy amúgy se lenne már meg a napló), így csak az időpontot tudjuk megállapítani. A szervernek évekig nem volt (rendszer)gazdája, míg kb. 1 évvel ezelőtt egy havidíjas szerződéssel megkaptuk az üzemeltetését. Innentől a havi ellenőrzési procedúra részévé vált a szerverük ellenőrzése, többek közt rendbe lett téve a korábban gyakran hibázó biztonsági mentés is. Egy dolog viszont nem volt az ellenőrzési procedúra része, mégpedig, hogy a különböző felhasználók adminisztrátori jogait nézegessük, az igazat megvallva nem is voltunk ehhez hozzászokva, hogy utólagosan vegyünk át egy már ismert, de jelentősen megváltozott rendszert, pláne olyan bújtatott felhasználókkal, amikkel egyébként már korábban is feltörték a szervert. Ennek nyomait találtuk ugyanis több helyen a gépen, egy időben (2015 őszén és 2016 tavaszán) 2 alkalommal is spamküldésre használták fel, mígnem 2019. február elején egy másik próbálkozás ismét betalált a könnyen támadható „admin” felhasználón keresztül.

Természetesen a problémából mi is levontuk a következtetéseket és a szerver karbantartási procedúra részévé tettük a jogosultság ellenőrzést, ami nem egyszerű feladat egyébként. Ezen kívül minden olyan általunk üzemeltetett szerveren, ahol rajtunk kívül másnak is rendszergazda joga van bevezettük a címtárnak azt az audit házirendjét, ami naplózza az új felhasználók létrehozását és a jogadásokat. Mivel ez a biztonsági napló része, ami rengeteg bejegyzést tartalmaz, így rövid időn belül felülíródik, ugyanakkor 1-2 héten belül így is lehetőség van visszanézni ki mit csinált a szerveren. Ezt kiegészítettük egy saját készítésű Powershell scripttel, ami minden este megvizsgálja a főbb rendszergazda csoportokat és ha bármelyik tagságában változás áll fenn értesítést küld. Ezt a két intézkedést kombinálva a jövőben meg tudjuk előzni a felesleges, kontroll nélkül rendszergazdai jogosultságokból eredő problémákat.

A történet vége szerencsére happy end lett, egyik nap délután 2-kor leállt a rendszerük, addigra szinte minden fájlt titkosított a szerveren a vírus. Másnap reggel munkakezdéskor visszakapták az előző nap hajnalban készült biztonsági mentésből teljesen visszaállított gépet. A gép olyan szinten vírusozódott be, hogy a Windows is romba dőlt, így a rendszerpartíciókat a kb. 1TB adatot tartalmazó adatpartícióval együtt kellett poraiból feltámasztani. Mivel egy olyan friss vírust kaptak, amire nem áll rendelkezésre decryptor (a titkosított fájlok visszafejtését elvégző) program, így a délelőtt folyamán keletkezett néhány fájl elveszett, ami nagyon minimális adatvesztésnek tekinthető, ugyanis a támadáskor éppen megnyitottakhoz nem fért a vírus hozzá, így azok épek maradtak, a biztonsági mentésből történt visszaállítást követően ezeket is visszamásoltuk az ügyfélnek. Így az éppen határidős projektjük legtöbb fájlja megvolt, amin az egész cég dolgozott és egy nagyon veszélyes kriptóvírus támadást sikerült átvészelniük anyagi kár nélkül.

IT biztonság

Okos ember viszont más kárából tanul, ahogy a bevezetőben is ígértem térjünk is rá arra, hogy mivel lett volna csökkenthető vagy megelőzhető ez az incidens.

Rendszergazdai jogosultságok
Ahogyan arra egy korábbi eset is rávilágított sok esetben akár programok telepítői is gyanútlanul nyithatnak réseket a gépünkre, amikor (sokszor felesleges) rendszergazdai jogot adnak egy felhasználónak a gépre, pláne amikor ezt könnyen kitalálható, netalán közismert, fix jelszóval teszik. Ezeknek a jogosultság adásoknak a felülvizsgálata sajnos rendszeres karbantartási feladat kell legyen, ezzel együtt, ahogyan azt feljebb már említettem script segítségével automatizálva is lehet ezt figyelni. Így időben felfedezésre kerülhetnek a problémák, mielőtt azt mások vennék észre. Az informatikában sokat emlegetett „legkisebb jogosultság elve” (principle of least privilege) pedig érvényes kell legyen a rendszerünkre. Tehát minden felhasználónak csak a feladata ellátásához szükséges legalacsonyabb jogosultsága legyen, semmi több. Ez nem csupán bizalmi kérdés egy felhasználóval szemben, de biztonsági követelmény is. Ha egy olyan felhasználónál következik be incidens, akinek túl magas joga van a rendszerben az ő jogaival komoly károk keletkezhetnek. Erre is volt már precedens, amikor egy ügyfélnek sorozatosan felhívtuk a figyelmét rá, hogy a nagy közös mappát érdemes lenne a különböző munkakörök szerint szétbontani és korlátozni a jogokat. Egy vírustámadás a teljes adatállományt elintézte, a visszaállítás fél napot vett igénybe. Ekkor a saját hibájából tanulva hallgatott a tanácsra és megvalósítottuk a szabályozásokat. Néhány hónap múlva egy másik dolgozó is vírust kapott, de ekkor már a korábbi incidens kb. 1%-a volt a kár, biztonsági mentésből kevesebb, mint fél óra alatt helyreállt a rend.

Mentés, mentés és mentés
Számtalan cikkben foglalkoztunk már a témával, zsarolóvírus támadás esetén nincs más menekülés a teljes katasztrófából, csak egy jól működő biztonsági mentés. Szerencsére, mivel nemrégiben kötött ügyfelünk szerződést, így a havi karbantartás alkalmával megnézzük a mentések állapotát, ami így rendben volt. Korábban gyakran voltak vele fennakadások, de ezeket megoldottuk, így volt lehetőség visszaállítani most belőle az adatokat. Ha nincs szerződés és nem megy a mentés, akkor ezúttal egy teljes adatvesztés lett volna a végeredmény és nincs happy end!

Megfelelő jelszóházirend
Jelen esetben a felhasználónév admin volt, ami az ilyen jelszópróbálkozásoknak jó alapot ad. Egyrészt érdemes lehet a rendszergazdai jogosultsággal bíró profiloknál mellőzni az ilyen neveket, mint admin, administrator, root, stb. Másrészt pedig meg kell követelni és kikényszeríteni a bonyolultabb, összetett jelszavak használatát. Ezt sok felhasználó nem szereti, de meg kell érteni, hogy a megfelelő biztonsághoz szükség van egy jó jelszóra. A mi esetünkben egy dologról még nem esett szó, hogy az ügyfélnél az elmúlt évek során a gépeken „elfelejtődött” a tartományi rendszer, ami nem azt jelenti, hogy a gépek felejtettek el tartományban lenni, hanem a folyamatos gépcserék során az új gépek nem lettek beléptetve a tartományba, hanem a felhasználók név/jelszavát tárolták be rájuk, hogy a fájl szervert elérjék. Egyrészt a név/jelszó betárolás sosem szerencsés biztonsági szempontból, bármilyen rendszerről is beszéljünk, de jelen esetben ez azért is jelent problémát, mert a gépeken futó rendszerek így nem kerültek a központi házirendek hatálya alá, ami megkövetelhetné a megfelelő jelszavak használatát, elkerülhető lenne a jelszótárolás és a szerver egyéb más funkciót, mint pl. a központi frissítéskezelés (szintén fontos biztonsági elem!) is használni tudnák. Ezzel szemben a felhasználói igény az, hogy ne is legyen jelszó, a gépre ne kelljen külön belépni. Ez így kényelmes, de ára van, biztonsági kockázatot jelent.

Tűzfal
Az internetre kiengedett portokat ha van lehetőségünk tűzfallal védeni, az szintén hatalmas előny lehet az ilyen támadásokkal szemben. Jelen esetben egy néhány ezer forintos router látta el a feladatot, ami lényegében annyit tud csak, hogy a portokat ki lehet nyitni velük és a megfelelő IP címre irányítani a belső hálózaton (NAT-olás), korlátozni viszont a legtöbb ilyen eszköz nem tud. Komolyabb gyártók komolyabb eszközein ugyanakkor már vannak arra is lehetőségek, hogy korlátozzuk egyes portok elérését, méghozzá úgy, hogy eközben mi magunk is el tudjuk érni a szerverünket. A VPN, távoli asztal és az egyéb szerveren futó alkalmazások mind ilyen internet felé nyitott portokat igényelnek, amin sajnos bárki bemehet, a megfelelő név/jelszó birtokában. Lehet kapni több tízezer forinttól a csillagos égig terjedő összegekért neves gyártók profi termékeit, amiket jellemzően a hobbirendszergazdák már beüzemelni sem tudnak, mert komoly szaktudást igényelnek. Sok esetben, nagyvállalati környezetben megvan ezek előnye is, ugyanakkor a kis – és középvállalkozások számára szinte elérhetetlenek, az otthoni felhasználásra gyártott router-ek viszont nem igazán felelnek meg a mai biztonsági elvárásoknak. Éppen ezért ezen ügyfeleinknek egy rendkívül olcsó és könnyen kivitelezhető megoldást szoktunk javasolni, még pedig egy Linux alapú (tehát ingyenes szoftverrel telepített) tűzfal gép személyében. Mindössze egy megbízható, stabil PC kell hozzá minimális hardverrel (a legtöbb esetben egy 5 éves irodai processzor, 2GB memória és 5-10GB-nyi HDD bőven elég) és egy extra hálózati kártyával, amit ha egy használt brand gépből hozunk ki legfeljebb 25 ezer forintból ki lehet alakítani. A telepítése és beállítása természetesen szakértelmet igényel, de kellő rutinnal igen rövid idő alatt elvégezhető, nem kell csillagászati költségekkel számolni munkadíjra sem. Ezzel szemben sok olyan szolgáltatást kaphat meg egy ingyenes rendszertől, amiért a nagy gyártóknál komoly összegeket kell fizetni. Ezek közül talán az egyik legfontosabb, amit alkalmazni szoktunk az a geográfiai alapú (GeoDB) szűrés. Sok esetben nincs szükség az országhatáron kívülről történő elérésre, így a legtöbb ügyfél esetében a Dél-Amerikából, Afrikából, Oroszországból, Kínából és Ázsia legtöbb részéről a teljes bejövő forgalmat tiltani lehet. Egy ilyen szűrés a támadások több, mint 2/3-át alapból kiszűrik, mivel ezek közt szerepelnek a kiberbűnözéssel leginkább fertőzött országok is. Amennyiben levelező rendszer nem üzemel a hálózatban úgy szinte csak Európára lehet korlátozni az elérést. Fontos hangsúlyozni, hogy ilyen esetben se VPN-ezni, se távoli asztalozni nem lehet az adott országból és mivel ingyenes megoldásról, ingyen hozzáférhető adatbázisról beszélünk, amiből a tűzfal a tudást meríti így nagy ritkán előfordulnak hibák emiatt, de ez eltörpül amellett a problémahegy mellett, amitől megóvja a rendszert. A szabályokat pedig bármikor lehet finomítani, ki-be kapcsolni egyes területek elérését.

RDP Defender
A távoli asztal elérés védelmére, a bejövő kapcsolatok korlátozására szokták alkalmazni ezt a programot. A lényege, hogy megszünteti a végtelen jelszópróbálkozások és a rengeteg különböző IP címekről jelentkező robotok próbálkozásait azzal, hogy a beállított korlátok alapján bezárja előttük a kaput.

Megfelelő vírusvédelem
A szerverre telepített vírusvédelem mindig nehéz kérdés. Elvben, mivel munka nem zajlik a kiszolgálón, így vírusnak sem kellene bejutnia rá, amivel okafogyottá válik a vírusvédelem telepítése. Ezzel szemben a szerverekre telepített védelmek gyakran okoznak fennakadásokat, lassulásokat a szerver gépek életében még akkor is, ha megfelelően konfiguráltuk őket. A gyártó egy esetleges hibája a vírusdefiníciós fájlok frissítésekor hatalmas összeomlást tud eredményezni, mint ahogy sok ilyen elő is fordult már a történelemben. Így mérlegelni kell a kockázatokat és a védelem használatából eredő problémákat, hogy érdemes-e védelmet telepíteni. Az is nagy előnye lehet egy fájl szerverre telepített vírusirtónak, hogy ütemezetten lehet vele ellenőrizni a fájl szerverre felkerülő fájlokat, ami a kliensek biztonságát is nagyban javítja.

Ahogyan az a fentiekből is látszik azért annyira sok befektetést sem munkaórákban, sem költségben nem igényel, hogy drasztikusan tudjuk javítani a rendszerünk biztonságát. Azt a rendszerünkét, aminek egy apróbb gyengesége is a cégünk életébe, emberek megélhetésébe kerülhet. Következő cikkünkben bemutatjuk majd azt a tűzfalmegoldást, ami ingyenes és mind stabilitásban, mind tudásban fillérekből tud nekünk olyan nagyvállalati szintű megoldást biztosítani, ami mögött már jobban biztonságban érezhetjük magunkat.

Facebook