A kérdés csupán az, hogy az idő előrehaladtával, az informatika rohamos fejlődésével miért nem oldódik meg végre ez az aprócska probléma? Miért nem múlnak el a biztonsági rések? Miért van az, hogy ezekkel a képzésekkel immár „legalizáljuk”, hogy minden informatikai rendszer garantáltan sebezhető?
Pedig egyszer már úgy tűnt, leáldozott a hekkerkedésnek. A 2000-es évek közepére nagyon megritkultak a korábban sűrűn előforduló weblapmódosítási és egyéb támadások. A pillanatnyi lankadásnak megvolt a maga oka: az ezredfordulótól kezdődően a legbanálisabb, legprimitívebb biztonsági réseket már befoltozták a szoftvercégek, nemigen maradt alacsonyan lógó gyümölcs, amit amatőrként, nulla felkészültséggel le lehetett volna szedni. (Ez persze nem teljesen igaz, hisz ma is sok vállalati hálózatról fürtökben lóg az érett gyümölcs, a feltörés melegágyát nyújtó biztonsági rés, csoda, hogy össze nem rogynak alatta/miatta.)
2006-2007-től azonban ismét meglódult a biztonsági támadások száma, a statisztikai diagram felfelé görbült, de sajnos a jópofa amatőrök helyét átvették a profitorientált bűnszövetkezetek, melyek képzett programozók hadseregeit tudják bevetni egy-egy új biztonsági rés megtalálásába és kihasználásába. 2010 trendforduló: ebben az évben a szervezett bűnözés nagyobb bevételre tett szert informatikai bűnözésből, mint kábítószer-kereskedelemből. (Forrás: Verizon Data Breach Report 2010 )
De ez még nem válasz az eredeti kérdésre, hogy miért vannak még mindig kihasználható biztonsági rések a kereskedelmi szoftverekben? És meddig lesz ez így?
Elsőként hadd válaszoljam meg, hogy miért van tele minden szoftver hibával. Ennek egyszerű oka van: a komplexitás. Szoftvereink egyre összetettebbé, bonyolultabbakká válnak, rejtett, senki által nem követett függőségek alakulna ki bennük.
Ha „A” helyen módosítom, „B” helyen összedől – ezt mindenki tudja, aki egy picit is foglalkozott szoftverfejlesztéssel. Ilyen viszonyok között azonban nincs más módszerünk egy program helyességének „bizonyítására”, mint a teszt, a próba. Ez azonban nem bizonyítás, hanem próbálgatás. És még ha valami át is jut az összes ellenőrzőteszten, bétatesztelőn és early adopteren, akkor sem igaz, hogy hibátlan. Csak egy dologban lehetünk biztosak, hogy az általunk kifundált teszteken nem bukott el a program.
Azonban a rosszindulatú támadók majd olyan „teszteknek” vetik alá az alkalmazást, amire a gyártó soha életében nem gondolt, és fogalma sincs, hogy ilyen határhelyzetekben hogyan viselkedik majd a kód. Gondoljunk itt a fuzzingra (~összezavarás), amely „teszt” során a hacker szándékosan hibás bemeneti adatokkal tömi meg a program minden bemeneti nyílását (fájl, tcp-csatorna, url, adatbeviteli űrlap, e-mail stb.), és azt vizsgálja, hogy a tesztelt alkalmazás összedől-e. Ha igen, már lehet is továbbmenni, és az összeomlás romjain kifejleszteni azt a kódot (exploit), ami a világban futó további százmillió ugyanilyen alkalmazásán át tudja venni az uralmat a gép felett.
Ennyi a recept, így kell új és még újabb, senki által korábban nem ismert, a szoftver gyártójának is totális meglepetést okozó nulladik napi (zero day) sebezhetőséget találni. Hát így állunk. És meddig lesz ez így? A jelenlegi szoftvertechnológia mellett „örökké”, de legalábbis addig biztosan, amíg a próbálgatás helyett a szoftverminőség-ellenőrzésben más módszereket ki nem találnak.
Aki tehát ma etikus hekkernek tanul, egy robbanásszerűen fejlődő iparág egyik korai képviselőjévé válik, és mint ilyen, nagyon kapós lesz a munkaerőpiacon, mert ma már minden nagyvállalatnál felismerték, hogy az etikus hekker által végzett biztonsági ellenőrzés alternatívája – a meghekkelés.
