Először is tisztázzuk, hogy ki is az etikus hacker, és mi az amit csinál? Nem meglepően két dolgonak kell teljesülnie: hacker legyen, és etikus. Hacker alatt azt értem, hogy értse annyira a szakmát, hogy nem youtube videókból képes egyszerű dolgokra (scriptkiddie), hanem tudja és látja is hogy mi történik a háttérben, így képes saját támadási módok kitalálására és kivitelezésére.
A múltkor BKK ügy kapcsán pedig hiába is szajkózza a sajtó, hogy szegény „etikus hacker” srácot meghurcolják, az a helyzet, hogy a fiatal nem igazán volt etikus. Egy etikus hacker felkérésre dolgozik, és főként nem rohan egy órán belül a sajtóhoz publikálni a feltárt hibákat. Ezzel szemben ezeket (megoldási javaslattal együtt) a megbízó felé juttatja csak el. Aztán majd ha a rést befoltozták, akkor talán lehet publikálni a hibát.
Mikor érdemes felkérni egy etikus hackert?
Ha a fejlesztést más végezte, és nincs a kezedben egy etikus hacker jegyzőkönyve, vagy ha fejlesztő cég vagy. Ez utóbbi esetben kétféle lehetőséged van:
- A már elkészült rendszer auditjára, etikus hackelésére kérsz fel egy szakembert. Így az Ő általa feltárt hibákat javíthatod, még mielőtt az ügyfélhez kerülne a rendszer. Persze megértem, nem minden fejlesztő cégnek fér bele a budgetbe az ethical hacking – ugyanakkor a megrendelőnél / érdeklődőknél bizonyára jó pont, ha látják, Te ennyire odafigyelesz a biztonságra.
- Folyamatos megbízással dolgozol együtt egy etikus hackerrel. Így a hosszabb fejlesztések során az egész fejlesztési folyamat auditálva van. Nem egyszerre kell egy hatalmas rendszert auditálni, hanem lehet folyamatosan is, amíg a fejlesztés tart.
Hogyan dolgozik?
Az etikus hackerek élete nem csak játék és móka. Egy-egy audit során a rendszer feltérképezése, a belépési pontok azonosítása, paraméterek felkutatása, stb. gyakran kétszer annyi időt vesz el, mint az aktív rész, amikor valóban a töréssel próbálkozik az ember. A sztereotípiákkal nem nagyon kell foglalkozni, képesek vagyunk nap közben is dolgozni, és éjszaka úgyanúgy szeretünk aludni, ahogy minden más ember.
Persze van olykor olyan megbízás, hogy vagy éjszaka célszerű tesztelni, mikor minimális a forgalom az adott felületen, vagy az ember épp rábukkan valami nyomra aminek hatására éjjel háromig ül a gép előtt, és próbálja minél ügyesebben meghackelni az adott rendszert.
Persze a hackelés nem ad-hoc jellegű. Minden egyes teszt után bővül valamivel a jegyzőkönyv. Ha elkészült minden, akkor juttatjuk el a jegyzőkönyvet a megbízó számára, segítséget is nyújtva a hibák javításához.
Mennyi ideig tart a vizsgálat?
Ez nagyban függ a rendszer komplexitásától, és felhasznált technológiától. Egy egyszerű űrlap vizsgálata eltarthat néhány perctől akár néhány óráig is. Nem célszerű pár perc után feladni, hogy „ááá, ez biztonságosnak tűnik”. Nem egyszer tártam fel már olyan sérülékenységet, ahol valami spéci dolgot kellett művelni az egyébként jónak tűnő védelem megkerülésére.
Viszonyításképpen elmondanám, hogy jómagam egy kb 100 pontból álló checklistát használok az auditok során. Ennek a checklistának a nagyrészén végig kell menni nem hogy minden űrlap, de sokszor minden beviteli mező, minden paraméter esetében. Ha valami jól működik az egyik űrlapon, az még nem garancia arra, hogy a másikon is jól fog működni.
Ökölszabályként azt szoktam mondani, hogy egy webalkalmazás (sok beviteli mezővel) etikus hackelése kb 3 hetet vesz igénybe. Szóval nem arról szól a dolog, hogy csak végigkattingatjuk az oldalakat.
Minden hibát ki lehet szűrni?
Szeretnénk elhinni, hogy minden hibát ki lehet szűrni, de az igazság az, hogy 100%-os biztonság nincs. Lehet hogy most éppen nem tartalmaz semmiféle hibát a rendszer (mai tudás alapján), de ha holnapután kiderül, hogy van egy biztonsági rés mondjuk a webszerverben, akkor hiába is lenne 100%-os biztonságú a webalkalmazás. A rendszer mindig annyira biztonságos, mint a leggyengébb láncszem.
A másik gyengítő tényező, hogy viszonylag ritka az white-box vizsgálat. Ez az a típus, amikor a szoftver forráskódját is megkapja a hacker, és azt is átnézheti. Itt fény derülhet olyan hibákra is, ami black- vagy graybox teszt esetében nem tűnne fel.
A lényeg azonban az, hogy a támadók dolgát minél inkább megnehezítsük. Ha túl sok energiába kerülne feltörni a rendszert, lehet hogy nem nyúlnak hozzá. Minél magasabb a biztonság szintje, annál kevesebb rosszindulatú hacker fogja tudni kihasználni a rendszerben még esetleg meglévő hibákat. Erre nagyon jó példa a BKK. A 18 éves srác talált pár sérülékenységet: SQLi, titkosítatlan jelszókezelés, 50 forintos jegyvásárlás. Az a helyzet, hogy ezek a hibák annyira alapvetőek, hogy szinte bárki ki tudja használni őket. Ha lett volna egy alapvető etikus hackelés a rendszeren, ahol egy frissen végzett etikus hacker végignyomkodja a rendszert, ezeket a hibákat garantáltan ki lehetett volna szűrni. (ezek egyébként annyira gyakori hibák, hogy az OWASP TOP 10-ben folyamatosan benne vannak). Ha ezeket a hibákat kiszűrték volna, az egész ügyet megúszhatták volna. Gyanítom ugyanis, hogy az „etikus hacker” a SSL kapcsolat gyengeségeit már nem tudta volna kihasználni.
Elég drága, megéri?
Drága? Mihez képest? Alapvetően sikerdíjas konstrukcióban dolgozom, így nem kell attól félned, hogy semmit nem kapsz a pénzedért. Legrosszabb esetben is valószínűleg töredékét fizeted ki annak, mint amennyiért a weboldaladat elkészíttetted / eladtad. Ugyanakkor nem szabad megfeledkezni a következőkről:
- Immár csaknem 5 éve végzek etikus hackelést webes rendszereken. Eddig nem volt olyan rendszer a kezeim között, amiben ne lett volna valami ordító probléma.
- Egy ilyen BKK-s balhét a T-Systems valószínűleg túl fog élni. De egy KKV szektorban tevékenykedő vállalkozás közel sem biztos hogy fel tud állni a padlóról egy ilyen pofon után.
És akkor még nem esett szó róla, hogy a jövőre életbelépő szabályozás miatt is célszerű lesz minél biztonságosabbá tenni a rendszereket…