Webalkalmazások biztonsági tesztelése 2

csirkeMiután megismerkedtünk az alapelvekkel egy oldal feltörésénél az első dolgunk az alkalmazás feltérképezése lesz. A feltérképezés során tulajdonképpen a megtámadható felületeket keressük meg. Két fő dolgunk lesz ennek során. Először is megismerkedünk az alkalmazással és megpróbáljuk a lehető legtöbb háttér információt összeszedni róla, majd második lépésként feltérképezzük a támadási felületeket.

Háttérinformációk gyűjtése

Egy sikeres támadás (illetve biztonsági tesztelés) véghezviteléhez először meg kell ismernünk az alkalmazást. Ennek kettő fő módszere létezik. Az első amikor kézzel végigkattintgatjuk az elérhető linkeket és figyelünk a megjelenített tartalomra és funkciókra. A feltérképezés során folyamatosan figyelnünk kell az url paramétereket, a cookie-kat, az elpostolt paramétereket és a http fejléceket.
A második módszer automatizálja a végigkattintgatós módszert valamilyen spidering eszköz segítségével. Ezek közül a legnépszerűbbek a paros, a burp, a webscarab, a webhttrack. Általában itt valamilyen proxy-n folyatjuk keresztül az adatkommunikációt, hogy naplózni lehessen, vagy egy az egyben tükrözzük a saját gépünkre az alkalmazást.
A magam részéről a kézi felderítés híve vagyok addig amíg nem lesz egy általános benyomásom arról, hogy hogyan is épül fel, hogyan működik az alkalmazás. Ha ez megvan és valami konkrét dolog után kutatok, akkor jöhetnek a spiderek és a logokban való keresgélés.

Rejtett tartalmak felderítése

A robots.txt file arra való, hogy segítségével kitiltsuk bizonyos könyvtárakból a keresőrobotokat. Kis szerencsével egy egyszerű http://akarmi.hu/robots.txt meghívással már a kezünkben is egy lista arról, hogy az alkalmazás mely részeit kívánták eldugni.

Keresgélhetünk kézzel vagy a fenti eszközök egyikével olyan könyvtárak, elérési utak után amelyek általában elrejtésre kerülnek. Ilyenek a /admin, /admins, /user, /users, /phpmyadmin, /mail, /servlet, /cgi-bin, /cfdocs, /rails, /accounts, /admin.php, /admin.asp, /src, /inc, /include, /old, /txt, stb. Ha keresgélésünk automatizált akkor figyelembe kell vennünk, hogy a 200-as header valóban sikert jelent.

Ismert filenevek és / vagy funkciók ismeretében tippelhetünk elrejtett tartalmakra. Például ha van egy AddPost.php és ViewPost.php akkor elképzelhető, hogy lesz DelPost.php vagy éppen AddUser.php is. Hasonlóan ha az url-ben megjelenik valami ilyesmi: index.php?m=post&act=add akkor érdemes tenni egy próbát az index.php?m=user&act=add paraméterekkel is.

Bepróbálkozhatunk általánosan használt paraméterekkel melyek használatával esetleg beszédesebb oldalakat kapunk. Ilyenek a debug, test, source, admin, edit = true, yes, on, 1.

Ezeken túl a keresők tárolt változatai tartalmazhatnak rejtett, vagy már nem használt részeket. A régi verziók, már nem frissített, a szerveren felejtett programrészek igen hasznosak lehetnek majd a későbbiekben.
A keresőket használhatjuk direkt felderítésre is, például ha szeretnénk tudni, hogy az adott céloldalon mi van beindexelve amiben szerepel az admin szó akkor egy admin site:celoldal.hu egyből a segítségünkre siet. A kihagyott találatok megjelenítésével további információkkal gazdagodhatunk.

További háttérinformációk begyűjtése

Nézzük meg a html kódot. Sok esetben a kommentekben ott lapul sok sok hasznos információ. Hivatkozások egyébként elrejtett fájlokra vagy funkciókra, debug információk, sőt sokszor sql lekérdezések.

Ha az oldal hívogat valamit ajaxxal akkor érdemes ránéznünk, hogy milyen válaszokat kapunk ugyanazokon az urleken amennyiben simán böngészőből hívjuk meg őket.

Szenteljünk a kigyűjtés során különös figyelmet az általában könnyen támadható paraméterekre mint a template=new.tpl, dir=../akarmi és hasonlók.

A webszerver feltérképezése

Nézzük meg a szerver válaszaként kiküldött http headert. Ebből megtudhatjuk általában a használt webszerver nevét és verzióját, a használt modulokat. Ennek ismeretében keresgélhetünk ismert biztonsági rések után.
Ebben a munkánkban segíthet a httprint vagy éppen a nikto.

A fájlok kiterjesztéséből többnyire kiderül a szerver oldalon használt scriptnyelv: asp, aspx, jsp, cfm, php, d2w, pl, py.

Input lehetőségek begyűjtése

A térképünkre fel kell vezetnünk minden oldalt ami elfogad url paramétereket, postot, cookiet, vagy http header-ből jövő adatokat mint a referer, a user-agent vagy más szóba jöhető header.

Próbáljunk ezeknek direkt “rossz” adatokat adni és figyeljük a hiba üzenteket. A hibaüzenetek hajlamosak a kelleténél több információt adni, hogy megkönnyítsék a fejlesztők betörők munkáját.

Támadási felület térkép

Az eddigiek alapján meglehetősen sok információnak leszünk már a birtokában. Nem javaslom, hogy ezekből kiszűrjünk bármit is, hogy nem érdemes tesztelni mert úgysem megyünk vele semmire, sem azt, hogy egyből nekiessünk valamelyik vonzónak vélt célnak. E helyett állítsuk össze a támadási felületek térképét. A támadási felületek feltérképezéséhez az eddig begyűjtött információkhoz hozzárendeljük az egyes helyeken használható támadási módszereket. A következő pontokat kell összegyűjtenünk.

Kliens oldali ellenőrzések (javascript vagy html)
Amennyiben a kliens oldalon az alkalmazás rendelkezik valamilyen adat ellenőrző funkcióval, mint egy javascriptes függvény ami ellenőrzi, hogy például egy megadott e-mail cím megfelelő formátumú-e, vagy a html inputok maxlength tulajdonsága meg van adva, akkor ezeket a helyeket meg kell jelölnünk a térképen, hogy majd leteszteljük, hogy a szerver oldalon is végrehajtja-e az alkalmazás ezeket a teszteket vagy sem. Ha nem, akkor jó eséllyel a kliens oldali ellenőrzések megkerülésével fogunk találni valami megtámadható funkciót.
Adatbázis kommunikáció
A legtöbb oldalunk valószínűleg fog egy adatbázissal kommunikálni. Ezeken a helyeken fogunk majd SQL beoltásokkal próbálkozni.
Fájlok le és feltöltése
Itt az elérési utak átjárásával (path traversal) fogunk próbálkozni.
A user által bevitt adatok megjelenítése
Fő példája a keresés, de sok-sok más formája is van. Ezek a területek lesznek az XSS támadások fő célpontjai.
Dinamikus átirányítások
Itt kapjuk majd elő az átirányítási és header beoltási fegyvereinket.
Bejelentkezés
Usernév és jelszó tippelés, és brute force támadás.
Session kezelés
Megjósolható session azonosítók keresése, vagy session azonosító fixálás.
Hozzáférések kezelése
Itt próbálunk majd a saját jogunkon felüli jogosultságokat szerezni a többi módszer használatával.
User megszemélyesítő metódusok
Admin userek megszemélyesítése
Sima szöveges kommunikáció
Amennyiben le tudjuk hallgatni a szerver és a kliens közötti kommunikációt itt bármilyen adatot el tudunk kapni beleértve jelszavakat, és más érzékeny adatokat.
Hibaüzenetek
Sok esetben a hibaüzeneteket megjelenítő oldalak könnyebb támadási célpontok mint mások.
E-mail funkciók
Beoltások, spam.
Harmadik féltől származó alkatrészek
Ismert hibák kihasználása
Web szerver szoftver
Ismert hibák kihasználása, általános konfigurációs beállítások kihasználása

Ha a kezünkben van a támadási felületek térképe, akkor a következő részekben ismertetett támadásokat indíthatjuk meg.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.