Védd a rendszert, ne siránkozz!

2014. március 28. 13:23 - Csizmazia Darab István [Rambo]

Igen tanulságos előadást láthattunk arról, hogy az elvégzett etikus hackelési projektek után hogyan látják belülről a szakemberek a jelenlegi helyzetet. Nem az a kérdés, hogy sikerül-e bejutni, vagy a rendszert feltörni - erre általában igen a válasz - hanem sokkal inkább a milyen könnyen és milyen rövid idő alatt az érdekes, illetve az is kulcs fontosságú, hogy mennyire fogadják meg az ügyfelek az ilyenkor kapott tanácsokat.

Ezekről, a legjellemzőbb  tapasztalatokról, gyakran észlelt problémákról, és hiányosságokról kaphattunk sok érdekes, részletes és praktikus háttérinfomációt. Amikor például a sok jelszó feltörésről, vírusos, botnetes fertőzésekről, nagy cégek szervereinek kompromittálásáról olvasunk, hajlamosak vagyunk azt hinni, minden egyes támadás mögött egy zseniális gonosz áll.

Természetesen a támadók alapos tudása sok esetben valóban nem kérdőjelezhető meg, ám óriási arányban maguk a felhasználók, rendszergazdák, adatgazda felelősök is megkönnyítik a behatolók dolgát. Nem mindegy, hogy mennyire van megnehezítve a támadó feladata, percek alatt könnyedén hozzáférhet bármihez vagy számos akadályt állítanak az útjába. Szem előtt tartva azt, hogy 100 százalékos biztonság persze nem létezik, azért hogy a biztonsági kockázatot, a védelem mértékét 40%-ról 85-re emeljük, annak a Silent Signal szakemberei szerint igenis volna értelme.

Ehhez például olyan dolgok kellenének, mint a hosszú és erős jelszavak megkövetelése és használata, a jelszavak és egyéb információk titkosítása, a kényes mentések másolatai ne heverjenek szanaszét a szervereken, ahogy a főkönyvtárban tárolt, és plain textben olvasható jelszo.txt, konfig backup vagy SQL adatbázis dump állományok is nagyságrendekkel megkönnyíthetik egy támadó dolgát. Ugyanezek elmondhatók a jogosultságok kiosztásánál, ACL beállításoknál, vagy szerverek frissítéseinek elhanyagolásánál. A kártevők és a támadók is ma már iparszerűen használják ki a sérülékeny szoftverek hibáit.

Természetesen lenne tanulsága mindennek nem csak a biztonsági szakmának, hanem a szolgáltatást igénybe vevőknek is. Érdemes az ilyen biztonsági projektet előre megtervezni, alaposan tájékozódni, hogyan zajlik egy etikus hackelési vizsgálat (meg tudnátok nézni most pénteken gyorsan éjjel 2 és 3 között), és tudni, pontosan mit is akarnak kérni.

A megrendelőnek emellett illene pontosan ismernie a saját infrastruktúrát (ja nem is 30, hanem 50 szerver), és megfelelő belső kapcsolattartókat kell hozzá kijelölni, hiszen nem a vizsgálat szimpla kipipálása a cél.

A komolyan vehető etikus hacker csapatok ugyanis nem egy csupasz automatikusan lefuttatott Nessus listát csapnak le az asztalra Mekk Elek módjára, hanem egyrészt valóban leleményesen, és hacker fejjel gondolkodva az összes gyenge pontot igyekeznek alaposan felderíteni - ezt semmilyen gép vagy program nem végzi el automatikusan, hanem rettentő sok tanulás és tapasztalat vezethet el csak ide.

Másrészt pedig a végeredmény mellé részletes megoldási javaslatokat is tesznek. Itt még az sem lehet akadály, ha véletlenül egy 0-day sebezhetőség felfedezése okozná a problémát, hiszen technikailag ilyenkor is lehet megfelelő védekezési módszert, vagy workaroundot alkalmazni.

Itt lép be a képbe az, hogy a tapasztalatok szerint sok ügyfél a javítási javaslatokat egyszerűen ignorálja, és "soha napján" történik meg a javítás, pedig belső felelősök és megfelelő határidők kijelölése lenne az optimális. Itt az ismételt visszaellenőrzési folyamatok is jól mutathatják, hogyan változik meg vagy éppen marad a régiben a korábbi sérülékeny állapot.

Utalva arra, hogy 100 százalékos védelem valóban nem létezik, valójában nem az az igazán szomorú, ha egy rendszer sebezhető, vagy törhető, hiszen elengedő munkával mindig mindenhol lehet hibát találni. Sokkal inkább szánalmas viszont az, ha valaki megkapja ugyan erről a jelzést, jelentést, ám ennek ellenére mégsem tesz ellene semmit.

A technikai trükkök természetesen nem merülnek ki pusztán a számítógépek tesztelésében, hanem például képbe kerülhet a beléptető rendszer gyengesége is. Ha például napokig észre sem veszik, ha egy vendégkártyát nem vittünk vissza, az nem utal túl alapos és szigorú rendszerre, de adott esetben az RFID kártya másolása, klónozása is eredményre vezethet egy felkészült támadó esetében - ezt egy pár perces mellék helység látogatáskor is el tudja végezni a megfelelő eszközökkel.

Emellett egy külön fejezet a technikai dolgok mellett a social engineering rész is, amikor ha egy illetéktelen úgy juthat be könnyedén, hogy közben még teával is megkínálják, éles banki terminálokhoz férhet hozzá vagy észrevétlenül felcuppanthat a hálózati rackbe egy Raspberryt.

És persze ott van az eszköztárban az elmaradhatatlan hamis telefonálgatás a rendszergazda nevében a jelszó után érdeklődve, a kíváncsi alkalmazottaknak szándékosan elszórt USB kulcsok a munkahely területén, vagy a célzottan a dolgozóknak küldött "nyereményjátékos" e-mailes APT támadás, amin a munkahelyi jelszó begépelésével lehet részt venni. A tapasztalatok szerint több-kevesebb ember minden esetben bedől ezeknek a trükköknek. Ilyenkor ezek tanulságait is le kell vonni, és a védelmi szolgálat, valamint a dolgozók rendszeres biztonságtudatossági képzésében ezekre külön ki kell térni.

Végül arról is hallhattunk pár keresetlen szót, mire számítson az a hibavadász, aki 0-day sebezhetőségek felfedezésből és beküldéséből szeretne megélni. A tapasztalatok szerint itt sem csak Grál lovagok kereskednek ezekkel, így simán megtörténhet, hogy a megfelelően és alaposan dokumentált jelzésre mégis nemet mondanak, közben az el nem fogadott jelentésnek viszont ellopják tartalmát, vagy például csak minden tizedik bejelentőnek fizetnek a látszat kedvéért.

Mindenesetre egy érdekes és színes körképet kaphatott az etikus hackeléssel kapcsolatos világ aktuális kérdéseiről, aki részt vett ezen a szerda esti rendezvényen.

Szólj hozzá!

A bejegyzés trackback címe:

https://antivirus.blog.hu/api/trackback/id/tr605883099

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.