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.

Gondolatok az IT biztonságról – Social engineering

Mostanság nap, mint nap sikerül belebotlani az IT biztonsággal kapcsolatos témába a munkám során, már régóta érlelődik bennem a gondolat, hogy ezekből egy jó összefoglaló cikket lehetne írni, amiben rengeteg tanulságos eset és hasznos gondolat lenne. Eljött hát az ideje, hogy rászánjam magam a megírására, remélem sokak figyelmét fel tudom hívni vele a 21. század egyik legnagyobb problémájára, amit az online világgal és minket körülvevő rengeteg digitális adattal és rendszerrel együtt öröklünk meg. Nem is gondolnák sokan mennyi veszély leselkedik ránk nap, mint nap ezekből kifolyólag. Hagy kezdjem először is egy viccel:

  • Mi az: kicsi, sárga és veszélyes?
  • Naposcsibe a root jelszóval.
Social engineering

Bár nem ő jelenti majd számunkra a legnagyobb veszélyt, azért találunk majd a cikk végére szép számban ilyen „napos csibéket”. A cikk megírását egyébként az az élmény is inspirálta, hogy nemrégiben sikerült az egyik népszerű hazai internet szolgáltató egyik eszközében olyan méretű biztonsági hibát találni, ami ugyan nem példátlan (pár Index olvasó egy korábbi cikkében a UPC-nél olvashatott már hasonlóról), de mégis egy olyan mértékű hiba, amely otthoni és céges előfizetők tömegeit teszi ki támadásoknak. Természetesen a hiba jelzésre került a szolgáltató szakembereinek (több alkalommal, több elérhetőségen is, de válasz nem érkezett rá), a probléma viszont jelen pillanatban is valós, így részleteket ezzel kapcsolatban még nem árulhatok el, de amint befoltozásra kerül egy újabb cikkben több részletet elárulhatok majd róla és megírom majd azt is hogyan sikerül egy ilyet felfedezni.

Akit egyébként érdekel a hackerek világa és szeretne kicsit jobban képbe kerülni a gondolkodásmódjukkal, annak nagyon tudom ajánlani a legendás hacker, Kevin Mitnick könyveit. Egy 3 részes sorozatban elárulja a kezdeteket, a motivációkat, leírja a módszereket és azt is milyen hibákat vétettek a felhasználók, amelyek ahhoz vezettek, hogy értékes adatokat tudott megszerezni tőlük.
A legmegdöbbentőbb az, hogy ugyan a könyvei nem a jelen korban, hanem 15-20 évvel ezelőtti történeteket írnak le, a legnagyobb biztonsági probléma megoldására azóta sincsenek jól bevált módszerek. Ez pedig a leggyengébb láncszem, a felhasználó. A mai modern rendszerek a megfelelő biztonsági előírások betartásával és egy ügyes rendszergazda háttérmunkája révén annyira biztonságosnak mondhatóak már, hogy egy értelmes hacker nem is onnan próbál meg adatokat lopni. Majd rá fogunk térni a rendszer lehetséges gyengéire is, de először is nézzük a leggyengébb pontot.
Nagyon sok nagyvállalat és kormányzati szervek is rájöttek már az idők folyamán és nagy hangsúlyt fektetnek a képzésre, hogy biztonságtudatosságra neveljenek, de a gyakorlati tapasztalat azt mutatja, hogy nem sok sikerrel teszik ezt.
Szerintem ez idővel a fiatalabb generációk munkába állásával majd talán változik, sok mostani dolgozó már nem is akar újat tanulni a korából kifolyólag és egyáltalán nem fogékony az oktatásra, de talán a mostani fiatal generációk, akik már online élték életüket védettebbek lesznek a különböző támadási formák ellen. Ezeket az átverésre alapozó technikákat hívják a szaknyelvben social engineeringnek, ez a fogalom a biztonságtudatos rendszergazdák rémálma.
Nagyon jól védett egy rendszer, amiből adatokra lenne szükség? Nem gond, találjunk ki egy hihető sztorit, szerezzünk be hozzá pár olyan adatot, ami hitelessé teszi és kérjük meg azt a felhasználót, aki hozzáfér azokhoz az adatokhoz, hogy segítsen nekünk hozzáférni. Netán fizikailag be lehet jutni az adott felhasználó gépéhez vagy egy trükkel elvonni a figyelmét? Ha a gépe nem zárolt, van 1-2 percünk hozzáférni és célirányosan keresünk meg lehet az az információ. Kicsit sci-fi-nek vagy akciófilmszerűnek tűnhet, de nem az! Ahogyan a legkeresettebb amerikai hacker leírta vele ilyen és ehhez hasonlók számtalanszor megtörténtek, egy alkalommal pedig még egy hihető történettel biankó születési anyakönyvi kivonat nyomtatványokhoz is hozzájutott, amit némi trükközéssel évekig arra tudott használni, hogy új személyazonosságot és iratokat szerezzen. Ma már ezekre a trükkökre mindenhol figyelnek és oktatják a felhasználókat, de még mindig vannak olyanok, amik beválnak és kismillió biztonsági rést nyújtanak felhasználók a támadóknak nap, mint nap anélkül, hogy tudnának róla. A munkám során soha nem tévesztettem meg vagy vertem át valakit, mégis elmondhatom, hogy számos olyan információ szerzést sikerült végrehajtani, ami biztonságtudatos felhasználó mellett nem ment volna. Nem azért, mert rossz célokra akartam felhasználni a kért adatot, hanem vagy a munkámhoz kellett vagy szimplán megkönnyítettem vele egy adott probléma megoldását. De alapvetően amikor megkérdeztem tudtam, hogy erre lehet a válasz egy „hozzáférés megtagadva” is, nem az lett. Nagyon ritkán pattant vissza a kérés, az esetek többségében kérdés nélkül átment. Jártam így kis cégnél, magánembernél, multinál egyaránt. Persze alapvetően a szakmánk alapja a bizalom és igyekszik az ember soha egyetlen pillanatra sem megingatni ezt az ügyfelénél, így talán könnyebb az információszerzés is, mint egy külsős idegennek. Ettől függetlenül nem magától értetődő. Embernél is teljesülnie kellene annak a biztonsági alapelvnek, hogy jogosultsága mindenkinek csak annyi legyen, amit az adott feladat elvégzése igényel. Semmi több. Néha sokkal könnyebb a munkánk, ha nem ütközünk percenként a falba és olykor az ember extra hozzáférést kér. Általában kap is.

Egy másik tipikusan social engineering trükk és egyben életem első ilyen akciója, ami sikerrel is zárult középiskolában történt. Programozás nagydolgozat, néhány perc van már csak hátra és egy bosszantó hibával sikerült hosszasan elakadni. A nagyobb baj az volt, hogy a program egy jó része már készen volt és működött, viszont az utolsó percekben sikerült valahol egy olyan hibát vinni a kódba, amitől az nem fordult le. Ez pedig automatikusan 1-est jelent(ett volna), még akkor is ha valahol csak egy karakter elütés van és amúgy a többi minden jó. Az idő egyre ment, már csak 2 perc volt és szigorúan időre be kellett másolni a kódot. Fél perccel a zárás előtt nem volt mit tenni, fel kellett függesszem a hiba megkeresését, eszembe jutott egy trükk. Minden ilyen programozás feladathoz kiadtak a tanárok egy exe fájlt mintaként. Az exe-t magát soha nem kellett beadni csak a kódot, amit megnyitottak, lefordították és megnézték az eredményét. Gondoltam ha az exe-t is beadom „véletlenül”, persze fájlkezelőben gyorsan átírva a módosítás idejét és a fájl nevét úgy, mintha én csináltam volna, talán örülnek majd neki a sok javítás közepette, hogy valakinek nem kell bajlódni a kódja megnyitásával, exe indít, program letesztel, nyilván a sajátjukat már csak 5-ösre értékelik és minden jó lesz. Sikerült, úgy lett ötös a program, hogy a kódot meg se nézték, mert ha igen látták volna, hogy le sem fordul egy hiba miatt. De nem így lett, a social engineering sikerrel zárult. 🙂

Vannak még tipikus emberi hibákra visszavezethető biztonsági problémák. Nézzük például a jelszavainkat. Sok biztonsági szakember abba a hibába esik, hogy szuper bonyolultságú és összetettségű jelszót ír elő. Persze a számítógép nyelvén jó dolog ez, csak azt elfelejtik, hogy emberek vagyunk és nem gépek, hosszas bonyolult dolgokat nem képes az agyunk megjegyezni. Ez annyira nem vicc, hogy egy alkalommal volt lehetőségem keresés nélkül is rátalálni egy hivatali dolgozó jelszópapírjára, amit a kis parafatáblájára szépen kifüggesztett. A különböző webes hivatali és minisztériumi rendszerekhez, több esetben szigorúan védett adatokhoz biztosítottak hozzáférést. Bár nyilván nem jogosulatlanul kerültem a dolgozó irodájába, de nem kellett volna profi social engineernek lenni, hogy valaki oda jogosulatlanul jusson be. Az eset régebben történt és az új törvényeknek köszönhetően remélhetőleg már nem történnek ilyen felhasználói hibák, de ugyancsak felhívja az eset a figyelmet a leggyengébb láncszem szerepére.

Social engineer

Másik tipikus hiba, amit a hacker legenda leírt, hogy a legjobban védett banki rendszert is ki tudta játszani apró trükkök segítségével. Távolról nem lehetett a rendszerbe férkőzni, így néhány napnyi kutatómunka és egy banki látogatás alkalmával készített pár lopott fotót a banki dolgozókról. Megfigyelte a szokásokat és azt is hogy kártyás beléptetőrendszer van a védett ajtóknál. Elég nagy cégről volt szó, annak is a központjáról több emeleten, nem ismerhet mindenki mindenkit. Legyártotta a kis névkártyát, amit kitűzött Ő is mintha oda tartozna és az épület mögött, az autó parkoló felől odaoldalgott, amikor egy nagyobb csoport dolgozó éppen a cigiszünetet tartotta. Amikor elindultak befelé az egyiknek szorosan a nyomába eredt, az nyitotta neki mágneskártyával az ajtót és mivel nem szokás a mögötted jövőre rácsapni az ajtót még készségesen meg is tartották neki, Ő pedig köszönte szépen. Ezzel bejutott egy védett területre, kártya nélkül. Ennek kivédésére ma már sok helyen forgókaput alkalmaznak, ott nincs ilyen gond, de sok helyen ez egy jó lehetőség a mai napig.

Aztán nagyon gyakori a kapcsolati háló kihasználása is. Feltérképezik ki kivel áll kapcsolatban, ki kit ismerhet és kit nem, de már esetleg hallott róla. Multicégeknél jó trükk egyik-másik részlegre hivatkozni, ahol a részlegek közt nem ismerik egymást, de tudnak egymás létezéséről. Ez mind bizalmat sugároz, és ha egy támadónak sikerül a megtámadottban egy segítőkész személyre lelni rengeteg információt szolgáltathat ki neki. Az is egy tipikus emberi tulajdonság, amikor valaki azzal áll elő neked, hogy egy magasabb rangú valaki, akit Te ismersz, de esetleg nem állsz vele közvetlen napi kapcsolatban, kért egy számodra nem bonyolult dolgot, esetleg olyat ami bizalmas jellegű és nem akarsz rá visszakérdezni, akkor hajlandó vagy kérdések feltevése nélkül is segíteni.
Itt egy ismerőstől származó történet jut eszembe. A Tiszára indultak horgászni, amikor felfedeztek egy nagyon szép partszakaszt. A terület el volt kerítve, de az autó bejárónál a sorompó nem volt lezárva, félre lehetett húzni és bemenni. Valami vízmű területe lehetett talán. Nem olyan rég horgászgattak ott, amikor egyszer csak megjelentek motorcsónakkal a vízirendőrök és közölték, hogy ez bizony magánterület és mit keresnek itt. Egy nyugodt határozottsággal jött a válasz, hogy mi azt tudjuk, de a Pista bácsi engedett be minket és Ő engedte meg, hogy itt horgásszunk. Összenézett a két rendőr, egyik se tudta ki az a Pista bácsi, de ha beengedte őket ide és engedélyt adott biztos valami nagy ember lehet, nem kéne ezt tovább feszegetni, így elköszöntek.

Ezek sajnos mind nagyon emberi hibák és még a tudatos oktatás sem mindig képes őket megelőzni, sokszor ennek ellenére is képesek lehetünk ilyen csapdákba esni. Ráadásul itt még maga az informatika nem is annyira kerül képbe, bár említhetnénk az átverős e-mail-eket is, vagy az adathalász weboldalakat, azok is mind arra vannak, hogy minket megtévesszenek és fontos adatokat adjunk ki általuk. Azokra viszont már vannak IT megoldások, egy bizonyos fokig képesek biztonsági szoftverek megvédeni tőlük.

Mielőtt rátérnék a további biztonságot érintő problémára nézzünk néhány dolgot, amivel a felhasználó tudatosabb lehet az ilyen támadásokkal szemben:

  1. Amikor idegen valami olyet kérdez mindig legyünk gyanakvóak, és fontoljuk meg a választ, hogy mire használhatja fel azt. (Például egy mióta dolgozik itt típusú kérdés egy idegentől is irányulhat adatszerzésre. Lehet például arra kíváncsiak mennyire ismerhetem a kollágákat vagy cég más osztályain dolgozókat. Ha nemrég dolgozok itt nyilván még nem rutinszerűek a védelmi mechanizmusok sem, de lehet könnyebben adok ki infót úgy, hogy valakire hivatkoznak, akit csak név szerint ismerek.)
  2. Ha valakire vagy valakinek az utasítására hivatkozik valaki ne féljünk rákérdezni. Gyorsan kiderülhet, hogy az illető nem is tud róla.
  3. Telefonon történő kérdezgetésre lehetőleg ne adjunk ki semmilyen értékes információt.
  4. Ha kártyás beléptetés van valahol érvényben ügyeljünk rá, hogy a kártyánk ne jusson más kezébe, azt az ajtót pedig amit az nyit-zár húzzuk is be mindig magunk után. Mást lehetőleg ne engedjünk be kártya nélkül, csak ha ismerjük.
  5. A különböző helységekhez, rendszerekhez való hozzáférés jól dokumentált legyen, a kulcsok/kártyák kiadása és tárolása szigorú szabályok szerint történjen.

Az emberek megtévesztését követően térjünk rá a rendszerek megtévesztésére, a biztonsági hibák kihasználására. Természetesen ebből is van szép számmal rossz példa és sok olyan hibát is láttunk már, ami könnyen sikeres hackeléshez vezethet, a továbbiakban ezeket fogjuk áttekinteni.

  • Te Józsi! Képzeld, feltörték a Pentagon számítógépes rendszerét.
  • Ne mondd, és hogyan?
  • Repülővel.
Pentagon repülő
Pentagon repülő

Természetesen katonai objektumot nagyon nehéz feltörni repülő nélkül, éppen ezért ilyen bonyolult rendszerek esetében rendszerint a hackerek social engineering trükkökhöz folyamodnak inkább. Az az egyszerűbb. A másik lehetőség, hogy valami olyan helyet támadnak, ami kevésbé jól őrzött és biztosak benne, hogy ott található kulcs vagy valamilyen hozzáférés a megtámadni kívánt szigorúan védett rendszerhez. Egy Pentagon esetében ilyenkor jön képbe mondjuk a katonai gépeket gyártó Lockheed Martin vagy a Boeing és emiatt is volt óriási szarvashiba Hillary Clintontól például saját otthoni levelezőrendszert használni, mert nem védett rendszer és a segítségével nagyon sok máshoz hozzá tudnak férni hackerek. Jelen esetben a Lockheed vagy a Boeing is a nehezen támadható célpontok közt van, de mondjuk egyik-másik már social engineering módszerekkel megtámadható annyira, hogy sikeresen el lehessen jutni a Pentagonhoz is. Innentől a töréshez már nem kell repülő. Persze ezek csak elméletben hangzanak könnyűnek, a gyakorlatban nagyon nem azok, de a logika így is jól kirajzolódik. Ha az informatikai vonalon indítanak támadást, akkor vélhetően a védelemhez használt eszközöket kezdik el elsőként felderíteni és azok verzióját, aktuális hardver és szoftver revíziót. Ilyenkor kutatnak egy kicsit ismert sérülékenységek után és ha mondjuk valamelyik rendszergazda elfelejtette frissíteni az adott tűzfalat, egy ügyes hacker már el is kezdi kihasználni az ismert hibát. A gyártók ugyan nem szokták publikálni mikor mit foltoznak, de a kiadott programkódokat visszafejtve a profik rájönnek mire nyújt megoldást az adott patch. És meg is van a gyenge pont. Sokszor nem is közvetlenül van rés a pajzson, hanem közvetve, legjobb példa erre amikor mondjuk a legnépszerűbb, jól felépített Cisco tűzfal azon hasal el, hogy a szoftverét Unix alapokra írták. Magának a Unixnak kiderül egy ismert sebezhetősége, ami érinti azt az adott eszközt és azon keresztül máris támadható. Egyébként éppen ez az, ami miatt a Lockheed és a Boeing, illetve a nagyobb hadi gyártók rendszerei nem Unix alapú eszközökkel vannak védve, hanem például a teljesen egyedi operációs rendszert futtató Sonicwall-al vagy éppen Fortinettel. Lehet, hogy ezek rendszere még több hibát rejt, de mivel egyrészt nem hozzáférhető (nem nyílt) a forráskódja, így nem nyitott könyv a támadók számára és hibát is nehezebb benne találni, ráadásul ők még egy olyan trükköt is elkövettek, hogy nem Intel alapú architektúrára építenek, hanem egyedire, így nagyon nehéz lenne bárki számára közvetlen a gyárból hozzájutni olyan hardverhez, amin egyáltalán esélye lenne futtatni az operációs rendszert és keresgélni benne a hibákat. Persze ha sikeresen hozzá tudna jutni a védett forráskódokhoz és a gyárból a szükséges hardverhez.
A tűzfalak lélektanáról egy egész könyv sorozatot lehetne írni, ezt én most nem teszem meg, a lényeg nagyon sok fajtája van, vannak köztük jók és rosszak, biztonságosak és kevésbé biztonságosak. De tudni kell őket jól beállítani, márpedig ha az nincs meg, akkor a legjobb eszköz is lehet kész átjáróház.

A következő cikkben elmeséljük majd egyik ügyfelünk majdnem teljes adatvesztését, hogyan hackelték meg és kapott zsarolóvírust, ennek kapcsán lesz még szó tűzfalakról és ezt követően mutatunk majd egy olyan tűzfalmegoldást, ami nagyban megnöveli a rendszerünk biztonságát és mindeközben bárki számára elérhető potom összegből, sok mindenben mégis felveszi a versenyt a sok milliós brand megoldásokkal.

Facebook