web02.qxd
1/17/2007
10:57 AM
Page 13
2
fejezet
Információk összegyûjtése a célpontról A fejezet tartalma Ebben a fejezetben három olyan támadási módszert mutatunk be, amelyek arra irányulnak, hogy a támadó információt gyûjtsön a webalkalmazásról. Bármilyen biztonsági tesztelés, amit a webalkalmazáson végzünk, elõször ezekre a területekre kell, hogy összpontosítson, mert a késõbbi fejezetekben bemutatott támadások közül jónéhány az információgyûjtésen alapul.
Bevezetés A hadvezérek jelentõs idõt áldoznak arra, hogy kikémleljék az ellenség szándékait, és információt gyûtsenek róla, mert így tudnak döntést hozni arról, hogy a támadóerejüket hogyan lehet a leghatékonyabban felhasználni. A szoftvertesztelésre ugyanez érvényes, hiszen a támadások természetüket tekintve itt is arra irányulnak, hogy a hibák kihasználása révén legyûrjék az „ellenséget” (a szoftvert).1 Minél több információt gyûjt össze a támadó a célpontról (ebben az esetben az adott webalkalmazásról), annál könnyebben képes kiválasztani a megfelelõ támadástípust és eszközöket, illetve megvédeni saját „csapatait”. 1 A szoftvertesztelés célja, hogy megtaláljuk a hibákat, illetve ellenõrizzük a hibamentes mûködést. A hibakeresõ tesztek jó tesztek, hiszen lehetõvé teszik, hogy csökkentsük a megbúvó hibák számát. A hibákat nem keresõ tesztekkel sincs semmi baj, hiszen ezek arra szolgáltatnak bizonyítékot, hogy a program az elvártaknak megfelelõen viselkedik. Arról azonban gondoskodnunk kell, hogy az utóbbi típusba tartozó tesztek kellõen hatékonyak legyenek. Ha ugyanazt a dolgot ellenõrizzük újra meg újra, a mûködésérõl kétségtelenül meggyõzõdhetünk, de nem jutunk egyrõl a kettõre. A könyv olyan tesztelési eljárásokat ismertet, amelyek mindkét célnak megfelelnek.
web02.qxd
1/17/2007
14
10:57 AM
Page 14
Hogyan törjünk fel webhelyeket A webes tesztelés sem más, eltekintve attól, hogy a webalkalmazások ritkán képesek visszavágni. Annyi információt kell összegyûjtenünk az alkalmazásról és annak megvalósításáról, hogy hatékonyan megvédhessük a támadástól. Az ebben a fejezetben bemutatott támadásfajták mind azt célozzák, hogy megfelelõ mennyiségû információt gyûjtsünk össze az alkalmazásról.
1. támadás: Aranymosás Bizonyára láttunk már olyan westernfilmet, amelyben egy öreg, fogatlan szerencsevadász aranyat mos a folyóban: megragad egy marék homokot, és ide-oda lökdösi a szitában, reménykedve, hogy õ lesz az elsõ, aki aranyrögöt talál. A következõkben bemutatandó támadásfajta is ilyen: látszólag idõpocsékolásnak tûnik, de csak akkor az, ha a támadó nem a megfelelõ folyóban próbálkozik, és ott keres hosszasan aranyat, ahol csak kavicsot és homokot találhat. Ahhoz, hogy megtaláljuk az aranyrögöt egy webalkalmazásban, tudnunk kell, hol keressük. Ha viszont ismerjük a helyet, a jutalom busás lehet. A webtesztelésnél könnyen azonosítható, hogy mi az, amit a szitába kell helyeznünk: az alább bemutatott eljárás lényege a szûrés módja.
Mikor alkalmazzuk ezt a támadást? Minden tesztelési stratégia fontos része, hogy annyi információt gyûjtsünk össze, amenynyit csak lehet. Ezért ez az elsõ támadás, amelyre gondolnunk kell webteszteléskor. Általános szabályként elmondhatjuk, hogy célszerû szakaszosan tesztelni, mert bár ad hoc teszteléssel is találhatunk hibákat, könnyû elsiklani valami fontos felett. Ezt a támadási tesztet a következõ négy környezetben lényeges alkalmazni: • • • •
HTML forráskódba beágyazott megjegyzések HTML forráskódban elhelyezett érzékeny adatok Kiszolgálóoldali hibaüzenetek és HTTP-válaszok Az alkalmazás hibaüzenetei
Az elsõ kettõhöz át kell néznünk az alkalmazás forráskódját, olyan információkat keresve, amelyek a támadót segíthetik. A második kettõhöz az szükséges, hogy hibás bemenettel lássuk el az alkalmazást, majd alaposan elemezzük a megjelenõ hibaüzeneteket.
web02.qxd
1/17/2007
10:57 AM
Page 15
2. fejezet • Információk összegyûjtése a célpontról A támadók mind a forráskódot, mind a hibaüzeneteket hasznosíthatják: megállapíthatják belõlük, mely webhelyek rejtenek aranyat, és melyek csak kavicsot és homokot.
Hogyan hajtsuk végre ezt a támadást? A legtöbb ember nem igazán élvezi a forráskódok olvasgatását. Szerencsére mi, webtesztelõk, nem „csak úgy” keresgéljük a hibákat: vizsgálódásunk sokkal fókuszáltabb. Általánosságban, olyan HTML megjegyzések és érzékeny adatok (jelszavak, felhasználónevek, adatbázisnevek) azonosítására törekszünk, amelyek elõnyhöz juttathatják a támadót. Nem szabad elfelejtenünk hogy mivel a webalkalmazások forráskódjának jó része kikerül az ügyfél gépére, a támadó hozzáférhet. Annak ismerete, hogy egy adott algoritmus vagy üzleti program hogyan mûködik, ötleteket adhat arra nézve, hogy a támadó milyen megoldásokat alkalmazhat. Az aranymosás néha olyan megjegyzéseket fed fel, amelyeket a fejlesztõk hagytak a kódban, hogy emlékeztessék magukat vagy más fejlesztõket a befoltozandó lyukakra. Megjegyzéseket hagyni a végleges HTML kódban veszélyes. Mivel a HTML nem lefordított kód, a megjegyzéseket sem rejthetjük el a kíváncsi szemek elõl; a forráskód a böngészõ View, Source (Nézet, Forrás) vagy File, Save As (Fájl, Mentés másként) menüpontjain keresztül könnyen megtekinthetõ. A programozókat arra tanítják, hogy bõven használjanak megjegyzéseket a program felépítésének megvilágítására és a késõbb a programot módosító fejlesztõk útbaigazítására. Ezek a megjegyezések azonban nem a felhasználónak szólnak, és különösen nem szabad látnia õket, ha rosszindulatú felhasználóról van szó, aki kiaknázhatja az információkat. A forráskódban tehát olyan titkos, fel nem fedendõ információkat keresünk, mint az adatbázisok nevei vagy a felhasználók bejelentkezési nevei és jelszavai. Ahhoz, hogy ezeket teszteléskor megtaláljuk, olyan eljárásra van szükségünk, amely térképet rajzol a webalkalmazás felépítésérõl, és kielemzi a forrását. Az elsõ feladat az alkalmazás oldaltérképének felvázolása, hogy megértsük az oldalak közötti kapcsolatokat. Ebben segíthetnek a „webturkálók” (web crawler; ilyen program a wget vagy a BlackWidow, lásd a C függeléket), de hacsak nem többezer önálló oldalból épül fel az alkalmazás (tehát nem olyan oldalakból, amelyek aszerint mutatnak más képet, hogy milyen paraméterrel hívjuk meg õket), rendszerint célszerûbb ezt a feladatot saját kezûleg elvégezni, hogy jobban átláthassuk a webhely szerkezetét. Az önmûködõ eszközök használata gyakran vezet ahhoz, hogy egy oldalt sokszor látunk, és így a fejünkben nehezebben áll össze a kép. Egy webhelytérkép kézi elkészítése fárasztó lehet, de nem fogjuk megbánni, és biztosan közelebb visz minket ahhoz, hogy hatékony webtesztelõvé váljunk.
15
web02.qxd
1/17/2007
16
10:57 AM
Page 16
Hogyan törjünk fel webhelyeket Az eljárás egyszerû. Kezdjük a nyitólapon, és kattintsunk rá minden hivatkozásra, feljegyezve, mely oldalakat értük el. Ezt folytassuk addig, amíg minden oldalt meg nem látogattunk.
2.1. ábra Ûrlapparaméterek megtekintése webes közvetítõ eszközzel
Az oldaltérkép több információt nyújt, ha azokat az adatokat és paramétereket is feltüntetjük rajta, amelyeket az egyes lapok átadnak egymásnak. Ezeket az információkat azonban csak korlátozott mértékben nyerhetjük ki a forráskódból. A legegyszerûbb, ha az URL-ben keressük a kérdõjel után álló, egymástól & jelekkel elválasztott név=érték párokat (egy részletesebb példa a 4. fejezetben található), ez azonban csak a GET-paramétereknél mûködik, az ûrlapokon megadott értékek átvitele rendszerint más módon történik. Segítségünkre lehetnek azonban a webes közvetítõ (web proxy) programok. Az olyan eszközök, mint az IEHttpHeaders2 vagy a Paros3, felfedik számunkra az oldalak között átküldött adatokat (lásd a 2.1. ábrát). 2 Lásd: http://www.blunck.info/iethhpheaders.html 3 Lásd: http://www.parosproxy.org/225235.html
web02.qxd
1/17/2007
10:57 AM
Page 17
2. fejezet • Információk összegyûjtése a célpontról Amennyiben az alkalmazás szerep alapú hozzáférést valósít meg (vagyis a hozzáférési jogok attól függnek, hogy a felhasználó milyen szerepet tölt be, például rendszergazda vagy normál felhasználó-e), vagy engedélyek (jogosultságok) alapján mûködik, az aranymosást a legalacsonyabb szintû (semmilyen jogosultsággal nem rendelkezõ) felhasználó szerepében érdemes kezdeni, majd innen haladni a többi szerep felé, addig emelve a jogosultsági szintet, amíg el nem érünk a legtöbb jogosultsággal rendelkezõ felhasználóig. Ha mindezt feltüntetjük az oldaltérképen, láthatjuk a megbízhatósági határokat, ahogy azt a 2.2. ábra is mutatja.
2.2. ábra Webalkalmazás oldaltérképe
Miután az alkalmazást feltérképeztük, térjünk vissza minden egyes oldalhoz, és tekintsük meg a forrását. Vizsgáljuk át a HTML-t megjegyzéseket ( jelek között álló szövegeket) keresve, hogy láthassuk, mit tartalmaznak. A legtöbb webfejlesztõ az oldal navigációs részeit jelzi megjegyzésekkel, mások azonban olyan információkat is elhelyeznek bennük, amelyeket a támadók kihasználhatnak.
17
web02.qxd
1/17/2007
18
10:57 AM
Page 18
Hogyan törjünk fel webhelyeket Az alkalmazásprogramozási nyelveknek (PHP, ASP, Perl stb.) saját megjegyzésfajtáik vannak (// vagy */…/*). Ezeket a megjegyzéseket nem szabad az ügyfélen megjeleníteni, de ha rosszul helyezzük el a címkéket vagy a HTML megjegyzésjeleket, átcsúszhatnak a szûrõn. A legnagyobb veszély a ColdFusion nyelvnél áll fenn, mert ott a megjegyzéseket a jelek jelzik, amelyek csak abban különböznek a HTML szokványos megjegyzésjeleitõl, hogy kettõ helyett három kötõjel szerepel bennük, ezért a programozó könnyen lefelejtheti az utolsót. A megjegyzések többnyire érdektelen emlékeztetõk a kódban, amelyek csak a kód jobb megértését szolgálják, de néha aranyrögnek bizonyulnak. A régi, immár szükségtelen kódrészleteket gyakran csak megjegyzésjelek közé teszik, ahelyett, hogy törölnék azokat, ahogy kellene, ezek a töredékek pedig árulkodhatnak az alkalmazás belsõ mûködésérõl. Más, leíró megjegyzések beállításokat, gép- és adatbázisneveket fedhetnek fel. A forrásfájlok kézi aranymosása helyett automatikusan is kereshetünk karakterlánc-mintákat, különösen ha az oldalak egyenkénti meglátogatása helyett webturkálót használtunk. Ehhez a grep a legalkalmasabb eszköz, amely a UNIX/Linux terjesztések szokványos része, de Windowson külön telepíteni kell, például a Cygwinen4 keresztül, amely egy ingyenes Linux típusú környezet Windowsra, amely tartalmazza a megszokott *NIX-eszközöket. Az alábbi táblázatban felsoroltuk azokat a dolgokat, amelyeket a grepnek átadott szabályos kifejezésekkel leírt mintákkal keresni érdemes a HTML forráskódban. Saját keresõkifejezések létrehozásához nagyszerû ingyenes eszköz a The Regulator, amelyet megtalálhatunk a http://regex.osherove.com címen. Elem HTML megjegyzés
Leírás A HTML-megjegyzések többsége érdektelen navigációs vagy oldalszakasz-jelzõ, de néha hasznos információkra bukkanhatunk. Programmegjegyzés A kód végrehajtásakor a webkiszolgálón minden programmegjegyzést el kell távolítani. Bármi, amit meghagyunk, érdekes lehet a támadóknak.
IP cím
A forráskódban szereplõ minden IP cím érdekes lehet, mert a kód az alkalmazás elsõdleges kiszolgálóján kívül más kiszolgálókra is hivatkozhat (például adatbáziskiszolgálókra vagy egy fürt egyes kiszolgálóinak IP címeire)
4 Lásd:http://www.cygwin.com/
Grep minta
ColdFusion //.* Egysoros megjegyzések /\*[\w\W]*?\*/ C stílusú megjegyzésblokkok ^'.* rem\s.* VB megjegyzések [0-9]{1,3}\.[0-9]{1,3}\. [0-9]{1,3}\.[0-9]{1,3}
web02.qxd
1/17/2007
10:57 AM
Page 19
2. fejezet • Információk összegyûjtése a célpontról Elem E-mail cím SQL lekérdezés
Leírás A fejlesztõ elektronikus levélcímét tartalmazhatja Ilyet találni bármely oldal forrásában olyan, mintha egy hatalmas aranyrögre bukkannánk. Nem csak az adatbázis szerkezetérõl árulkodik, hanem a lekérdezések felépítésérõl is.
Grep minta [\w]*(\.[\w]*)*@[\w]*(\.[\w]*) SELECT\s[\w\*\)\(\,\s]+\ sFROM\s[\w]+ UPDATE\s[\w]+\sSET\s[\ w\,\’\=]+ INSERT\sINTO\s[\d\w]+ [\s\w\d\)\(\,]*\sVALUES\s\ ([\d\w\’\,\)]+ DELETE\sFROM\ s[\d\w\’\=]+ Provider|Data\sSource| Driver
Adatbázis-kapcsolati Szokványos kulcsszavak általános karakterlánc keresési mintája az adatbázis-kapcsolati karakterláncokban. Sokszor hamisan ad pozitív eredményt a nyelvek és adatbázisok különbözõsége miatt. Rejtett beviteli mezõ A rejtett beviteli mezõkkel a 6. tá-
helyének azonosítása azonban sok idõt takaríthat meg.
Miután kézi módszerrel és automatizálva is átfésültük a forrást, az oldalak között átadott paraméterekre kell fordítanunk a figyelmünket. Ezekkel a paraméterekkel hibaüzenetek megjelenítésére kényszeríthetjük az alkalmazást: ha a paramétereket olyan értékekre állítjuk, amelyek kívül esnek a normál értéktartományon vagy az adattípus korlátain, érdekes tervezési részletekre deríthetünk fényt, és olyan hibaoldalakra juthatunk, amelyek hasznos információkkal látják el a támadókat – márpedig éppen õk azok, akiknek a legkevésbé szeretnénk segíteni. Vegyük például a 2.3. ábrán látható képernyõképet: az adatbázishoz való kapcsolódás során hiba lépett fel, és a ColdFusion program nem kezelte, a hibaoldal azonban nem csak arról tájékoztat, hogy mi volt a probléma, hanem a kódkörnyezetrõl is. Normális esetben a kiszolgáló feldolgozná a elemet, ám annak megjelenítése itt értékes információkat ad a támadónak – az adatbázis egyik táblájának, illetve magának az adatbázisnak a nevét. Az adatbázisok pedig gyakran tartalmaznak olyan adatokat, amelyekre a támadók nagyon kíváncsiak, mert ezeket felhasználhatják például SQL-befecskendezéshez (lásd az 5. és 7. fejezetet).
19
web02.qxd
1/17/2007
20
10:57 AM
Page 20
Hogyan törjünk fel webhelyeket Egyes környezetekben, például ColdFusion programokban vagy Java servletekben (kiszolgálóoldali kisalkalmazásokban) az alkalmazás nyelvtani hibával vagy kezeletlen kivétellel való térdre kényszerítése azt eredményezi, hogy a kiszolgáló a meghívott függvények nyomkövetési információval válaszol, és beillesztheti a hiba helyének kódkörnyezetét is. Kényszerítsünk ki annyi hibaüzenetet, amennyit csak tudunk, és olvassunk el mindent, amit a kiszolgáló kiír. Akár az alkalmazástól, akár a webkiszolgálótól származnak a hibaüzenetek, hasznos információkat nyújthatnak a támadóknak. A sokatmondó hibaüzenetekre klasszikus példa a bejelentkezési képernyõ, amely felhasználónevet és jelszót kér: amennyiben az alkalmazás más-más hibaüzenetet ad az érvénytelen felhasználónevekre és az érvénytelen jelszavakra, a támadónak elárulja, hogy mikor választott létezõ felhasználónevet.
2.3. ábra Információ felfedése egy hibás adatbázis-kapcsolatban
A 2.4. ábra egy érvénytelen felhasználónévvel történõ bejelentkezési kísérletet mutat, míg a 2.5. ábra egy érvénytelen jelszó beírása utáni hibaüzenetet. Egymás mellé téve õket, a különbség látható, de egyenként megtekintve fel sem tûnne. A veszélyt az jelenti, hogy a támadó most már tudja, hogy érvényes felhasználónévre bukkant, így már csak a hozzá tartozó jelszót kell kitalálnia vagy feltörnie.
web02.qxd
1/17/2007
10:57 AM
Page 21
2. fejezet • Információk összegyûjtése a célpontról
2.4. ábra Hibaüzenet érvénytelen felhasználónév megadása esetén
2.5. ábra Hibaüzenet érvénytelen jelszó megadása esetén
21
web02.qxd
1/17/2007
22
10:57 AM
Page 22
Hogyan törjünk fel webhelyeket
Hogyan védekezhetünk ez ellen a támadás ellen? A biztonságos webalkalmazások fejlesztése nem csak arról szól, hogy miként kezelje a kód a bemenetet, hanem arról is, hogy milyen legyen a kimenet. Fejlesztõként meg kell találnunk az egyensúlyt a hasznos és a veszélyes információk között. Felül kell vizsgálnunk minden megjegyzést a forráskódban (mind az alkalmazás kódjában, mind a HTMLben), hogy meghatározhassuk, mi számít a felhasználók és a fejlesztõk számára közérthetõ és hasznos információnak, és mi a támadókat segítõ kikotyogott adatnak. A végleges kódból célszerû minden megjegyzést eltávolítani, és csak azokban a példányokban tárolni, amelyek belsõ, kizárólag a fejlesztõk által használt kiszolgálókon találhatók. Ugyanez vonatkozik a hibaüzenetekre, akár a webkiszolgálótól, akár a programnyelvi környezettõl (PHP, ColdFusion, ASP.NET stb.), akár magától a webalkalmazástól származnak. Az információk „kiszivárogtatását” mindenképpen meg kell akadályoznunk. A felhasználót tájékoztató üzeneteknek hasznosaknak, de egyben szûkszavúaknak kell lenniük. Sikertelen bejelentkezés esetén például célszerû ilyen hibaüzenetet adni: „A megadott felhasználónév/jelszó érvénytelen.”. Ennek az üzenetnek az alapján a felhasználó tudhatja, mi volt a hiba, de a támadó nem találhatja ki, hogy vajon a megadott név vagy a jelszó volt érvénytelen. Más hibaüzenetek túl sok részletet árulhatnak el. Nem az olyan rejtélyes üzenetek használatára akarunk bátorítani, mint az „58-as hiba”, hanem olyanokéra, amelyek pontosan leírják a problémát, de anélkül, hogy túl sok információt adnának ki. Egy sikertelen SQL lekérdezésnél például mindenképpen tájékoztatnunk kell a felhasználót a hibáról, de semmiképpen nem szabad kiírni magát a hibás lekérdezést, mert erre az információra a felhasználónak nincs szüksége. Mindig tartsuk észben, hogy webhelyünk látogatói nem feltétlenül a barátaink: rosszindulatú felhasználóból igen sok kószál a Világhálón. Persze nem kell eldobnunk minden bõbeszédû üzenetet; egy kiszolgálóoldali naplófájlban összegyûjthetjük azokat. A naplók segíthetnek a csúnya futásidejû hibák okának felderítésében – a fejlesztõknek például gyakran ismerniük kell az adott SQL lekérdezést, hogy azonosíthassák a hibát, és ne kelljen a tünetek reprodukálásával próbálkozniuk. A naplófájlok idõszakos átnézésével arra is fényt deríthetünk, hogy a felhasználók az alkalmazás mely részein ütköznek problémákba (és esetleg vissza is térhetünk, hogy csiszoljunk az alkalmazás mûködésén), sõt arra is, hogy milyen támadásokat kísérelnek meg a webhelyünk ellen.
web02.qxd
1/17/2007
10:57 AM
Page 23
2. fejezet • Információk összegyûjtése a célpontról
2. támadás: Fájlok és könyvtárak kitalálása Leegyszerûsítve, a weblapok a webkiszolgálón található fájlok, amelyeket egy böngészõprogrammal bárki elérhet. A fájlokat rendszerint alapértelmezett könyvtárakban tárolják (például C:\Inetpub), és olyan elnevezési szabályokat alkalmaznak, amelyek a helyet és a fájlnevet megjósolhatóvá teszik. Ez azt jelenti, hogy még ha nem is mutat hivatkozás egy adott fájlra, a támadó kitalálhatja a nevét és a helyét, és közvetlenül a böngészõ címsorába beírva a teljes elérési útját hozzáférhet. Híres példa arra, hogy egy ilyen látszólag jelentéktelen dolog mekkora kárt okozhat, az az eset, amikor a Reuters hírügynökség közzétette az Intentia nevû svéd szoftvercég harmadik negyedévi bevételi adatait, mielõtt azokat hivatalosan megjelentették volna.5 Az adatokat tartalmazó dokumentum felkerült a cég webhelyére, de még nem mutatott rá hivatkozás (ezt nyilván késõbb akarták beilleszteni). Egy szorgos újságíró azonban kitalálta a fájl nevét és helyét az elõzõ negyedév hasonló dokumentuma alapján, és rá is bukkant a fájlra. Ezzel a módszerrel azonban nem csak dokumentumok támadhatók. A webkiszolgálók és rajtuk futó alkalmazások egyre nagyobb mértékben támaszkodnak távolról elérhetõ vezérlõ- és beállítási oldalakra: ha ezeket felfedezik, és nem vagy nem megfelelõen védettek (lásd a 8. fejezetben a 20. támadást), a támadó irányítása alá vonhatja a célrendszert.
Mikor alkalmazzuk ezt a támadást? Ha elkészítettük a célrendszer oldaltérképét (lásd az elõzõ támadás tárgyalásánál), könnyebben észrevehetjük, milyen oldalelnevezési minták vannak jelen, és felfedezhetjük a „nyilvánvalóan” hiányzó részeket is. Egy ilyen támadás végrehajtásának tehát a célrendszer különbözõ oldalainak és tartalmának végigjárása és dokumentálása után van értelme.
Hogyan hajtsuk végre ezt a támadást? A minták keresési módjára nehéz általános érvényû szabályt adni, de gyakorlással rutint szerezhetünk a minták kiszúrásában. A legegyszerûbben azokat a dokumentumokat találhatjuk meg, amelyeket feltöltéskor sorszámoznak: egy sikeresen megtalált oldal sorszámának csökkentésével vagy növelésével elõfordulhat, hogy máskülönben tiltott oldalakhoz is hozzáférhetünk. 5 Lásd: http://news.com.com/2100-1023-963658.html
23
web02.qxd
1/17/2007
24
10:57 AM
Page 24
Hogyan törjünk fel webhelyeket Az, hogy ez gondot jelent-e, az alkalmazástól függ. Ha egy e-kereskedelmi alkalmazásban a „támadó” ezzel a trükkel más termékek leírását is megtekintheti, azzal még nem jut elõnyhöz. Legfeljebb megkerüli az ajánlott navigációs rendszert, de csak olyan oldalakat ér el, amelyeken mindenki számára hozzáférhetõ információk találhatók. Ha azonban a kérdéses alkalmazás egy online banki rendszer, amelyben a támadó egy számlaszám módosításával más számlákat próbál elérni, az már nyilván problémát jelenthet. Ha felfedeztünk egy mintát, az iDefence session ID auditor (egy ma már nem hozzáférhetõ, de a CD-mellékleten megtalálható, nyers erõt alkalmazó eszköz) segítségével megadhatjuk a keresési formátumot. Az említett eszköz minden lehetõséget végigpróbál, és amikor létezõ oldalra bukkan, megáll, és tájékoztat, hogy olyan oldalt ért el, amelyhez egyébként nem lett volna szabad hozzáférnie (lásd a 2.6. ábrát). Ez a fajta támadás egy webkiszolgáló bármely fájlja ellen végrehajtható. Ha a webhely szabványos elnevezési rendszert alkalmaz, a fájlokat közvetlenül lekérhetjük, és elõfordulhat, hogy ezzel megkerülhetünk minden hozzáférés-szabályozást.
2.6. ábra Az iDefence Session ID Auditor
web02.qxd
1/17/2007
10:57 AM
Page 25
2. fejezet • Információk összegyûjtése a célpontról A vezérlõoldalakat (felügyeleti oldalakat) kétféleképpen lehet elrejteni. Lehetnek az alkalmazás önálló részwebhelyei (mint a 2.7. ábrán a virágüzlet webhelyének /admin/ része), de futhatnak a fõ webkiszolgáló szabványos 80-as kapujától eltérõ kapun is (mint a 2.8. ábra ColdFusion-példájában, amely a 8100-as kaput használja).
2.7. ábra Felügyeleti oldal egy rejtett könyvtárban
2.8. ábra Másik kapun futó felügyeleti oldal
25
web02.qxd
1/17/2007
26
10:57 AM
Page 26
Hogyan törjünk fel webhelyeket A részwebhelyek megtalálása olyan, mint egy kitalálós játék, de az okos tippelés alaposan lecsökkentheti a találgatások számát. Olyan nevekkel érdemes próbálkozni, mint az admin, a control vagy a cp (Control Panel). Minden lehetõséget persze nem lehet végigpróbálni, különösen ha a nevek véletlenszerûek, ezért maradjunk azoknál a szokványos neveknél, amelyeket a támadók kitalálhatnak. Amikor a felügyeleti oldalak másik kapun futnak, a lehetõségek könnyebben végigpróbálhatók, mert a kapuk (portok) száma véges, és egyesekrõl tudhatjuk, hogy más alkalmazások használják õket. Az alkalmazásokhoz rendelt kapuk általában egy 1024-nél nagyobb számot kapnak („1024 feletti kapuk”)6. Egy kapupásztázó programot használva felderíthetjük, mely kapuk nyitottak, és hozzájuk kapcsolódva elõfordulhat, hogy felügyeleti oldalakra bukkanunk.
2.9. ábra Felügyeleti felületek keresése kapupásztázással
6 Az 1024 alatti kapuk „kitüntetett” kapuk, amelyek használatát az operációs rendszer határozza meg. Ezek a kapuk más célokra is használhatók, de ennek súlyos következményei lehetnek a biztonságra nézve.
web02.qxd
1/17/2007
10:57 AM
Page 27
2. fejezet • Információk összegyûjtése a célpontról
Hogyan védekezhetünk ez ellen a támadás ellen? A tanulság az, hogy a biztonság tekintetében ne támaszkodjunk a korlátozott láthatóságra. Ha egy információt csak az véd, hogy nehéz kitalálni, magunknak keressük a bajt. A fájlokhoz közvetlen hozzáférést szerezni próbáló támadók megállításának elsõ lépése, hogy úgy állítjuk be a webkiszolgálót, hogy csak olyan oldalakat szolgáltasson, amelyek az alkalmazáshoz tartoznak, például engedélyezze a PHP-oldalakra irányuló kérelmeket, de tagadja meg minden más fájl elérését. Az alábbi kód, amely az Apache beállítófájljából származik, éppen ezt teszi: Order allow,deny Deny from all
A fenti kód arra kényszerít minden kérelmet, hogy áthaladjon az alkalmazáson, ahol hitelesítést lehet végrehajtani (bár az URL-átugrás veszélye így is fennáll; lásd a 4. fejezetben a 8. támadást). A felügyeleti oldalakhoz, illetve a webhely normál felhasználóktól elzárt részeihez való hozzáférés korlátozásának másik módja, ha jelszót követelünk meg a belépéshez az említett területekre. Ezt többféleképpen megvalósíthatjuk (alapszintû, kivonat alapú vagy ûrlap alapú azonosítással), de mindegyik módszernek megvannak a maga sebezhetõ pontjai (lásd a 20. támadást a 8. fejezetben) – igaz, legalább egy újabb biztonsági szintet jelentenek. Az Apache kiszolgálókon létrehozhatunk például egy .htaccess fájlt, amely a védeni kívánt könyvtárban a következõ szöveget tartalmazza: AuthName "admin pages" AuthType Basic AuthUserFile /path/to/.htpasswd Require valid-user
Ezt követõen a htpasswd program futtatásával létre kell hoznunk egy jelszófájlt, amelyet olyan helyen kell tárolnunk, ahol a webkiszolgáló elérheti, de nem más webdokumentumokkal együtt. Nem szabad, hogy valaki letölthesse és a kapcsolatot bontva elemezhesse a tartalmát. #htpasswd –cm .htpasswd username
A fenti kód hatására a böngészõ egy üzenetablakot jelenít meg, amelyben felhasználónevet és jelszót kér az azonosításhoz, mielõtt engedélyezné a hozzáférést bármely fájlhoz, amely a .htaccess fájllal azonos könyvtárban található. Az Internet Information Server esetében hasonló megoldást alkalmazhatunk, amely a Windows beépített felhasználói fiókjain, illetve a fájl- és könyvtárszintû jogosultságokon alapul.
27
web02.qxd
1/17/2007
28
10:57 AM
Page 28
Hogyan törjünk fel webhelyeket A webkiszolgálót úgy is beállíthatjuk, hogy csak megadott hálózati címeknek adjon ki fájlokat, vagy hogy a belsõ hálózattól eltekintve tûzfallal akadályozza meg a kapukhoz való hozzáférést, így támadás csak (remélhetõleg) megbízható forrásból érkezhet.
3. támadás: Mások által hagyott lyukak – a mintaalkalmazások sebezhetõ pontjai A webalkalmazások programozása egyike a valódi „gyors fejlesztési” környezeteknek. A webalkalmazások fejlesztési ideje általában jelentõsen rövidebb a hagyományos programokénál, nagyrészt annak köszönhetõen, hogy programozásuk egyszerûbb, és rengeteg elõre megírt, újrahasznosítható kódkönyvtár áll rendelkezésre hozzá. A most bemutatandó támadás éppen ezekre a könyvtárakra összpontosít. Saját kódjaink minõségében ugyan megbízhatunk, de mi a helyzet azokkal a mások által írt kódokkal, amelyekre támaszkodunk? A kódkönyvtárak és mintaalkalmazások újrahasznosításakor kellõ óvatossággal kell eljárnunk. Régebben megszokott volt, hogy a webkiszolgálók alapértelmezett telepítésekor mintaalkalmazások, „segédparancsfájlok” és dokumentációs anyagok is felkerültek a gépre, de a rossz tapasztalatok7 miatt ez a gyakorlat ma már megszûnt. A kereket persze nem kell újra és újra feltalálni; ma is megszokott a létezõ programösszetevõk újrahasznosítása. Rengeteg olyan webhely létezik, ahol a fejlesztõk kicserélhetik kódjaikat; ilyen például a cfexchange.com, a gotdotnet.com vagy a px.sklar.com. A kérdés, amit fel kell tennünk magunknak, csak ennyi: mennyire bízhatunk meg mások kódjaiban?
Mikor alkalmazzuk ezt a támadást? Ezt a támadásfajtát teszteléskor kétszer kell végrehajtanunk: a webkiszolgáló telepítésekor, illetve a fejlesztés végén. A webkiszolgáló és az alkalmazáskörnyezet telepítése (itt az alkalmazás-kiszolgálóról – .NET, PHP, Java stb. –, nem az alkalmazás, vagyis a webhely kódjáról van szó) kritikus pont. Olyan kiegészítõ szolgáltatásokat kell keresnünk, amelyek telepítéskor kerülnek a rendszerre, hogy tudjuk, milyen kódokat tartalmaz a webkiszolgáló, és hogy meggyõzõdjünk róla, hogy nem öröklünk sebezhetõ pontokat. A webkiszolgáló nyilvános, nem megbízható felületekkel dolgozik, ezért tudnunk kell, milyen szoftver várakozik ezeken a felületeken arra, hogy használják vagy visszaéljenek vele. 7 Lásd: http://news.com.com/ColdFusion+still+shows+security+holes/2100-1001_3-225235.html
web02.qxd
1/17/2007
10:57 AM
Page 29
2. fejezet • Információk összegyûjtése a célpontról A fejlesztési folyamat vége, vagyis a kiszolgáló életre kelése szintén kritikus pillanat. Ellenõriznünk kell, hogy milyen megosztott vagy külsõ fejlesztésû összetevõket használ az alkalmazásunk, és gondoskodnunk kell róla, hogy ezeket ne lehessen könnyen eltéríteni.
Hogyan hajtsuk végre ezt a támadást? A webalkalmazás megtámadásának módja ebben az esetben megegyezik a védekezés módjával. A hackerek feliratkoznak az elterjedt összetevõkben felfedezett sebezhetõ pontokról tájékoztatást adó levelezõlistákra és hírcsoport-üzenetekre. Egyes csoportok teljes körû tájékoztatást adnak, és részletesen leírják nem csak az adott problémát, hanem a támadás módját is (gyakran lépésrõl lépésre – de akár elõre megírt eszközt is kínálhatnak hozzá). Még ha ilyen információk nem is állnak rendelkezésre, a bejelentés pillanatától kezdve alapos vizsgálódás és tesztelés indul, és csak idõ kérdése, mikor teszik közzé a feltörési módszer részleteit. Ráadásul a hackerek földalatti kommunikációs rendszere hatékonyabb, mint a CERT-hez hasonló szokványos információ-megosztó hálózatok, ezért az idõvel is versenyt kell futni. Az elterjedt összetevõk elleni különbözõ támadási módszereket nem érdemes itt boncolgatni, mert azok általában ugyanazok, mint amelyeket ebben a könyvben és a sorozat többi kötetében ismertetünk. A lényeg az, hogy tisztában legyünk a mások által írt kódok felhasználásának veszélyeivel: ellenõrizzük a kód eredetét, tájékozódjunk róla, és közeledjünk hozzá kellõ óvatossággal. Azonosítsunk minden külsõ fejlesztésû összetevõt, amit az alkalmazásunkban használunk, látogassunk el a kérdéses összetevõ honlapjára, és más forrásból is tájékozódjunk róla, honnan származik. Tegyük fel a következõ kérdéseket: Gyakran frissítik az összetevõt? Sérülékeny bizonyos támadásokkal szemben? Korábban merültek fel vele kapcsolatban súlyosabb biztonsági aggályok? Mindezek az információk elegendõ háttérismeretet adnak ahhoz, hogy eldönthessük, használjuk-e az összetevõt és megbízunk-e benne. A megosztott vagy külsõ fejlesztésû összetevõk esetében ennél is nagyobb figyelmet kell fordítanunk az általuk kapott és továbbított adatokra, mert nem tudhatjuk, hogy belül milyen elõfeltételezésekkel élnek, és milyen hibaellenõrzést végeznek. Minden nem általunk írt összetevõvel kapcsolatban azt tanácsoljuk, hogy legyünk különösen paranoiásak a bemenet és a kimenet ellenõrzését illetõen. Gondoskodjunk róla, hogy csak megfelelõ adatok jussanak el hozzájuk a saját kódunkból, és szigorúan ellenõrizzünk mindent, ami tõlük érkezik. A könyvben bemutatott támadásfajták alkalmazásával megvizsgálhatjuk, hogyan viselkedik az összetevõ támadás esetén. Ha nem állapítható meg, hogy mi került a gépre a kiszolgáló telepítésekor, a nyílt forrású Nikto8 nevû eszközzel számos tesztet elvégeztethetünk, amelyekkel ismert sebezhetõ 8 Lásd: http://www.cirt.net/code/nikto.shtml
29
web02.qxd
1/17/2007
30
10:57 AM
Page 30
Hogyan törjünk fel webhelyeket pontokat kereshetünk. Az egyéni hibaoldalak és különbözõ kiszolgálóbeállítások miatt a tesztek sajnos gyakran adnak hamis pozitív eredményt. Természetesen a webkiszolgáló alkalmazás maga is gyakran célpontja a támadásnak, de ezzel a témával majd a 7. fejezetben (19. támadás) foglalkozunk.
Hogyan védekezhetünk ez ellen a támadás ellen? Az ilyen támadások elleni védekezésnek az az egyik módja, hogy lucsupaszított webkiszolgálót (és operációs rendszert) telepítünk, és soha nem használunk megosztott vagy külsõ fejlesztésû összetevõket. Ez persze egy megosztott környezetben sokszor nem kivitelezhetõ, és a fejlesztõk képességein, az idõn és a költségvetésen is múlik, mennyire megvalósítható. (Gyakran olcsóbb egy kész megoldás felhasználása vagy akár megvásárlása, mint saját kód írása.) Lényeges, hogy minden összetevõt megvizsgáljunk az ismert sebezhetõ pontok szempontjából, beleértve a webkiszolgálót és annak elemeit is, hogy naprakész információkat szerezzünk levelezõlistákról és hírcsoportokból, illetve hogy az IISLockdownhoz hasonló eszközökkel lezárjuk a kiszolgálókat.9
9 Lásd: http://www.microsoft.com/technet/security/tools/locktool.mspx
