SQL csonkítási támadás

Az SQL csonkítás biztonsági rése akkor fordul elő, amikor egy adatbázis a hosszúság korlátozása miatt megcsonkítja a felhasználói bevitelt. A támadók információkat gyűjthetnek a kritikus mezők hosszáról (például felhasználónév), és kihasználhatják ezeket az információkat illetéktelen hozzáférés megszerzéséhez. A támadók más felhasználóként, például rendszergazdaként jelentkezhetnek be a saját regisztrált jelszavukkal.

SQL csonkolási sebezhetőség általában a MySQL adatbázisokban található. Ezt a biztonsági rést először a CVE-2008-4106 írta le, amely a WordPress CMS-hez kapcsolódott.

Hogyan működnek az SQL csonkítási támadások

Ez a támadás az adatbázisokban a felhasználói bevitel csonkolása miatt működik, a „kiválasztás” és a „beillesztés” funkcióval.

• Amikor az űrlapmezőben megadjuk a bemenetet, a 'select' funkció ellenőrzi az adatbázisban lévő bemeneteknek megfelelő redundanciát.
• A redundancia ellenőrzése után a 'beszúrás' funkció ellenőrzi a bemenet hosszát, és a felhasználói bemenet csonkol, ha a hossz meghaladja.

Tegyük fel, hogy egy fejlesztő a következő lekérdezéssel hozza létre a „felhasználók” táblázatot:

hozzon létre tábla felhasználókat (
user_id INT NEM NULL AUTO_INCREMENT,
felhasználónév VARCHAR (20) NEM NULL,
jelszó VARCHAR (40) NEM NULL,
ELSŐDLEGES KULCS (felhasználói azonosító)
);

Ennek a sémának a használatával, ha a fejlesztő egy adminisztrátori fiókot hoz létre az alábbiakkal:

user_name = 'admin'
jelszó = “secret_p4ssw0ord”

Ezek a bizonylatok nyilvánvalóan nem nyilvánosak. Csak egy adminisztrátori fiók van az adatbázisban, és ha a támadó megpróbál másik fiókot regisztrálni az 'admin' felhasználónévvel, akkor a támadó az adatbázis redundanciaellenőrzése miatt meghiúsul. A támadó továbbra is megkerülheti ezt a redundancia-ellenőrzést, és újabb rendszergazdai fiókot adhat hozzá az SQL csonkítás biztonsági résének kihasználásával. Tegyük fel, hogy a támadó egy másik fiókot regisztrál a következő bemenettel:

Felhasználónév = 'adminxxxxxxxxxxxxxxxxxrandom'
(x a szóköz)
&
Jelszó = "RandomUser"

Az adatbázis felveszi a 'user_name' nevet (26 karakter), és ellenőrzi, hogy ez létezik-e már. Ezután a user_name bemenet meg lesz csonkolva, és az "admin" ("admin" szóközzel) be lesz írva az adatbázisba, ami két duplikált admin felhasználót eredményez.

A támadó ezután képes létrehozni egy „admin” felhasználót saját jelszavával. Most az adatbázis két rendszergazda 'user_name' bejegyzéssel rendelkezik, de különböző jelszavakkal. A támadó bejelentkezhet az újonnan létrehozott hitelesítő adatokkal, hogy adminisztrációs panelt szerezzen, mivel az „admin” és az „admin” felhasználói név egyaránt megegyezik az adatbázis szintjével. Most megnézzük a gyakorlati támadás mintáját.

Támadásminta

Ebben a példában egy forgatókönyvet veszünk fel a overthewire webhelyről.org. Az overthewire közösség olyan wargame CTF-eket biztosít, amelyeken gyakorolhatjuk a biztonsági koncepcióinkat. Az SQL-csonkítás forgatókönyve a natas 26-> 27-es szintű játékban fordul elő. A szintet a következők segítségével érhetjük el:

URL: http: // natas27.natas.laboratóriumok.overthewire.org
Felhasználónév: natas27
Jelszó: 55TBjpPZUUJgVP5b3BnbG6ON9uDPVzCJ

Ez a szint a következő címen érhető el: https: // overthewire.org / wargames / natas / natas27.html. Megjelenik egy bejelentkezési oldal, amely sebezhető egy SQL csonkítási támadással szemben.

A forráskód átvizsgálásakor látni fogja, hogy a felhasználónév hossza 64, amint az alább látható.

A „natas28” nevű felhasználó már létezik. Célunk egy másik „natas28” nevű felhasználó létrehozása az SQL_truncation támadás segítségével. Tehát beírjuk a natas28-at, majd 57 szóközt és egy véletlenszerű ábécét (esetünkben a), felhasználónevet és bármilyen jelszót. Az „a” betű nem látható a képernyőképen, a 65 karakteres felhasználónév miatt. A felhasználói fiók létrehozása után láthatja a 'a."

Ha az adatbázis tartalmaz sql_truncation sebezhetőséget, akkor az adatbázisnak most két „natas28” felhasználónevet kell tartalmaznia. Egy felhasználónév tartalmazza a jelszavunkat. Próbáljuk meg megadni a hitelesítő adatokat a bejelentkezési oldalon.

Most 'natas28' felhasználóként vagyunk bejelentkezve.

Enyhítés

A támadás enyhítéséhez több tényezőt is figyelembe kell vennünk.

• Nem szabad megengednünk a kritikus identitások, például a felhasználónév megkettőzését. Ezeket az identitásokat elsődleges kulcsokká kell tennünk.
• A csonkolási funkciót a frontend űrlapok összes mezőjéhez, valamint a háttérprogram kódjához kell megvalósítani, hogy az adatbázisok csonkolt bemeneteket fogadjanak.
• A szigorú módot engedélyezni kell az adatbázis szintjén. A szigorú mód engedélyezése nélkül az adatbázisok csak figyelmeztetéseket adnak a háttérprogramban, de a duplikált adatokat elmentik. Szigorú üzemmód esetén az adatbázisok hibákat okoznak duplikáció esetén, és elkerülik az adatok mentését.

Ellenőrizzük például a szigorú módot a következő lekérdezéssel:

mysql> select @@ sql_mode

Létrehozunk egy adatbázist és a tábla felhasználóit."

mysql> CREATE DATABASE teszt
Lekérdezés rendben, 1 sor érintett (0.02 mp)
mysql> Test használata
Az adatbázis megváltozott
mysql> CREATE TABLE felhasználók (VARCHAR felhasználónév (10), jelszó VARCHAR (10));
Lekérdezés rendben, 0 sor érintett (0.05 mp)

Ezután létrehozunk egy rendszergazdai felhasználót hitelesítő adatokkal az INSERT lekérdezés segítségével.

mysql> INSERT INTO users VALUES ('admin', 'password1');
Lekérdezés rendben, 1 sor érintett (0.01 mp)

A „felhasználók” táblázat információit a „select * from users” opcióval láthatjuk.

A felhasználónév hossza 10 karakter. Most megpróbáljuk az SQL csonkítási támadást.

Amikor megpróbáljuk beírni a következőket:

Felhasználónév = 'adminxxxxxa'
(x a szóköz)
&
Jelszó = 'pass2'

Hibát kapunk, ami azt jelenti, hogy a szigorú mód teljesen hatékony.

mysql> INSERT INTO felhasználói értékek ('admin a', 'pass2')
1406 (22001) HIBA: Az adatok túl hosszúak az 1. sor „felhasználónév” oszlopához

A szigorú mód engedélyezése nélkül az adatbázis figyelmeztetéseket ad ki, de az adatokat továbbra is beilleszti a táblázatba.

Következtetés

A támadók nagy jogosultságú fiókokhoz férhetnek hozzá, ha az sql_trunction sebezhetőség létezik az alkalmazásban. A támadó a kritikus mezők segítségével könnyedén megszerezheti az információkat a felhasználónévről és az adatbázis hosszúságáról, majd létrehozhatja ugyanazt a felhasználónevet, amelyet a minimális hosszúság után szóközök és véletlenszerű ábécé követnek, ami több nagyjogosultságú fiók létrehozását eredményezi. Ez a biztonsági rés kritikus fontosságú, de elkerülhető, ha bizonyos biztonsági óvintézkedéseket tesz, például aktiválja a szigorú módot a felhasználói bemeneteknél, és az érzékeny mezőt az adatbázis elsődleges kulcsává teszi.