Hogyan hackerek átveszik a webhelyeket SQL befecskendezéssel és DDoS-sel
Még akkor is, ha csak lazán követte az Anonymous és a LulzSec hacker csoportok eseményeit, valószínűleg hallott a webhelyekről és a szolgáltatásokról, amelyeket hackelnek, mint a hírhedt Sony hacks. Elgondolkozott már valaha, hogyan csinálják?
Számos eszközt és technikát használnak, amelyeket ezek a csoportok használnak, és bár nem próbálunk Önnek egy kézikönyvet adni magának, hasznos megérteni, hogy mi történik. A támadások közül kettő, amit állandóan hallasz róluk, a „(Distributed) Denial of Service” (DDoS) és az „SQL Injections” (SQLI). Itt vannak, hogyan működnek.
Kép: xkcd
Szolgáltatási támadás megtagadása
Mi az?
A „szolgáltatásmegtagadás” (néha „elosztott megtagadási szolgáltatás” vagy „DDoS”) támadás akkor fordul elő, amikor egy rendszer, ebben az esetben egy webszerver, annyi kérést kap, hogy a szerver erőforrások túlterheltek, a rendszer egyszerűen zárol és leáll. A sikeres DDoS támadás célja és eredménye a célkiszolgáló webhelyei nem érhetők el a jogos forgalmi kérésekhez.
Hogyan működik?
A DDoS támadás logisztikája legjobban egy példával magyarázható.
Képzeld el, hogy egymillió ember (a támadók) összejönnek azzal a céllal, hogy megakadályozzák a vállalat X üzleti tevékenységét azáltal, hogy leállítják a call centerüket. A támadók úgy koordinálják, hogy kedden este 9-kor hívják a X-es telefonszámát. Valószínűleg az X-es vállalat telefonrendszere nem képes egyszerre egymillió hívást kezelni, így az összes bejövő vonalat a támadók kötik össze. Az eredmény az, hogy a törvényes ügyfélhívások (azaz azok, amelyek nem a támadók) nem jutnak át, mert a telefonrendszer a támadóktól érkező hívásokat kezeli. Tehát az X vállalat lényegében elveszítheti az üzleti tevékenységet, mivel a jogos kérések nem tudnak átjutni.
A webszerver DDoS támadása pontosan ugyanúgy működik. Mivel gyakorlatilag semmilyen módon nem lehet tudni, hogy a forgalom milyen jogosultsággal érkezett a támadókkal szemben, amíg a webkiszolgáló feldolgozza a kérést, az ilyen típusú támadás jellemzően nagyon hatékony.
A támadás végrehajtása
A DDoS támadás „brutális erő” jellege miatt sok számítógépet kell összehangolni, hogy egy időben támadjanak. A hívásközpont példájának felülvizsgálatához ez megkövetelné, hogy mind a támadók mindketten tudják, hogy hívják a 9 órát, és abban az időben hívják. Bár ez az elv minden bizonnyal akkor fog működni, amikor egy webszerver támadására van szükség, akkor lényegesen könnyebbé válik, ha a zombi számítógépeket a ténylegesen személyi számítógépek helyett használják..
Ahogy valószínűleg tudja, sok kártevő és trójai változata létezik, amelyek egyszer a rendszeredben nyugvóak és néha „telefonos otthonok”. Ezeknek az utasításoknak az egyik lehet például az, hogy ismételt kéréseket küldjön a X vállalat vállalatszerverére 9 órakor. Tehát egyetlen rosszindulatú támadó az egyetlen rosszindulatú számítógép otthoni helyének egyetlen frissítésével azonnal koordinálhatja a veszélyeztetett számítógépek több százezerét, hogy hatalmas DDoS támadást hajtson végre.
A zombi számítógépek használatának szépsége nemcsak annak hatékonysága, hanem anonimitása is, mivel a támadónak nem kell egyáltalán használni a számítógépét a támadás végrehajtásához..
SQL befecskendezési támadás
Mi az?
Az „SQL injekció” (SQLI) támadás olyan kihasználás, amely kihasználja a rossz webfejlesztési technikákat, és jellemzően hibás adatbázis-biztonsággal kombinálva. A sikeres támadás eredményeképpen a felhasználói fiók megszemélyesítése a teljes adatbázis vagy szerver kompromisszumáig terjedhet. A DDoS támadással ellentétben az SQLI támadás teljesen és könnyen megelőzhető, ha egy webes alkalmazás megfelelően programozott.
A támadás végrehajtása
Amikor bejelentkezik egy webhelyre, és megadja felhasználónevét és jelszavát, a hitelesítő adatok teszteléséhez a webalkalmazás lekérdezheti a következőket:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "myuser" ÉS Jelszó = "mypass";
Megjegyzés: Az SQL lekérdezésben szereplő karakterlánc értékeket egyetlen idézőjelbe kell foglalni, ezért jelennek meg a felhasználó által megadott értékek körül.
Tehát a megadott felhasználói név (myuser) és a jelszó (mypass) kombinációjának meg kell egyeznie a Felhasználók táblázatban szereplő bejegyzésekkel annak érdekében, hogy a felhasználói azonosítót vissza lehessen küldeni. Ha nincs egyezés, a felhasználói azonosító nem kerül visszaadásra, így a bejelentkezési adatok érvénytelenek. Bár egy adott megvalósítás eltérhet, a mechanika eléggé szabványos.
Most nézzük meg a sablon hitelesítési lekérdezést, amelyet helyettesíthetünk a felhasználó által a webes űrlapon megadott értékekkel:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "[user]" és jelszó = "[pass]"
Első pillantásra ez egyszerűnek és logikus lépésnek tűnhet a felhasználók egyszerű validálásához, azonban ha a felhasználó által megadott értékek egyszerű helyettesítése történik ezen a sablonon, akkor érzékeny az SQLI támadásra.
Tegyük fel például, hogy a „myuser” - a felhasználói név mezőbe kerül, és a jelszóba be van írva a „hibakeresés”. Egyszerű helyettesítés használatával sablon lekérdezésünkben ezt kapjuk:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "myuser" - 'ÉS Jelszó = "hibás"
Ennek a kijelentésnek a kulcsa a két kötőjel felvétele (-). Ez az SQL utasítások megjegyzés kezdőjelzője, így a két kötőjel (beleértve) után megjelenő mindent figyelmen kívül hagyunk. Lényegében a fenti lekérdezést az adatbázis hajtja végre:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "myuser"
A ragyogó mulasztás itt a jelszó-ellenőrzés hiánya. A két kötőjelet a felhasználói mező részévé téve teljesen kiiktattuk a jelszó-ellenőrzési feltételt, és „myuser” -ként tudtunk bejelentkezni anélkül, hogy tudnánk a megfelelő jelszót. Ez a cselekmény a lekérdezés manipulálására a nem kívánt eredmények előállítására egy SQL injekciós támadás.
Milyen kárt okozhat?
Az SQL injekciós támadást a gondatlan és felelőtlen alkalmazáskódolás okozza, és teljesen megakadályozható (amit egy pillanat alatt lefedünk), de a kár mértéke az adatbázis beállításától függ. Ahhoz, hogy egy webalkalmazás kommunikálhasson a backend adatbázisával, az alkalmazásnak bejelentkeznie kell az adatbázishoz (megjegyzés, ez más, mint a felhasználó belépése a webhelyre). Attól függően, hogy milyen jogosultságokat igényel a webalkalmazás, a megfelelő adatbázis-fióknak csak a meglévő táblák olvasási / írási engedélyétől lehet szüksége a teljes adatbázis-hozzáférésre. Ha ez most már nem világos, néhány példának segítenie kell valamilyen egyértelműséget.
A fenti példa alapján láthatjuk, hogy például belépünk, "youruser" - "," admin "-" vagy bármely más felhasználói név, azonnal beléphetünk a webhelyre, mint a felhasználó anélkül, hogy tudnánk a jelszót. Miután a rendszerben vagyunk, nem tudjuk, hogy valójában nem vagyunk a felhasználók, így teljes körű hozzáférést biztosítunk az adott fiókhoz. Az adatbázis-jogosultságok nem biztosítanak biztonsági hálózatot erre, mivel általában egy webhelynek legalább olvasási / írási hozzáféréssel kell rendelkeznie az adott adatbázishoz.
Most feltételezzük, hogy a webhely teljes mértékben ellenőrzi a megfelelő adatbázist, amely lehetővé teszi a rekordok törlését, táblázatok hozzáadását / eltávolítását, új biztonsági fiókok hozzáadását, stb. Fontos megjegyezni, hogy egyes webalkalmazásoknak ilyen típusú engedélyre van szükségük nem egy rossz dolog, hogy teljes körű ellenőrzést adnak.
Az ily módon bekövetkezett károk illusztrálására tehát a fenti képregényben szereplő példát az alábbi nevet adja meg a felhasználói név mezőbe: "Robert"; DROP TABLE Felhasználók; - ". Egyszerű helyettesítés után a hitelesítési lekérdezés:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "Robert"; DROP TABLE Felhasználók; - 'ÉS Jelszó = "hibás"
Megjegyzés: a pontosvessző SQL lekérdezésben van megadva egy adott utasítás végének és egy új utasítás kezdetének jelzésére.
Amelyet az adatbázis hajt végre:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "Robert"DROP TABLE Felhasználók
Tehát éppen úgy, hogy egy SQLI támadást használtunk fel a teljes Felhasználók táblázat törléséhez.
Természetesen sokkal rosszabb is lehet, mivel az engedélyezett SQL-engedélyektől függően a támadó megváltoztathatja az értékeket, a táblázatokat (vagy az egész adatbázist) egy szövegfájlra, új bejelentkezési fiókokat hozhat létre, vagy akár az egész adatbázis-telepítést is lekophatja.
SQL injekciós támadás megelőzése
Ahogy korábban már többször említettük, az SQL injekciós támadás könnyen megelőzhető. A webfejlesztés egyik alapvető szabálya, hogy soha nem vakon bizalmasan bízik meg a felhasználó bevitelét, mint ahogyan akkor, amikor egyszerű helyettesítést hajtottunk végre a fenti sablon lekérdezésünkben.
Az SQLI támadást könnyen megakadályozza a bemenetek fertőtlenítése (vagy elhagyása). A fertőtlenítési folyamat valójában meglehetősen triviális, hiszen minden lényegében bármilyen inline egyszeri idézet (') karaktert megfelelően kezel, úgy, hogy nem használhatók fel arra, hogy egy SQL utasításban lévő karakterláncot idő előtt befejezzék.
Például, ha egy adatbázisban „O'neil” -et szeretne keresni, akkor nem lehetett egyszerű szubsztitúciót használni, mert az O-t követő egyszeri idézet a karaktersorozat idő előtti befejezését okozza. Ehelyett a megfelelő adatbázis menekülési karakterével tisztítsa meg. Tegyük fel, hogy az inline egyetlen idézethez tartozó menekülési karakter minden egyes idézetet egy szimbólummal \ t Tehát az „O'neal” megtisztulna „O \ t.
Ez az egyszerű higiéniai aktus megakadályozza az SQLI támadást. A szemléltetés érdekében nézzük meg a korábbi példáinkat, és nézzük meg a kapott lekérdezéseket, amikor a felhasználói bevitel megtisztul.
myuser”-- / wrongpass:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "myuser" - 'ÉS Jelszó = "hibás"
Mivel a myuser utáni egyszeri idézet megszűnt (ami azt jelenti, hogy a célérték része), az adatbázis szó szerint keresni fogja a felhasználói nevet "Myuser" -". Továbbá, mivel a kötőjelek a karakterlánc értékek közé tartoznak, és nem az SQL utasításnak, akkor azok a célérték részét képezik, nem pedig SQL megjegyzésként értelmezve..
Robert '; DROP TABLE Felhasználók;-- / wrongpass:
Felhasználóazonosító kiválasztása felhasználóktól WHERE UserName = "Robert"; DROP TABLE Felhasználók; - 'ÉS Jelszó = "hibás"
Egyszerûen elhagyva az egy idézetet Robert után, mind a pontosvessző, mind a kötőjelek megtalálhatók a UserName keresési karakterláncban, így az adatbázis szó szerint keresni fog "Robert"; DROP TABLE Felhasználók; - " a táblázat törlése helyett.
Összefoglalva
Míg a webes támadások fejlődnek és kifinomultabbak, vagy egy másik belépési pontra összpontosítanak, fontos megjegyezni, hogy meg kell védeni a megpróbált és igaz támadásokat, amelyek több szabadon elérhető „hackereszköz” inspirációját jelentik..
Bizonyos típusú támadásokat, mint például a DDoS, nem lehet könnyen elkerülni, míg mások, mint például az SQLI. Azonban az ilyen típusú támadások által elszenvedett károk bárhol lehetnek a kényelmetlenségtől a katasztrofálisig, attól függően, hogy milyen óvintézkedéseket tettek.
