Az egyik leggyakrabban felvetődő kérdés, amit SQL injection témában nekem szegeznek az, hogy mégis hogyan valósítható meg a gyakorlatban az "SQL smuggling" néven elhíresült támadási forma? A legenda szerint ezen módszer felhasználásával bizonyos escape-elési eljárások megkerülhetők, mivel a bemenetellenőrzést végző alkalmazás a különböző karakterkészlet-beállítások miatt az adatbáziskiszolgálótól eltérően értelmezi a potenciálisan veszélyes karaktereket. Őszintén szólva az én ismereteim sem voltak kimerítőek a témában (és valószínűleg még mindig nem azok), de a CCC-n EQ unszolására ("Most hackelni jöttél vagy Fluxboxot konfigolni?" ;) újra elővettem a régi leírást, és azt hiszem sikerült meglátnom a fényt az alagút végén:
A Comsec-féle tanulmány egyrészt több, gyakran előforduló programozói hibát, illetve IDS-megkerülési módot mutat be, de ezek nem jelentenek különösebb izgalmat. Az érdekes rész a Unicode Smuggling fejezetben kezdődik, ahol a szerző felveti, hogy a különböző karaktertáblák hasonlóan kinéző karaktereit egymásba átvívő "homoglifikus" (a rangidős nyelvész kérem javítson ki!) transzformációk bizony biztonsági kockázatot rejtenek magukban. Azaz, pl. az Ā karaktert a DBMS okosan A-vá alakítja, a sokféle szemita felülvonást pedig ASCII aposztróffá. A probléma ott van, hogy mégis mely adatbáziskezelők végeznek ilyenfajta váratlan átalakításokat a bemeneten? A hivatkozott tanulmány csak annyit mond, hogy az MS SQL Server 2005 már nem, valamint hogy a MySQL egyes régebbi Java connectorai még lehetővé tettek ilyen támadásokat. Nem sok.
Ha kicsit jobban utánajárunk a dolognak, észrevehetjük, hogy SQL Smugglinggal kapcsolatban szinte kizárólag az eredeti Comcast-féle tanulmány különböző hivatkozásait találjuk, konkrét esettanulmányokat nem. Támpontként leginkább egy régi Bugtraq-os szálat használhatunk, melyben többen kritizálják a tanulmányt, mondván, hogy itt szó sincs új típusú támadásokról, egyszerűen néhány régimódi hibatípust fedeztek fel újra.
Emellett ugyanakkor találunk néhány gyakorlati példát is: David Litchfield például a PLSQL-ben alkalmazott tárolt-eljárás-feketelista (grammarnazis, help me!) megkerülésére mutatott példát még 2001-ben. Itt a problémát az okozta, hogy a PLSQL a ÿ karaktert Y-á konvertálta, de a SYS.* tárolt eljárásokra vonatkozó szabályok nem kerültek érvényesítésre. Gary Oleary-Steel egy Ruby szkriptet tett közzé, melyet IIS-el tesztelt, de bővebb információ nem áll rendelkezésre arról, hogy hogyan.
EQ-val elvégeztünk egy csomó tesztet MySQL-lel szemben, de nem siekrült még csak aggodalomra okot adó viselkedést sem kicsikarnunk a kiszolgálóból.
Úgy tűnik tehát, hogy az SQL Smuggling lényegében ráhúzható minden DBMS, webszerver vagy interpreter bugra, ami nem kezeli megfelelően a speciális karaktereket, ezeket viszont az érintett gyártók általában hamar javítják, az egyszer programozónak/üzemeltetőnek pedig nincs sok ráhatása az ilyen problémák megelőzésére. Az egyetlen gondot az így-úgy összebarkácsolt szűrőeljárások jelenthetik, de ezeket általában akkor is megkerüli az ember előbb vagy utóbb, ha nem tudja mi is az az SQL Smuggling.
Szóval használjatok naprakész szoftvereket, és ne próbáljátok meg feltalálni a spanyolviaszt, ha pedig behatolástesztelésre kerül a sor, a sebezhetőség-adatbázisok környékén kell kutakodni, mert úgy tűnik, nem létezik varázsmódszer a jól ellenőrzött SQL paraméterekkel és előkészített lekérdezésekkel szemben.
Még egyszer köszönet EQ-nak a motivációért és a segítségért!
