A sql SQL sql szerver kezelése
Ez a dokumentum nem terjed ki az alap SQL-szintaxisra vagy SQL-befecskendezésre. Feltételezzük, hogy az olvasó már jól ismerte a témát. Ez a dokumentum olyan speciális technikákra fog összpontosítani, amelyek a Microsoft SQL Server használatával a webes alkalmazások támadásaiban használhatók. Ezek a technikák bemutatják, hogyan használhatják a támadók SQL injekciókat a tartalom törléséhez az adatbázisból, elkerülve a tűzfalat, és áthaladva a belső hálózaton. Ez a dokumentum arra szolgál, hogy az információbiztonsági szakemberek számára az SQL injekciók potenciálisan veszélyes hatásait jelenítse meg a szervezetben.
bevezetés
SQL injekciós detektálás
Az SQL injektálás eredményei
A kiváltságok növelése
Fájlok feltöltése
Behatolás a belső hálózatba
Portszkennelés
ajánlások
következtetés
Ez a dokumentum nem terjed ki az alap SQL-szintaxisra vagy SQL-befecskendezésre. Feltételezzük, hogy az olvasó már jól ismerte a témát. Ez a dokumentum olyan speciális technikákra fog összpontosítani, amelyek a Microsoft SQL Server használatával a webes alkalmazások támadásaiban használhatók. Ezek a technikák bemutatják, hogyan használhatják a támadók SQL injekciókat a tartalom törléséhez az adatbázisból, elkerülve a tűzfalat, és áthaladva a belső hálózaton. Ez a dokumentum arra szolgál, hogy az információbiztonsági szakemberek számára az SQL injekciók potenciálisan veszélyes hatásait jelenítse meg a szervezetben.
A webes alkalmazások biztonságosabbá válnak, mivel a támadások bejelentéseinek száma, például az SQL injektálás, növekszik. Nagy és összetett alkalmazások esetén azonban az egyik felügyelet a teljes rendszer veszélyeztetése lehet. Számos webes alkalmazás fejlesztő és rendszergazda hamis biztonságérzetet élvezhet, mivel tárolt eljárásokat használnak vagy elrejtik a böngészőablakba visszatért hibaüzeneteket. Ez okot ad arra, hogy a sérülékenységet nem lehet használni.
Bár a dokumentumban a Microsoft SQL Serverről beszélünk, ez nem jelenti azt, hogy ez a termék kevésbé biztonságos, mint más platformok, például az Oracle vagy az IBM DB2. Az SQL injektálás nem specifikus biztonsági rés A Microsoft SQL Server általában egy adatbázis-probléma. A Microsoft SQL Server legnagyobb problémája a rugalmasság. Ez a rugalmasság új lehetőségeket nyit meg az SQL Injection osztály támadásaira. A dokumentum célja annak bemutatása, hogy amikor egy rendszergazda vagy fejlesztõ tetszõleges SQL lekérdezést tesz lehetõvé, a megtámadott rendszer nyitva áll a teljes rögzítéshez. Ez nem jelenti azt, hogy a Microsoft SQL Server termék általánosságban sérülékeny.
SQL injekciós detektálás
Amikor SQL alkalmazásokat próbál használni az alkalmazásokban, akkor a támadónak szüksége van egy módszerre annak meghatározásához, hogy tetszőleges SQL lekérdezést ténylegesen beillesztett-e. Szükség van egy módszerre az eredmények megszerzéséhez. Ehhez két beépített SQL szerver funkció használható. OPENROWSET és OPENDATASOURCE funkciók egy távoli adatforrás megnyitásához. Ezeket a funkciókat egy OLEDB szolgáltatóon keresztül megnyithatja. Az OPENROWSET függvény minden példában használható, de az OPENDATASOURCE funkció ugyanazokkal az eredményekkel használható.
Ez a kifejezés az 1. táblázat összes sorát visszaadja a távoli adatforrásból:
lehetőségek:
(1) Szolgáltató neve OLEDB
(2) Csatlakozási karakterlánc (lehet az OLEDB vagy az ODBC által előírt formátum)
(3) Az SQL kifejezés
Az SQL injektálás során a támadó meghatározhatja, hogy az SQL lekérdezés végrehajtásra került-e. Ha az SQL lekérdezés sikeres, a megtámadott kiszolgáló megpróbálja létrehozni a kimenő kapcsolatot a támadó számítógépével a megadott porthoz. Ezt a kimenő SQL kapcsolatot a legtöbb esetben nem blokkolja a tűzfal, mivel a 80-as portot használják.
Ez a technika lehetővé teszi a támadó számára, hogy megtudja-e, hogy az SQL lekérdezés végrehajtásra került-e még akkor is, ha a hibaüzenetek és lekérdezések eredményei nem jelennek meg a böngészőablakban.
Az SQL injektálás eredményei
A szükséges adatokat leggyakrabban a OPENROWSET és OPENDATASOURCE funkciók használják. Felhasználhatók arra is, hogy adatokat helyezzenek el egy távoli SQL szerverre. A OPENROWSET funkció nemcsak a SELECT lekérdezés végrehajtására használható, hanem az INSERT és a DELETE külső adatforrások végrehajtásához is. A távoli forrásból származó adatfeldolgozás nem általános, és csak akkor működik, ha az OLEDB szolgáltató támogatja ezt a funkciót. Az SQLOLEDB szolgáltatónak ilyen funkciói vannak.
Az alábbiakban bemutatjuk, hogyan adhatunk adatokat külső adatforráshoz:
Ebben a példában a helyi SQL-kiszolgáló 2. táblázatának összes sorát hozzáadjuk a távoli kiszolgáló tábla1 táblájához. A lekérdezés sikeres végrehajtásához szükséges, hogy mindkét asztalnak hasonló szerkezete legyen.
Amint azt az előző bekezdésben megtudtuk, a távoli adatforrások átirányíthatók bármely támadó választott kiszolgálójára.
A támadó módosíthatja a fenti lekérdezést egy távoli adatforráshoz való csatlakozáshoz, például a támadó gépén futó Microsoft SQL Server másolatához.
Az adatok sikeres beillesztéséhez a támadónak ugyanolyan oszlopokkal és adattípusokkal kell létrehoznia egy táblát1, mint a 2. táblázatban. Ez az információ ugyanazt a trükköt használhatja a rendszer táblázatokhoz. Ez azért fog működni, mert a rendszertáblák szerkezete előre ismert. A támadónak olyan táblák létrehozásával kell elindulnia, amelyek azonosak a rendszertáblák sysdatabases, sysobjects és sys columns rendszerével. Ezután a szükséges információk kivonásához a következő SQL lekérdezéseket kell végrehajtani:
Miután újra létrehozta az adatbázis tábláit, a szükséges adatok SQL szerverről történő betöltése triviális.
Ezzel a módszerrel a támadók kivonhatják a tartalmakat a táblázatokból, még akkor is, ha az alkalmazás elrejti a hibaüzenetet vagy az érvénytelen kérések eredményét.
Miután megkapta a megfelelő jogosultságokat, a támadó képes lesz betölteni a bejelentkezési listákat és a jelszavakat:
A jelszóbevitelek fogadása lehetővé teszi a támadó számára, hogy a jelszavak megtalálása érdekében brutális erővel támadjon.
A támadó képes lesz parancsokat végrehajtani a támadott szerveren, és megkapja a végrehajtás eredményeit:
Ha a tűzfal úgy van konfigurálva, hogy blokkolja az összes kimenő SQL kiszolgáló kapcsolatot, a támadó a tűzfal megkerülésével számos módszert használhat. A támadó a HTTP-kapcsolat 80. portját használhatja az adatok továbbítása során. Az alábbiakban egy példa erre a technikára:
Ha a 80. portra irányuló kimenő kapcsolatot blokkolja a tűzfal, akkor a támadó megpróbálhatja használni a többi portszámot, amíg meg nem találja a nyitottat.
A kiváltságok növelése
Gyakran az adminisztrátor, a biztonsági ajánlásoknak megfelelően, konfigurálja az alkalmazások futtatását hátrányos helyzetű felhasználóként. Miután sérülékenységet talált egy olyan alkalmazásban, amelyet egy hátrányos helyzetű felhasználó indított el, a támadó megpróbál emelni jogosultságokat és adminisztrátori jogokat szerezni. A támadók más ismert és ismeretlen biztonsági réseket is használhatnak, ami növeli a jogosultságokat. Az SQL-kiszolgáló néhány friss sérülékenységet észlel, ha a támadó képes tetszőleges SQL lekérdezéseket végrehajtani, viszonylag könnyedén növelheti a jogosultságokat.
Fájlok feltöltése
Miután a támadó megkapta a szükséges SQL szerver jogosultságait, érdemes egy bináris fájlt feltölteni a kiszolgálóra. Mivel ez nem lehetséges olyan protokoll használatával, mint az SMB, a 137-139-es portokat általában egy tűzfal blokkolja, a támadónak más módszerre van szüksége ahhoz, hogy a bináris fájlt az áldozat fájlrendszerébe helyezze. Ezt úgy teheti meg, ha egy bináris fájlt feltöl a támadó házának helyi táblájára, és a fájlt a támadott állomásnak egy SQL kiszolgáló kapcsolaton keresztül helyezi el.
Ennek végrehajtásához a támadónak a következőképpen kell létrehoznia egy táblát a helyi kiszolgálón.
Miután létrehozta a bináris fájl táblázatát, töltse be a következőképpen:
A bináris fájl letölthető az áldozat kiszolgálóra a támadó kiszolgálójáról a következő SQL lekérdezés használatával:
Ez a kérés kimenő kapcsolatot eredményez a támadó kiszolgálójával, és a lekérdezés eredményét egy fájlba írja. Ebben az esetben a kapcsolat az alapértelmezett protokollal és porttal történik, ez a kapcsolat valószínűleg blokkolja a tűzfalat. A tűzfal megkerülésével a támadó megpróbálhatja használni a következőket:
Az első SQL lekérdezés konfigurálja a kapcsolatot a hacker kiszolgálóval a 80. port használatához, a második SQL lekérdezés csatlakozik a hacker kiszolgálóhoz a 80. port használatával, és feltölti a bináris fájlt.
Ezzel a technikával a szkript csatlakozik egy kiszolgálóhoz és letölti a támadó bináris fájlját, vagy másolja és futtatja a fájlt az áldozat szerverén.
Behatolás a belső hálózatba
A csatlakoztatott és távoli Microsoft SQL Server kiszolgálók egy kiszolgáló számára lehetővé teszik, hogy átláthatóan működjenek együtt egy másik távoli adatbázis-kiszolgálóval. A csatlakoztatott kiszolgálók lehetővé teszik az elosztott lekérdezések végrehajtását, és akár távoli adatbázis-kiszolgálókat is kezelhetnek. A támadó kihasználhatja ezeket a lehetőségeket a belső hálózat eléréséhez.
A támadónak a master.dbo.sysservers rendszertáblában tárolt információkat kell gyűjtenie, amint az itt látható:
A támadó ezenkívül információt kérhet a csatlakoztatott távoli kiszolgálóról.
Ha a kiszolgálók nincsenek konfigurálva az adatok eléréséhez (nem tetszőleges kérésekhez konfigurálva, csak tárolt eljárások engedélyezettek), a támadó megpróbálhatja:
Ezzel a technikával a támadók "ugorhatnak" az egyik kiszolgálóról a másikra a belső hálózaton keresztül mélyebben behatolva a csatlakoztatott és a távoli kiszolgálókon keresztül:
Miután a támadó megkapta a szükséges hozzáférést a csatlakoztatott vagy távoli kiszolgálóhoz, fel tudta tölteni a fájlt a kiszolgálóra a korábban említett módszerek használatával.
Portszkennelés
Miután megtalálta a kiszolgáltatott (webes) alkalmazást, a támadó a következő SQL lekérdezést használhatja:
Ha a port nyitva van, a válaszidő kevesebb lehet, mint az időtúllépés beállítása (a portot használó alkalmazástól függően), és a következő hibaüzenet jelenik meg:
Egy ilyen portszkenner másik lehetséges hatása egy DOS-támadás. Tekintsük a következő példát:
ajánlások
A fő ajánlás annak biztosítása, hogy az SQL injekcióban ne legyenek sérülékenységek. Ez a legfontosabb ajánlás, mert még ha nem is tudod megtenni a cikkben leírt trükköket, akkor a sebezhetőségek kihasználására más módszer is lehet. Az SQL injekciók elleni védelem érdekében ajánlott parametrikus lekérdezések és szűrő felhasználói bevitel használata nem alfanumerikus karakterek esetén.
A legmegfelelőbb mód az alkalmazások írása során a biztonságos programozási szabványoknak való megfelelés. Ha az alkalmazáskód már meg van írva, ellenőriznie kell a biztonsági réseket. Javasolt továbbá néhány olyan automatizálási eszközre is hivatkozni, amelyek ilyen típusú problémák észlelésére szolgálnak.
Még akkor is, ha úgy érzi, hogy minden ismert sebezhetőséget bezárt, jó megoldás az, hogy letiltja a fel nem használt SQL szerver funkciókat. De csak abban az esetben, ha ez a funkció valóban nem szükséges az Ön számára. Szerencsére a blokkolni kívánt funkciókat gyakran nem használják.
Speciális kéréseket kell letiltania az OLEDB segítségével az SQL kiszolgálóról. A kérések végrehajtásának képességét a DisallowAdhocAccess érték beállítása a rendszer rendszerleíró adatbázisában határozza meg.
Ha az alapértelmezett példányt használja, állítsa a DisallowAdhocAccess = 1 értéket minden kulcsváltoztatóra:
Az érték beállításához kövesse az alábbi lépéseket:
Paranoid esetén a rendszerleíró kulcsokat csak olvasható módba állíthatja, hogy azokat ne lehessen szerkeszteni.
Nagyon fontos a javítások eltávolítása a biztonsági hibák kiküszöbölése érdekében, ezért időben meg kell csinálni.
Az utolsó óvintézkedés, konfigurálja és tesztelje a tűzfalat, hogy blokkolja az összes felesleges kimenő forgalmat. Ez segít nemcsak az adatbázis fenntartásában, hanem a hálózat egészének biztonságában is.
Amit bemutattunk ebben a dokumentumban, egy kis hozzáférhetőség, amelyet több szerver teljes ellenőrzésére lehet használni. Az SQL univerzális nyelv. Egyetlen kedves személy sem engedheti meg, hogy tetszőleges C ++ kódot vagy Visual Basic-t futtasson a kiszolgálón. Ugyanez vonatkozik az SQL-re is. Semmiféle jó ember nem vakon végrehajtja, amit a felhasználó belépett. Ez a dokumentum megmutatja, hogy ez miért nem történhet meg.
A Microsoft SQL Server egy nagy teljesítményű, rugalmas és megfizethető adatbázis-kiszolgáló, amely a különböző alkalmazások alapjául szolgál. Ennek alapján fontos megérteni, hogyan veszélyeztetheti az SQL szervert, és még fontosabb megérteni, hogy ez hogyan kerülhető el. Az SQL-kiszolgáló eszköz, és ha azt helytelenül vagy gondatlanul használják, akkor nem csak az adatokat, hanem a hálózaton lévő egyéb alkalmazásokat is veszélyeztetheti. Ez azt jelenti, hogy komolyan kell vennünk a Microsoft SQL Server biztonságát.
