A minap, ahogy régi dokumentumok között kotorásztam, ráleltem az első általam végzett „rendes” biztonsági vizsgálat jegyzőkönyvére. A történethez hozzá tartozik, hogy ezt a vizsgálatot teljesen ingyen végeztem egy ügyfelemnek – egyrészt még CEH minősítéssel sem rendelkeztem – más részről pedig voltak kétségeim afelől, hogy képes vagyok-e egy több ezer taggal rendelkező site feltörésére.
Főként akkor bizonytalanodtam el, mikor az oldal tulajdonosa (egy üzleti oldalról beszélünk) olyan stílusban mondta, hogy “persze, nézz rá!”, mintha a letapasztott szemüveges Pistike fejét simogatná: jól van hülyegyerek, próbálkozz csak, nálunk nem mész sokra… A félelmet elég gyorsan sikerült motivációvá konvertálnom: be akartam bizonyítani, hogy valóban jó vagyok – és egyúttal vissza akartam vágni a valós- vagy vélt sérelemért.
Megkötöttük a szerződést, majd elérkezett a támadási kísérletek napja. Este 9 óra körül kezdtem a vizsgálatokat. A feltérképezés során nagyjából egy órát vett igénybe, hogy kiderüljön: milyen rendszerre (és milyen verzióra) építették az oldalt, és ennek a rendszernek milyen ismert hibái léteznek (ez ma már 15 perc alatt megy). Összesen 7 hibalehetőséget sikerült feltárni, de ezeket bizonyítani nem tudtam. Valószínűleg ezeket a hibákat már korábban javították. Pech – mentem tovább a webes alkalmazásra, végülis már akkor erre akartam specializálódni.
Az oldalon volt ingyenes regisztrációs lehetőség – ingyen regisztrációval korlátozottan lehet csak elérni a funkciókat. Ahhoz azonban volt jogosultság, hogy egy bizonyos adatlapot (a sajátomat) szerkeszthessem. Rögtön feltűnt, hogy az az URL-végén szerepelt egy id=xxxxx (xxxxx helyére képzelj el egy tetszőleges számot) paraméter. Ha ilyet lát a hacker, az első dolga, hogy megpróbálja átírni. És ahogy anno a Szabadalmi Hivatal esetében, vagy a Citibanknál – úgy itt is működött ez a kis trükk. Vígan szerkeszthettem más felhasználók dolgait – beleértve azokét is, akik tetemes összeget fizettek ki a tagságért.
Amikor a hacker ilyen jellegű hibát talál, rögtön vérszemet kap. Ha ilyen egyszerűen kompromittálható a rendszer, akkor micsoda csemegéket rejthet még?
Nem sokkal később találtam XSS sérülékenységet is. Ez gyakorlatilag arról szól, hogy a látogató olyan műveleteket tud végrehajtani, ami az oldalt rosszindulatú működésre veszi rá. A webfejlesztők sokszor nem foglalkoznak az XSS-sel, nem értik hogy miért lehetne belőle probléma!?
Nos, jelen esetben az XSS kihasználásával fél óra alatt több olyan felhasználói belépést sikerült elcsípni, akik fizetős tagok voltak. Egy egyszerű böngészőkiegészítővel elérhető volt, hogy bármelyikük nevében belépjek a rendszerbe. Ha hagytam volna pár napig élni a rosszindulatú kódot, könnyűszerrel szerezhettem volna adminisztrátori jogokat is.
Erre azonban nem volt szükség – mert közben találtam még egy hibát a rendszerben. Az újabb hibát kihasználva, akár bejelentkezés nélkül is képes voltam fájlokat feltölteni a weboldalra. Ha pedig a támadó képes bármit feltölteni a szerverre, akkor ott vége a dalnak.
Sakk-Matt. Itt akár meg is állhattam volna. De a kíváncsiság nagy úr – minek szereztem teljes hozzáférést – még a forráskódhoz is – ha nem nézek kicsit körül? Pár másodperc múlva már a notebookomon volt a site teljes adatbázisa. Több ezer céges adattal, elérhetőségekkel, és…….. khmmm… jelszavakkal.
Programozók, webfejlesztők, az ég szerelmére! Soha, semmilyen körülmények között ne tároljatok jelszavakat tiktosítatlanul – még adatbázisban sem! Ezzel nem csak a saját rendszereteknél hozzátok kellemetlen helyzetbe a felhasználóitokat! A többség – sajnos – ugyanazt a jelszót használja sok-sok helyen. Akár levelezésnél, vagy PayPal-nál, vagy banki felületeken, vagy akárhol…
A vizsgálat során még 2-3 súlyos hibát sikerült feltárni, éjjel kettőre már készen állt a több oldalas jelentés a feltárt hibákról – és a javítási lehetőségekről.
Piros pontot érdemel a megbízó: a feltárt hiányosságokon nem megsértődött, hanem azonnal hívta a programozót, és kijavíttatta a hibákat. pár nappal később már újra lehetett ellenőrizni az oldalt – a hibák pedig egytől-egyig javítva lettek.
Ezzel az ingyenes tesztvizsgálattal mindenki nyert: a megbízó sokkal biztonságosabbá tehette az oldalát, én pedig megerősítést kaptam, hogy érdemes foglalkoznom az IT biztonsággal.
Nekem is volt olyan weboldalhoz szerencsém fejlesztőként, ahol plain text-ben voltak tárolva a jelszavak. Az SQL Injection-t nem tudták rendesen kiküszöbölni, ugyanúgy XSS sebezhetőség volt képben, miegymás. A megrendelő viszont nem értette, miért kell az egész oldalt átírni, hiszen működik.
Az egyik jelenlegi projektemben kikötöttem, hogy már a frontenden az első lépéstől fogva hashelve legyenek a jelszavak. A https-en túl még egy körös titkosítás van. Sajnos minden szakmában sok a kókler és ez az eredménye.