A betörési tesztelés mellett a nyomelemző munkák területe az a témakör, amelyről sok szakmabeli is csak homályos képpel rendelkezik, holott meglehetősen szerteágazó és szövevényes világról van szó. Több posztból álló sorozatunkban igyekszünk felvillantani néhány érdekesebb momentumot nyomelemzős munkáinkról.
Forensic munkák során gyakran kerül valamilyen adathordozó a vizsgálatok szkópjába. Lehet ez egy pendrive, egy írható CD, de a legtöbb esetben ilyen módon kezeljük a vizsgált munkaállomások és szerverek merevlemezeit is. Ahhoz, hogy a vizsgálatok további szakaszai számára megbízható és megfelelő alapanyagot szolgáltassunk a nyomgyűjtési fázis során, elengedhetetlenül szükséges a szóba kerülő adathordozó megfelelő kezelése.
Adathordozó nyomrögzítése során alapelv, hogy a forensic vizsgálatok során soha nem az eredeti példányon vizsgálódunk, hanem kizárólag megbízható eszközökkel és hiteles módon készített másolaton. A másolatkészítés ilyen formájának több oka is van.
Egyrészt egészen egyszerűen sokszor nem megoldható, hogy az kivizsgáláshoz elvigyük fizikailag az érintett adathordozót (például egy produktív rendszerben üzemelő szerverből nem szívesen adják oda a merevlemezt, ha napokig, esetleg hetekig is eltartanak a vizsgálatok), másrészről a másolaton vizsgálódó értelemszerűen nem tud véletlenül sem kárt tenni az eredeti médiában. A "hiteles módon" történő másolatkészítés szükség esetén ajánlás szerint úgy történik, hogy a lemezről készülő másolatot két példányban készítjük el, az egyik példányt és a róla készült hash-t megbízható hatóságnál hagyjuk, míg a másikon vizsgálódunk.
Milyen módon történik a "másolat" elkészítése? Az elveszett, adatszivárogtató pendrive-ok kapcsán készült bejegyzésben már érintettük, hogy az adathordozóról image-et készítünk, amely bitről bitre történő másolatát jelenti az eredeti eszköz tartalmának. Munkaállomások merevlemezeinek image-e magában foglalja nemcsak az összes felhasználói adatot, amelyet tárolnak a lemezen, hanem a partíciós táblát, a master boot recordot, a partícionálatlan helyeket, a partíciók közti "gap"-eket is.
Sok esetben nem is a forensic munkaállomást használjuk image-elési célokra, hanem céleszközt veszünk igénybe a feladatra. A céleszköz teljesen automatizáltan végzi a munkát: beleteszünk rengeteg saját merevlemezt, amikre az image-ek rákerülnek, illetve csatlakoztatjuk hozzá az érintett adathordozót. A másolat munkaállomáson történő elkészítéséhez (pl. pendrive esetén) sok esetben a dd linuxos eszközt, illetve ennek származékait (rescuedd például) használjuk, de az olyan forensic céleszközök is, mint az EnCase, illetve a Forensic Toolkit, rendelkeznek imaging funkcióval. Az elkészült másolaton történik meg a vizsgálat az adathordozón tárolt adatokból, a fájlrendszer metaadataiból és egyéb helyekről történő információgyűjtéssel.
2009. április 27., hétfő
2009. április 22., szerda
Forensic vizsgálatok 1. - A Windows registry elemzése
A betörési tesztelés mellett a nyomelemző munkák területe az a témakör, amelyről sok szakmabeli is csak homályos képpel rendelkezik, holott meglehetősen szerteágazó és szövevényes világról van szó. Több posztból álló sorozatunkban igyekszünk felvillantani néhány érdekesebb momentumot nyomelemzős munkáinkról.
Ha forensic munkáink során felhasználói munkaállomás kerül a vizsgálatok szkópjába, túlnyomórészt a Windows valamilyen verziója fut rajta - nem reprezentatív statisztikáink szerint a praxisban előforduló Windowsok 99%-a Xp. Munkaállomások sokféleképp látótérbe kerülhetnek: gyakran valamilyen visszaélés, szándékos adatszivárogtatás felfedezése áll a vizsgálatok indítása mögött, de volt már arra is példa, hogy külső betörés miatt hívtak minket.
Akármilyen céllal is indulnak a vizsgálatok, fontos lépés az, amikor felépítjük egyrészt a munkaállomást használó alkalmazottak profilját az operációs rendszeren és a fájlrendszerben található nyomok felhasználásával, másrészt összeállítjuk a munkaállomásokon a (közel)múltban végzett munka pontos dokumentálását (ezt ékes angolsággal timeline analysis névvel illetik. A szerző magyarul csak meglehetősen setesuta fordításokat olvasott, ezért maradna az eredeti névnél). A timeline analysis kimenete meglepő módon egy timeline, ami rögzíti, hogy milyen tevékenységet végeztek a felhasználók a munkaállomáson (pl. 2009. április 4., 8.00: index.hu meglátogatása, 8.15: bela.doc megnyitása, 8:18: Skype kliens telepítése)
A felhasználó profilozásához és az analízis elvégzéséhez rendkívül jól használható információkkal szolgál a Windows regisztrációs adatbázisa. A legtöbb felhasználó közvetlenül nem kerül kapcsolatba vele (nem nyitják meg, nem szerkesztik, sőt a legtöbb esetben nem is tudják, hogy létezik egyáltalán), viszont a munkaállomáson végzett tevékenység sokféleképp rögzül a Registryben.
A Registry egy bináris adatbázis, amelyben ágak, magyarul hive-ok találhatóak. Az egyes hive-ok különböznek egymástól mind funkcióban, másrészt mind abban, hogy a fájlrendszer mely részében található meg maga a megfelelő fájl. A beépített windowsos regedit.exe használatával egységes felületen láthatjuk a különböző hive-okat. Mik is ezek?
Milyen eszközökkel lehet kinyerni a registryben tárolt információkat? Kimondottan jó választás a regripper, de a Helix suite-ben is találhatóak eszközök a registryből történő információkinyerésre. Aki a parancssoros matatást részesíti előnyben, használhatja a linuxos chntpw eszközt is.
Ha forensic munkáink során felhasználói munkaállomás kerül a vizsgálatok szkópjába, túlnyomórészt a Windows valamilyen verziója fut rajta - nem reprezentatív statisztikáink szerint a praxisban előforduló Windowsok 99%-a Xp. Munkaállomások sokféleképp látótérbe kerülhetnek: gyakran valamilyen visszaélés, szándékos adatszivárogtatás felfedezése áll a vizsgálatok indítása mögött, de volt már arra is példa, hogy külső betörés miatt hívtak minket.
Akármilyen céllal is indulnak a vizsgálatok, fontos lépés az, amikor felépítjük egyrészt a munkaállomást használó alkalmazottak profilját az operációs rendszeren és a fájlrendszerben található nyomok felhasználásával, másrészt összeállítjuk a munkaállomásokon a (közel)múltban végzett munka pontos dokumentálását (ezt ékes angolsággal timeline analysis névvel illetik. A szerző magyarul csak meglehetősen setesuta fordításokat olvasott, ezért maradna az eredeti névnél). A timeline analysis kimenete meglepő módon egy timeline, ami rögzíti, hogy milyen tevékenységet végeztek a felhasználók a munkaállomáson (pl. 2009. április 4., 8.00: index.hu meglátogatása, 8.15: bela.doc megnyitása, 8:18: Skype kliens telepítése)
A felhasználó profilozásához és az analízis elvégzéséhez rendkívül jól használható információkkal szolgál a Windows regisztrációs adatbázisa. A legtöbb felhasználó közvetlenül nem kerül kapcsolatba vele (nem nyitják meg, nem szerkesztik, sőt a legtöbb esetben nem is tudják, hogy létezik egyáltalán), viszont a munkaállomáson végzett tevékenység sokféleképp rögzül a Registryben.
A Registry egy bináris adatbázis, amelyben ágak, magyarul hive-ok találhatóak. Az egyes hive-ok különböznek egymástól mind funkcióban, másrészt mind abban, hogy a fájlrendszer mely részében található meg maga a megfelelő fájl. A beépített windowsos regedit.exe használatával egységes felületen láthatjuk a különböző hive-okat. Mik is ezek?
- HKEY_CLASSES_ROOT (HKCR)
- HKEY_CURRENT_USER (HKCU)
- HKEY_LOCAL_MACHINE (HKLM)
- HKEY_USERS (HKU)
- HKEY_CURRENT_CONFIG
- HKEY_PERFORMANCE_DATA
- HKEY_DYN_DATA
- %SystemRoot%\System32\Config\SAM, SECURITY, SOFTWARE, DEFAULT
- %DocumentRoot%\NTUSER.DAT
- %SystemRoot%\System32\Config\ - itt nemcsak magukat a backup állományokat láthatjuk, hanem a tranzakciós logokat is [USER|SAM|SECURITY|DEFAULT].log néven.
- C:\System Volume Information\_restore{[...]}\RPxxx\Snapshot
- Sikeres szoftvertelepítések időpontjai. A registryben készül egy bejegyzés minden telpeített szoftverről, időpecséttel. Nem csak "igazi" telepített programok szerepelnek itt, hanem a Windows biztonsági frissítései is.
- A telepítés óta elindított .exe fájlok neve, az elindítások száma és a legutóbbi indítás időpontja. Bővebb kommentár nem szükséges hozzá...
- Az Internet Explorerben legutóbb meglátogatott URL-ek listája
- Legutóbb megnyitott dokumentumok listája
- A Media Playerben megnyitott fájlok listája
- A rendszerhez valaha hozzáadott adattárolók listája (ez akkor hasznos, ha a kérdés az, hogy egy bizonyos pendrive-ot csatlakoztatott-e a felhasználó a gépéhez)
- A felhasználó(k) lokális jelszavai
- Bejelentkezések időpontjai
- Környezeti változók, amik a felhasználó(k)ra jellemzőek
- Az egyes hive-ok kulcsainak legutóbbi módosítására vonatkozó timestamp (nagyon hasznos, ha például a kérdés az, mikor került az autostartok közé valamilyen alkalmazás)
- A registryben el is lehet rejteni (!) adatokat. A triviális megoldás (jó mélyre dugjuk az elrejteni kívánt adatokat, hátha a felhasználó nem találja meg) mellett ismeretes a default regedit.exe egy hibája is: a régi verziók nevezetesen nem tudnak mit kezdeni a nagyon hosszú nevű bejegyzésekkel, és adott esetben akár nem is jelenítik meg a felhasználó számára.
- Sok malware különféle, Registryhez kapcsolódó technikákkal terjed (például ismert módszer az, hogy a HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\alatti kulcsot használják. Ez a kulcs lehetőséget biztosít arra, hogy megváltozatassuk a fájlok indításakor elinduló processzeket, és pl. egy "DEBUG" kulcsot létrehozva akár backdoort is indíthat a malware).
Milyen eszközökkel lehet kinyerni a registryben tárolt információkat? Kimondottan jó választás a regripper, de a Helix suite-ben is találhatóak eszközök a registryből történő információkinyerésre. Aki a parancssoros matatást részesíti előnyben, használhatja a linuxos chntpw eszközt is.
2009. április 13., hétfő
Webkioszkok biztonsága
Web- és reklámkioszkokkal sok helyütt találkozhatunk: metrómegállókban, vasútállomásokon, bankfiókokban és sok cég helyez el ilyen eszközöket a főépületek látogatóknak szánt részein (előcsarnok, váróhelység). Egyértelmű, hogy a kioszkok kiválóan alkalmasak imázsépítésre, az ügyfélcentrikus hozzáállás hangsúlyozására, azonban a gyakorlat azt mutatja, hogy gyakran biztonsági kockázatot jelent az eszközök felépítése, használata és a rájuk vonatkozó üzemeltetési gyakorlat: ha valamilyen módon kompromittálni tudjuk a webkioszkot, sok esetben már fogtunk is egy hosztot a védett hálózaton, ahonnét további támadásokat lehet indítani.
A legtöbb "doboz" voltaképpen teljesen hagyományos számítógép: van billentyűzete, boltban kapható alkatrészekből építették össze, és bizony a rajtuk futó operációs rendszer is Microsoft Windows Xp, vagy valamilyen Linux-származék. Ennek megfelelően a támadási módok tekintetében is remekül lehet alkalmazni a jó öreg trükköket. Mindehhez hozzájön az, hogy a kioszkok esetében ritkán frissítik megfelelően az operációs rendszert és a futtatott alkalmazásokat, emiatt hemzseghetnek a kihasználható biztonsági résektől. Webkioszkokra nem szokás személyi tűzfalat, betörésérzékelő rendszert telepíteni, így könnyű célpontnak tekinthetőek.
A helyzetet tovább nehezíti, hogy jelen esetben a "gép" előtt ülő felhasználó is rosszindulatú, és például előzetesen készíthet egy weboldalt, amely végigpróbálgatja az elmúlt időszak összes Internet Explorert/Firefoxot érintő sebezhetőségét: ez esetben annyi a dolga, hogy meglátogatja ezt a webkioszk böngészőjével.
Nyilvánvaló, hogy a kioszkok szoftvereinek készítői is tisztában vannak azzal, hogy milyen biztonsági kockázatot jelent a termékük, és emiatt a lehető legkevesebb funkcionalitást teszik elérhetővé a felhasználó számára. Ha a gép előtt ülő (álló) felhasználó eléri például a futtatási parancsot, akkor egyszerűen tud backdoort telepíteni - céges webkioszk esetében ez gyakorlatilag a hálózati infrastruktúra és akár a teljes hálózati adatforgalom kompromittálását jelenti. A kioszkok operációs rendszerének esetében a funkcionalitás rendszerint megvan a rendszerben, csak a kezelőfelületen tiltják le az adott funkciót előhívó elemet. Például:
Azt szokás mondani, windows alapú webkiosk esetében a játék végét az jelenti, ha a felhasználó tud jobbklikk eseményt generálni: ekkor ugyanis bármely fájlkiválasztó ablakban a c:\windows\system32\cmd.exe-t kiválasztva, máris parancssorhoz juthat. A jobbklikk elleni védekezés naiv megoldása az, amikor fizikailag nincs a kioszk kezelői felületén jobb egérgomb - igen ám, de a shift (ha van) ötszöri megnyomásával aktiválni lehet a "hikomat módot", azaz billentyűleütésekkel előidézni a jobbklikk eseményt. A fájlkiválasztó ablak előcsalása pedig triviális: mindössze egy "file" típusú html mező kell hozzá.
Sok kioszk valamilyen speciális linuxot futtat, általában valamilyen light-weight ablakkezelővel (pl. XFCE): az ilyen kioszkok többnyire ránézésre felismerhetők a GTK2-es kezelőelemekről. Ilyen esetben túlnyomórészt a firefox a böngésző, amit használhatunk: mivel az add-onok telepítéséhez nincs szükség menüre, vagy jobbklikkre, meglehetősen egyszerűen készíthetünk olyan firefox add-ont, amely extra funkcionalitást biztosít (pl. a /bin/bash-t hívhatjuk vele).
A kioszkok legtöbb modellje lehetőséget biztosít adminisztrációs feladatok elvégzésre (a linuxosak nyilván ssh-n, a windowsos gépek pedig többnyire vnc-vel, vagy a beépített RDP szerverrel). Linux alatt meglehetősen egyszerű megtudni, hogy milyen felhasználók vannak az operációs rendszerben: meg kell csak látogatni a file:///etc/passwd "webhelyet".
A kioszkok biztonságának auditálására rendelkezésre áll egy nagyszerű, integrált eszköz, az iKAT (Interactive Kiosk Attacking Tool), amellyel az összes, fenti problémát és még számos egyebet is kipróbálhatunk.
A legtöbb "doboz" voltaképpen teljesen hagyományos számítógép: van billentyűzete, boltban kapható alkatrészekből építették össze, és bizony a rajtuk futó operációs rendszer is Microsoft Windows Xp, vagy valamilyen Linux-származék. Ennek megfelelően a támadási módok tekintetében is remekül lehet alkalmazni a jó öreg trükköket. Mindehhez hozzájön az, hogy a kioszkok esetében ritkán frissítik megfelelően az operációs rendszert és a futtatott alkalmazásokat, emiatt hemzseghetnek a kihasználható biztonsági résektől. Webkioszkokra nem szokás személyi tűzfalat, betörésérzékelő rendszert telepíteni, így könnyű célpontnak tekinthetőek.
A helyzetet tovább nehezíti, hogy jelen esetben a "gép" előtt ülő felhasználó is rosszindulatú, és például előzetesen készíthet egy weboldalt, amely végigpróbálgatja az elmúlt időszak összes Internet Explorert/Firefoxot érintő sebezhetőségét: ez esetben annyi a dolga, hogy meglátogatja ezt a webkioszk böngészőjével.
Nyilvánvaló, hogy a kioszkok szoftvereinek készítői is tisztában vannak azzal, hogy milyen biztonsági kockázatot jelent a termékük, és emiatt a lehető legkevesebb funkcionalitást teszik elérhetővé a felhasználó számára. Ha a gép előtt ülő (álló) felhasználó eléri például a futtatási parancsot, akkor egyszerűen tud backdoort telepíteni - céges webkioszk esetében ez gyakorlatilag a hálózati infrastruktúra és akár a teljes hálózati adatforgalom kompromittálását jelenti. A kioszkok operációs rendszerének esetében a funkcionalitás rendszerint megvan a rendszerben, csak a kezelőfelületen tiltják le az adott funkciót előhívó elemet. Például:
- Nem látszik a Start menü
- Nem lehet (egyszerűen) elérni az Explorer mögött található asztalt
- Nincs "futtatás" parancs
- Nincs "Windows"-gomb
- Nincsenek funkcióbillentyűk
- Nincs jobbklikk
- Stb.
Azt szokás mondani, windows alapú webkiosk esetében a játék végét az jelenti, ha a felhasználó tud jobbklikk eseményt generálni: ekkor ugyanis bármely fájlkiválasztó ablakban a c:\windows\system32\cmd.exe-t kiválasztva, máris parancssorhoz juthat. A jobbklikk elleni védekezés naiv megoldása az, amikor fizikailag nincs a kioszk kezelői felületén jobb egérgomb - igen ám, de a shift (ha van) ötszöri megnyomásával aktiválni lehet a "hikomat módot", azaz billentyűleütésekkel előidézni a jobbklikk eseményt. A fájlkiválasztó ablak előcsalása pedig triviális: mindössze egy "file" típusú html mező kell hozzá.
Sok kioszk valamilyen speciális linuxot futtat, általában valamilyen light-weight ablakkezelővel (pl. XFCE): az ilyen kioszkok többnyire ránézésre felismerhetők a GTK2-es kezelőelemekről. Ilyen esetben túlnyomórészt a firefox a böngésző, amit használhatunk: mivel az add-onok telepítéséhez nincs szükség menüre, vagy jobbklikkre, meglehetősen egyszerűen készíthetünk olyan firefox add-ont, amely extra funkcionalitást biztosít (pl. a /bin/bash-t hívhatjuk vele).
A kioszkok legtöbb modellje lehetőséget biztosít adminisztrációs feladatok elvégzésre (a linuxosak nyilván ssh-n, a windowsos gépek pedig többnyire vnc-vel, vagy a beépített RDP szerverrel). Linux alatt meglehetősen egyszerű megtudni, hogy milyen felhasználók vannak az operációs rendszerben: meg kell csak látogatni a file:///etc/passwd "webhelyet".
A kioszkok biztonságának auditálására rendelkezésre áll egy nagyszerű, integrált eszköz, az iKAT (Interactive Kiosk Attacking Tool), amellyel az összes, fenti problémát és még számos egyebet is kipróbálhatunk.
2009. április 6., hétfő
Webalkalmazások biztonsági hibái - 5. SQL injection
Betörési tesztjeink során gyakran találkozunk azzal a jelenséggel, hogy a weboldalak fejlesztői ugyanazokat a hibákat követik el újra és újra. Ezen klasszikus hibákat egy több részből álló sorozatban szeretnénk bemutatni.
Az SQL injection sebezhetőség a szerveroldali inputvalidációs kontrollok igen népes családjának prominens tagja, viszont önmagában is kiemelt jelentőséggel bír, ezért külön foglalkozunk vele.
Majdnem minden webalkalmazás használ valamilyen formában adatbáziskezelőt háttérrendszerként: kényelmes, gyorsan fejleszthető és megfelelő termékkel kimondottan hatékonyan működtethető infrastruktúrát alkot a webszerver(ek) mögött dolgozó adatbázisszerver. A legtöbb webalkalmazás széleskörű adattárolási feladatokra használja: itt tárolják többek között az üzleti logika adatait, a felhasználóneveket-jelszavakat és az éppen aktuális sessionök azonsítóit is akár. A webportálok felépítéséből és használatából következően viszont előbb-utóbb eljön az a pillanat, amikor felhasználói inputot illeszt SQL query-be - és itt kezdődnek a problémák.
Mi okozza a gondot? Az SQL injection sebezhetőségek abból fakadnak, hogy a webalkalmazást az adatbázis-kezelő rendszer queryértelmezője biztonságos forrásnak hiszi, és készséggel megtesz bármit, amire utasítást ad. Első példaként lássuk az alábbi PHP kódot:
keres.php:
<?php
$query="select * from tabla where id=$_GET['azon'];";
run($query);
?>
Mi itt a probléma? Ha a rosszindulatú felhasználó az alábbi HTTP-kérést adja ki: keres.php?azon=2; drop database; , akkor mi történik? Két SQL queryt kap meg az értelmező, az egyik a select * from tabla where id=2, a másik pedig a drop database lesz. Ha az adatbázis-kezelő lehetővé teszi a kötegelt queryk feldolgozását (például az MS-SQL), készséggel eldobja a második query miatt a teljes adatbázist.
A fenti példa természetesen nagyon naivnak tűnik, de gyakori eset, hogy a webfejlesztők a nem közvetlenül a felhasználótól érkező inputok tekintetében egész egyszerűen megfeledkeznek a validálásról (például hidden html mezők gyakran támadhatók SQL injectionnel).
Milyen támadásokat lehet véghezvinni SQL injectionnel? Néhány lehetőséget sorolunk csak fel, a lista célja annak érzékeltetése, hogy jóval többről van szó, mint néhány adat kompromittálása.
Login felületek megkerülése. Login felületek naiv implementációjában a felhasználó azonosítása ilyesmi SQL query kiadásával történik:
select * from users where uname="$_POST['user']" and passwd="$_POST['pass']";
A query kiadását követően feltételvizsgálat történik, miszerint ha a visszaadott táblának nullánál több sora van (azaz a felhasználónév és a jelszó is megtalálható), a felhasználói authentikációt érvényesnek fogadjuk el. Hogy lehet ezt megkerülni? Ha például az alábbi paraméterezéssel hívjuk meg:
user=admin";--
pass=pass
Mi jön ebből?
select * from users where uname="admin";-- and passwd="pass";
Azaz a query az admin" után terminálódik, az utána lévő részt egész egyszerűen kommentnek tekinti a queryértelmező: nullától különböző sorral tér vissza a query, a felhasználót beengedjük, bár nem írt be megfelelő jelszót. Természetesen nem ez az egyetlen mód, jó tipp például a klasszikus ' or true or ' string beírása mind a felhasználónév, mind a jelszó helyére (ennek végiggondolását az Olvasóra bízzuk).
Adatbázis-kezelő rendszer azonosítása. Az adatbázis-kezelők nagyjából-egészéből ugyanazt az SQL dialektust beszélik, azonban van néhány eset, amelyben ismert, kihasználható módon különböznek egymástól. Ilyen például az, ahogy a szöveges mezőket kezelik. Például elég jól azonosíthatóak az adatbázis-kezelők a sztringek konkatenációjának kezelésével: bármelyik termék hibát dob, ha a másik kettő dialektusával írt queryt kap.
Oracle: 'al'||'ma'
MSSQL: 'al'+'ma'
MySQL: 'al' 'ma' (szóköz a kettő között)
Tetszőleges adat kinyerése az adatbázisból. Ha már sikerült kitörni a queryből, akkor szabad az út, tetszőleges adat kinyeréséhez. Ha például az id paraméterbe aposztrófot írva adatbázishibát kapunk, jó indikátor a hibára: a kitöréshez elég egyetlen input, ami nem megfelelő ellenőrzés után a queryben köt ki - ha ez megvan, a következő lépésként fel kell derítenünk, hogy mennyi és milyen típusú oszlopot ad vissza. Ezt nagyon egyszerűen megtehetjük például az union operátor használatával: a módszer azon alapszik, hogy két SQL query egyesítése csak akkor lehetséges, ha pontosan ugyanannyi oszlopból állnak, amik egymással kompatibilis típusúak (például int oszlop nem illeszthető varchar típusúval a legtöbb esetben). Ha sikerült megtudni a query által visszaadott oszlopok nevét és típusát, az union újbóli használatával tetszőleges adatot (táblaneveket, az adatbázis-kezelőnek és magának a webalkalmazásnak a felhasználóit is akár) kinyerhetünk. A téma meglehetősen szerteágazó, de ezen a linken kimerítő összefoglalót talál az érdeklődő a null értékek és az union összekapcsolásáról.
A teljes operációs rendszer kompromittálása. Az eddig elmondott lehetőségek szorosan véve az adatbázishoz és a benne tárolt adatokhoz kapcsolódnak. Az MS-SQL-ben azonban lehetőség van arra is, hogy parancsokat adjunk ki az SQL szervert futtató account nevében: az xp_cmdshell() tárolt függvény meghívásával nem megfelelően alacsony jogosultságú service account esetén például felhasználót adhatunk hozzá az adatbázis-kezelő rendszerhez, vagy szélsőséges esetben akár a lokális rendszerhez is, illetve megemelhetjük a jogosultságait.
Az SQL injection támadások sikeres kivitelezéséhez először is találunk kell egy olyan paramétert, amellyel valamilyen módon ki tudunk törni az SQL query keretei közül. Numerikus paraméterek esetében a legegyszerűbb ezt megtenni, hiszen nem kell küzdeni az adatbázis-kezelő dialektusától függő "aposztróf vagy idézőjel?!" - témakörrel. A gyakorlat azt mutatja, hogy szöveges paraméterek esetében körülményesebb érvényes query-t összeállítani, ugyanis megfelelő módon terminálni kell a query "beépített" idézőjeleit: az adatbázis-kezelő hibaüzenetei (ha eljutnak a felhasználó böngészőjéig) alapján némi gyakorlattal egyszerűen összeállítható a megfelelő, értelmes query.
Az SQL injection támadásnak van egy speciális fajtája, amely nem igényli, hogy közvetlenül eljussanak a kinyerni kívánt adatok a felhasználó böngészőjéig: blind injection során azt használjuk ki, hogy ha értelmes a query (azaz eredménnyel tér vissza), akkor más lesz az oldal megjelenése, mint amikor hibára fut, illetve nulla találatot ad vissza. Ennek kihasználásával minden lekérdezésnél egy bitnyi információt nyerhetünk ki - például azt, hogy "igaz-e, hogy az adatbázis nevének első betűje A és M között van?". Lassú, alattomos és piszok zajos támadás, de működik.
Hogyan szoktak védekezni SQL injection ellen?
A leggyakoribb ellenlépés az, hogy egész egyszerűen escape-elik a fejlesztők a "speciális", SQL query-k metakaraktereiként ismert karaktereket (idézőjel, aposztróf, pontosvessző, mínuszjel stb.) Ez meglehetősen jó védelmet biztosít a legegyszerűbb SQL injection támadásokkal szemben, viszont nem véd az "SQL smuggling" néven ismeretes módszer ellen. SQL smuggling során kihasználjuk azt, hogy az adatbázis-kezelő rendszerek sok esetben transzparens karakterkonverziót végeznek az "egzotikus" kódolású karakterek esetében. Ha például UTF-8-as kódokkal adjuk meg a karaktereket a beviteli mezőben, az egyszerű "escape-eljük az aposztrófot"-hozzáállás sajnos nem nyújt védelmet.
A legjobb megoldás SQL injection ellen az, ha paraméterezhető tárolt eljárások segítségével érjük el az adatbázist: sajnos az a nagyon egyszerű mód, amikor szövegekből rakjuk össze az SQL query-ket, a legtöbb esetben támadható.
Az SQL injection sebezhetőség a szerveroldali inputvalidációs kontrollok igen népes családjának prominens tagja, viszont önmagában is kiemelt jelentőséggel bír, ezért külön foglalkozunk vele.
Majdnem minden webalkalmazás használ valamilyen formában adatbáziskezelőt háttérrendszerként: kényelmes, gyorsan fejleszthető és megfelelő termékkel kimondottan hatékonyan működtethető infrastruktúrát alkot a webszerver(ek) mögött dolgozó adatbázisszerver. A legtöbb webalkalmazás széleskörű adattárolási feladatokra használja: itt tárolják többek között az üzleti logika adatait, a felhasználóneveket-jelszavakat és az éppen aktuális sessionök azonsítóit is akár. A webportálok felépítéséből és használatából következően viszont előbb-utóbb eljön az a pillanat, amikor felhasználói inputot illeszt SQL query-be - és itt kezdődnek a problémák.
Mi okozza a gondot? Az SQL injection sebezhetőségek abból fakadnak, hogy a webalkalmazást az adatbázis-kezelő rendszer queryértelmezője biztonságos forrásnak hiszi, és készséggel megtesz bármit, amire utasítást ad. Első példaként lássuk az alábbi PHP kódot:
keres.php:
<?php
$query="select * from tabla where id=$_GET['azon'];";
run($query);
?>
Mi itt a probléma? Ha a rosszindulatú felhasználó az alábbi HTTP-kérést adja ki: keres.php?azon=2; drop database; , akkor mi történik? Két SQL queryt kap meg az értelmező, az egyik a select * from tabla where id=2, a másik pedig a drop database lesz. Ha az adatbázis-kezelő lehetővé teszi a kötegelt queryk feldolgozását (például az MS-SQL), készséggel eldobja a második query miatt a teljes adatbázist.
A fenti példa természetesen nagyon naivnak tűnik, de gyakori eset, hogy a webfejlesztők a nem közvetlenül a felhasználótól érkező inputok tekintetében egész egyszerűen megfeledkeznek a validálásról (például hidden html mezők gyakran támadhatók SQL injectionnel).
Milyen támadásokat lehet véghezvinni SQL injectionnel? Néhány lehetőséget sorolunk csak fel, a lista célja annak érzékeltetése, hogy jóval többről van szó, mint néhány adat kompromittálása.
Login felületek megkerülése. Login felületek naiv implementációjában a felhasználó azonosítása ilyesmi SQL query kiadásával történik:
select * from users where uname="$_POST['user']" and passwd="$_POST['pass']";
A query kiadását követően feltételvizsgálat történik, miszerint ha a visszaadott táblának nullánál több sora van (azaz a felhasználónév és a jelszó is megtalálható), a felhasználói authentikációt érvényesnek fogadjuk el. Hogy lehet ezt megkerülni? Ha például az alábbi paraméterezéssel hívjuk meg:
user=admin";--
pass=pass
Mi jön ebből?
select * from users where uname="admin";-- and passwd="pass";
Azaz a query az admin" után terminálódik, az utána lévő részt egész egyszerűen kommentnek tekinti a queryértelmező: nullától különböző sorral tér vissza a query, a felhasználót beengedjük, bár nem írt be megfelelő jelszót. Természetesen nem ez az egyetlen mód, jó tipp például a klasszikus ' or true or ' string beírása mind a felhasználónév, mind a jelszó helyére (ennek végiggondolását az Olvasóra bízzuk).
Adatbázis-kezelő rendszer azonosítása. Az adatbázis-kezelők nagyjából-egészéből ugyanazt az SQL dialektust beszélik, azonban van néhány eset, amelyben ismert, kihasználható módon különböznek egymástól. Ilyen például az, ahogy a szöveges mezőket kezelik. Például elég jól azonosíthatóak az adatbázis-kezelők a sztringek konkatenációjának kezelésével: bármelyik termék hibát dob, ha a másik kettő dialektusával írt queryt kap.
Oracle: 'al'||'ma'
MSSQL: 'al'+'ma'
MySQL: 'al' 'ma' (szóköz a kettő között)
Tetszőleges adat kinyerése az adatbázisból. Ha már sikerült kitörni a queryből, akkor szabad az út, tetszőleges adat kinyeréséhez. Ha például az id paraméterbe aposztrófot írva adatbázishibát kapunk, jó indikátor a hibára: a kitöréshez elég egyetlen input, ami nem megfelelő ellenőrzés után a queryben köt ki - ha ez megvan, a következő lépésként fel kell derítenünk, hogy mennyi és milyen típusú oszlopot ad vissza. Ezt nagyon egyszerűen megtehetjük például az union operátor használatával: a módszer azon alapszik, hogy két SQL query egyesítése csak akkor lehetséges, ha pontosan ugyanannyi oszlopból állnak, amik egymással kompatibilis típusúak (például int oszlop nem illeszthető varchar típusúval a legtöbb esetben). Ha sikerült megtudni a query által visszaadott oszlopok nevét és típusát, az union újbóli használatával tetszőleges adatot (táblaneveket, az adatbázis-kezelőnek és magának a webalkalmazásnak a felhasználóit is akár) kinyerhetünk. A téma meglehetősen szerteágazó, de ezen a linken kimerítő összefoglalót talál az érdeklődő a null értékek és az union összekapcsolásáról.
A teljes operációs rendszer kompromittálása. Az eddig elmondott lehetőségek szorosan véve az adatbázishoz és a benne tárolt adatokhoz kapcsolódnak. Az MS-SQL-ben azonban lehetőség van arra is, hogy parancsokat adjunk ki az SQL szervert futtató account nevében: az xp_cmdshell() tárolt függvény meghívásával nem megfelelően alacsony jogosultságú service account esetén például felhasználót adhatunk hozzá az adatbázis-kezelő rendszerhez, vagy szélsőséges esetben akár a lokális rendszerhez is, illetve megemelhetjük a jogosultságait.
Az SQL injection támadások sikeres kivitelezéséhez először is találunk kell egy olyan paramétert, amellyel valamilyen módon ki tudunk törni az SQL query keretei közül. Numerikus paraméterek esetében a legegyszerűbb ezt megtenni, hiszen nem kell küzdeni az adatbázis-kezelő dialektusától függő "aposztróf vagy idézőjel?!" - témakörrel. A gyakorlat azt mutatja, hogy szöveges paraméterek esetében körülményesebb érvényes query-t összeállítani, ugyanis megfelelő módon terminálni kell a query "beépített" idézőjeleit: az adatbázis-kezelő hibaüzenetei (ha eljutnak a felhasználó böngészőjéig) alapján némi gyakorlattal egyszerűen összeállítható a megfelelő, értelmes query.
Az SQL injection támadásnak van egy speciális fajtája, amely nem igényli, hogy közvetlenül eljussanak a kinyerni kívánt adatok a felhasználó böngészőjéig: blind injection során azt használjuk ki, hogy ha értelmes a query (azaz eredménnyel tér vissza), akkor más lesz az oldal megjelenése, mint amikor hibára fut, illetve nulla találatot ad vissza. Ennek kihasználásával minden lekérdezésnél egy bitnyi információt nyerhetünk ki - például azt, hogy "igaz-e, hogy az adatbázis nevének első betűje A és M között van?". Lassú, alattomos és piszok zajos támadás, de működik.
Hogyan szoktak védekezni SQL injection ellen?
A leggyakoribb ellenlépés az, hogy egész egyszerűen escape-elik a fejlesztők a "speciális", SQL query-k metakaraktereiként ismert karaktereket (idézőjel, aposztróf, pontosvessző, mínuszjel stb.) Ez meglehetősen jó védelmet biztosít a legegyszerűbb SQL injection támadásokkal szemben, viszont nem véd az "SQL smuggling" néven ismeretes módszer ellen. SQL smuggling során kihasználjuk azt, hogy az adatbázis-kezelő rendszerek sok esetben transzparens karakterkonverziót végeznek az "egzotikus" kódolású karakterek esetében. Ha például UTF-8-as kódokkal adjuk meg a karaktereket a beviteli mezőben, az egyszerű "escape-eljük az aposztrófot"-hozzáállás sajnos nem nyújt védelmet.
A legjobb megoldás SQL injection ellen az, ha paraméterezhető tárolt eljárások segítségével érjük el az adatbázist: sajnos az a nagyon egyszerű mód, amikor szövegekből rakjuk össze az SQL query-ket, a legtöbb esetben támadható.
2009. április 1., szerda
Nyomtatók hackelése
A tegnapi posztban szó esett arról, hogy nyomtatókat is lehet hackelni - kaptunk néhány visszajelzést arra vonatkozóan, hogy esetleg kicsit mélyebben is körbejárhatnánk a témát.
Hálózati nyomtatókkal kiemelten nem, vagy legalábbis meglehetősen kevéssé foglalkoznak az irányadó betörési módszertanok, noha meglehetősen ingoványos területről beszélünk. A nyomtatókkal a hálózati védelmi mechanizmusok kialakításánál sok esetben meglehetősen mostohán bánnak: beállítják őket, kapnak egy kábelt az aljzatból és kész, lehet is használni. Miért érdemes mégis foglalkozni velük?
A hálózati nyomtatók igazából önálló számítógépek, csak speciális csomagolásban laknak és váratlan funkciókat biztosítanak: operációs rendszerük van, TCP/IP-s protokollstackjük, gyakran sokfajta szolgáltatást nyújtanak (gyakori, hogy ftp, telnet és http szerverként is üzemelnek).
Másrészről a legtöbb nyomtató nem tartozik a túlbiztosított eszközök körébe - ha vannak is védelmi mechanizmusok az egyes beállításokkal, szolgáltatásokkal kapcsolatosan, a legtöbb esetben könnyedén kikerülhetőek (például a HP nyomtatóinak egy sorozata SNMP-n keresztül elárulja az adminisztrációs jelszót).
A harmadik roppant szimpatikus vonás a nyomtatókban az, hogy a HPLJ 9100-as portján keresztül mindenféle hitelesítés nélkül lehet csatlakozni, és az itt kiadott parancsokkal elég mélyrehatóan lehet állítgatni a nyomtató lelkivilágán. A megfelelő eszközzel csatlakozva könnyedén turkálhatunk a nyomtató fájlrendszerében, a környezeti paramétereken és egyéb beállításokban - mindezt a legtöbb esetben jelszó nélkül.
Milyen támadásokat lehet végrehajtani egy nyomtatóval a hálózaton?
Hálózati nyomtatókkal kiemelten nem, vagy legalábbis meglehetősen kevéssé foglalkoznak az irányadó betörési módszertanok, noha meglehetősen ingoványos területről beszélünk. A nyomtatókkal a hálózati védelmi mechanizmusok kialakításánál sok esetben meglehetősen mostohán bánnak: beállítják őket, kapnak egy kábelt az aljzatból és kész, lehet is használni. Miért érdemes mégis foglalkozni velük?
A hálózati nyomtatók igazából önálló számítógépek, csak speciális csomagolásban laknak és váratlan funkciókat biztosítanak: operációs rendszerük van, TCP/IP-s protokollstackjük, gyakran sokfajta szolgáltatást nyújtanak (gyakori, hogy ftp, telnet és http szerverként is üzemelnek).
Másrészről a legtöbb nyomtató nem tartozik a túlbiztosított eszközök körébe - ha vannak is védelmi mechanizmusok az egyes beállításokkal, szolgáltatásokkal kapcsolatosan, a legtöbb esetben könnyedén kikerülhetőek (például a HP nyomtatóinak egy sorozata SNMP-n keresztül elárulja az adminisztrációs jelszót).
A harmadik roppant szimpatikus vonás a nyomtatókban az, hogy a HPLJ 9100-as portján keresztül mindenféle hitelesítés nélkül lehet csatlakozni, és az itt kiadott parancsokkal elég mélyrehatóan lehet állítgatni a nyomtató lelkivilágán. A megfelelő eszközzel csatlakozva könnyedén turkálhatunk a nyomtató fájlrendszerében, a környezeti paramétereken és egyéb beállításokban - mindezt a legtöbb esetben jelszó nélkül.
Milyen támadásokat lehet végrehajtani egy nyomtatóval a hálózaton?
- A kinyomtatott/elfaxolt anyagok kinyerése. A legtöbb hálózati nyomtatónak több-kevesebb memóriája van, amelyben forgalomcsökkentési okokból tárolják egy ideig a kinyomtatott jobokat. A hijetter eszközzel meglehetősen kényelmesen lehet turkálni a nyomtató memóriájában.
- DoS támadás a nyomtató alhálózata ellen: a hálózati nyomtatók hálózati beállításaiban átírhatjuk az IP-címét a default gw címére, ami legalábbis egy ideig, meglehetősen rosszul esik a hálózatnak.
- Tökéletes tárolási hely sniffer logoknak, ugyanis a nyomtatón üzemelő webszerver wwwrootjába pakolva, elérhető a http://nyomtato/hp/device/sniffer.log címen. Másrészről az üzemeltetésről ki keresne gyanús forgalmat a nyomtató felé menő forgalomban?
- Social engineering. Az egyik legfinomabb csemege, amit a nyomtatóval tenni lehet, az a kijelzőn található szöveg megváltoztatása. Adott esetben le is lehet tiltani az összes gombot a kezelőfelületen, és megjeleníteni az "Ismeretlen hiba #9927" hiba feliratot - ekkor a tesztelőnek annyi a feladata, hogy amikor elég magasra csap a pánik lángja, felhívja a nyomtató előtt idegesen ácsorgó, mérsékelten biztonságtudatos felhasználót: "Csókolom, a helpdeskről telefonálok. Tapasztaltak hibát a nyomtatással ma délután? Igen? Ó, önöket is elérte. Igen, tudunk a problémáról, és most gyorsan ki is tudjuk javítani, csak ezt a kis frissítést kell letölteni a gépére... mondom a címet. Há-té-té-pé-kettőspont-per-per-vévévépont..."
- Papírpazarolás. Bővebb kommentár nem szükséges hozzá - sok nyomtató (főleg a régebbi típusok) egész egyszerűen kinyomtatja a 9100-as portjára küldött szöveget, ez pedig mérhetetlenül bántja a környezettudatos tesztelőt és szkennelőeszköz-készítőt és ebből következően kihagyja a 9100-as port naiv szolgáltatásfelderítését.
- Zombiként lehet használni idle scan támadáshoz. A portscannelés legosonósabb módja az úgynevezett idle scanning, amikor egy tétlen, egyszerű, hálózatra kötött eszköz forgalmát manipuláljuk úgy, hogy a célpont a zombit érzékelje scannerként. A nyomtatók nagyon hálásak, ugyanis több esetben tapasztaltuk white-box vizsgálatoknál, hogy a nyomtatók felől jövő forgalmat nem szűrik a tűzfalakon.
- Hálózati eszközökről lévén szó, a klasszikus hálózati támadások (forgalomelterelés, floodolás stb.) teljesen korrektül működnek ellenük. Céleszközökről lévén szó, nincs bennük floodvédelem vagy tűzfal sem.
Feliratkozás:
Bejegyzések (Atom)
