Használható-e valaha az xp_cmdshell egy tárolt procin belül biztonságosan, és vannak-e olyan helyzetek, amelyekre valóban nincs más lehetőség? Más szavakkal, a tárolt procikban való használatát mindig biztonsági kérdésként kell megjelölni (amint azt egy jól ismert forráskód-elemző tanácsolja)?
Másképp fogalmazva, egyetértene-e a következő állítással ( közvetlen idézet)?
Az xp_cmdshell függvény nem használható biztonságosan. Nem szabad használni.
Megjegyzések
- Azok számára, akik ismeretlenek ” xp_cmdshell “, ez a ” kiterjesztett tárolt eljárás, amelyet a Microsoft biztosít és a fő adatbázisban tárol. Ez az eljárás lehetővé teszi az operációs rendszer parancsainak közvetlen kiadását a Windows parancshéjához T-SQL kódon keresztül. ” Igen !!
- Nem, nem adok ‘ nem ért egyet. Mindenképp biztonságosan használható legalább 2 különböző módszerrel, amelyeket ismerek, és az egyiket nagyon könnyű beállítani. A probléma az, hogy a BOL nem ‘ nem mondja meg, hogyan kell csinálni.
Válasz
Ez mindig kockázat . Mindig felül kell vizsgálni . Megfelelően enyhíthető .
Vannak törvényes felhasználások, néha szükségszerűek is, de figyelje alaposan a véleményét!
Megjegyzések
- Mi a probléma azzal, hogy nincs mód a felhasználót egy előre definiált műveletek csoportjára korlátozni, és ezért minden privilégium-megadás lehetővé teszi a felhasználó számára bármely parancssor végrehajtását, azaz nem ‘ nem engedheti meg a privilégiumok részletességét, vagy másként állította, hogy a vezérlés teljes vezérléssé válik?
- Most az SQL Server másodlagos számomra, ezért mondja meg, ha ‘ m rossz: Ha a felhasználónak engedélyt ad a végrehajtott engedélyekre a tárolt eljáráshoz, akkor az adott felhasználó futtathatja azt. Nem teszi lehetővé számukra, hogy módosítsák, és nem jár ‘ nem vonja maga után engedélyek megadását mindarra, amelyet a tárolt eljárás használ. Ha meg kell adni nekik
xp_cmdshellengedélyt az azt tartalmazó tárolt eljárás futtatásához, akkor ‘ mindenképpen probléma merült fel. ‘ Biztos vagyok benne, hogy nem szükséges – az eljárást nem a rendes felhasználónak kell birtokolnia. - @TobyS … ez a probléma azokkal fajta nyilatkozatok. Rövid válasz: Az xp_cmdshell gonosz. Hosszú válasz: ez attól függ. 😉
- @SteveS – az MSSQL jelenlegi verziója lehetővé teszi egy másik operációs rendszer fiók beállítását az xp_cmdshell parancsok futtatásához.
- @JeffFerland … te ” I ‘ m eléggé magabiztos, amire nincs szükség – az eljárást nem a rendes felhasználónak kell birtokolnia. ” Ez ‘ 100% -ban helyes. ‘ nincs szükség arra, hogy a felhasználó még azt is tudja, hogy van-e benne tábla, ne feledje az xp_CmdShell. És igen, ‘ nagyon könnyű beállítani.
Válasz
Az xp_CmdShell kikapcsolása egy kicsit olyan, mintha fátylat vetne a rothadó húsra. Hamis biztonságérzetet hoz az asztalra, és a legyek még mindig eljuthatnak a húshoz. Engedje meg, hogy elmagyarázzam.
Ki használhatja az xp_CmdShell alkalmazást? Ez így van. Csak azok az emberek / alkalmazások jelentkezhetnek be, akik “SA” privilementekkel rendelkeznek, vagy azok, akiknek szörnyű hibát követett el, ha proxyt adott.
Következő kérdés. Ha az xp_CmdShell ki van kapcsolva, csak azok tudják visszakapcsolni? Javítsd újra! Csak az “SA” privátokkal rendelkező emberek / alkalmazások kapcsolhatják be újra.
Tehát mi az igazi probléma az xp_CmdShell biztonsági kockázatával ? A válasz: xp_CmdShell NEM biztonsági kockázat. A gyenge biztonság az egyetlen biztonsági kockázat. Ha egy hacker vagy rosszindulatú belső felhasználó “SA” privilementekkel kerül be a rendszerbe, akkor bekapcsolhatja az xp_CmdShell-t a momementekben. Igen, ez a művelet naplózásra kerül, de ez csak dokumentáltan bizonyítja, hogy a biztonság eleve durván hiányzott.
Az xp_CmdShell kikapcsolása nem tesz semmit a biztonság érdekében, kivéve, hogy lehetőséget ad a hackerek kódjának arra a részére, hogy újra bekapcsolja a futtatást.
Megismételem még egyszer. Az xp_CmdShell nem jelent biztonsági kockázatot. Csak a rossz biztonság jelent biztonsági kockázatot. Javítsa ki a biztonságot, majd kapcsolja be az xp_CmdShell szoftvert. Ez egy csodálatos eszköz, és a rossz biztonsági gyakorlatok és a mítosz miatt hiányol.
Megjegyzések
- Teljesen egyetértek veled, Jeff. A syadmin jogosultságokat elnyerő támadó létrehozhat egy sa tulajdonú SQL Agent-feladatot egy CmdExec jobsteppel, és elérheti ugyanazt, mint az xp_cmdshell. Létrehozhat egy CLR tárolt eljárást is, amely elindítja a folyamatot. Miben különbözne ez az xp_cmdshell-től?A szerver megfelelő védelme az egyetlen módja a biztonsági kockázatok megelőzésének.
- Ah, ol ‘ barátom. Köszönjük a visszajelzéseket. Jó, ha ” újra látlak ” téged.
- +1 tévedsz, de nekem tetszik, hogy tévedsz mert az embereket arra biztatja, hogy kevésbé biztonságban legyenek, ami az érdeklődést szórakoztatóbbá teszi. Igen Telepítse az SQL Server szolgáltatást mindenre, és igen, egy további részt arról, hogy a konfigurációval hogyan lehet egyszerűen javítani. Szeretem < 3. A 2020-as és a 9/10-es SQL szervereit nem fogják megfelelően megkeményíteni – de természetesen a DB admin XD-t hibáztatom
- Heh … I ‘ ll neked ugyanaz a plusz egy, mert tévedsz. Szeretném, ha adhatnék egy pluszt azért, mert tévedett abban a gondolatban, hogy az xp_CmdShell letiltása egyáltalán bármit megtesz ” keményítéséért ” egy szerverért. Csak nem ‘ t.
Válasz
szerintem “nem szabad használni” valószínűleg elég jó tanács. Ez nem egy kategorikus “ mindig bizonytalan”, sokkal inkább annak a felismerése, hogy az xp_cmdshell veszélyes, és bármilyen használata aggodalomra ad okot és alapos vizsgálat.
És Még akkor is, ha úgy gondolja, hogy tudja elkerülni a biztonsági kockázatokat, valószínűleg az xp_cmdshell nem a legjobb eszköz. Valószínű, hogy van egy jobb megoldás (amely véletlenül kevésbé kockázatos).
Válasz
” a nagy hatalom nagy felelősséggel jár. ” Ennek ellenére azt gondolom, hogy a xp_cmdshell az egyik legrosszabb biztonsági vonat, amely Redmondból kijut.
Szerkesztés: 2020, több mint 10 éves penetrációs tesztelőként – xp_cmdshell továbbra is az egyik legfélelmetesebb biztonsági kockázat, amellyel találkoztam, mert a legjobb kombinációval rendelkezik nak,-nek; széles körben elterjedt, fontos üzleti vállalkozások, például bankok használják, és a maximális hatás. Az SQLmap használható az SA megszerzésére és az xp_cmdshell újbóli engedélyezésére … csak az SQL Injection használatával egy webappban.
Mint mérnök a másiknak, köszönöm a Microsoft – szó szerint nem tudtam volna megszerezni ezeket a héjakat nélküled.
Megjegyzések
- Tudom, hogy ‘ egy régi kérdés, de igazából ki kell mondanom: meg ‘ meglepődtem, hogy 3 ember komolyan vette a trollkodását elég ahhoz, hogy pozitívan szavazzon a válaszodra.
- @spaghettidba halálosan komoly vagyok, mivel a pentester
xp_cmdshell()isten küld. Annyira rosszá teszi, hogy a Microsoftnál senkinek eszébe sem jut kijavítani ezt a problémát.
nagyon örülök, hogy találkoztam a Microsoft termékeivel és a Microsoft platformjára épített alkalmazásokkal, mert gyengék. Szórakoztató tény, hogy az első 0 napom 16 éves koromban volt egy Microsoft biztonsági termékben, ami több mint egy évtizede volt.
Válasz
Milyen biztonságot használ az SQL Server környezet, vegyes vagy integrált (Windows)? Hányan vannak a sysadmin SQL Server szerepkörben? Az MS bevált módszerei integrált hitelesítést igényelnek (nincs bejelentkezés, nincs SQL bejelentkezés), és csak kettőt kell a sysadmin SQL Server szerepkörben használni. Bevallom, hogy ezeknek a bevált gyakorlatoknak a követése nagymértékben csökkenti az ember expozícióját. Az xp_cmdshell (pre sqlcmd mód és pre-Powershell) lehetővé teszi a tranzakciós naplófájlok másolását a termelési kiszolgálóról a DR szerverre, több száz mérföldnyire egy ütemezettől. SQL Agent-feladat. Itt nincs semmi gonosz, de ahogy az egy poszter megfogalmazta, “ez attól függ”.
Válasz
A jl01 hangsúlyozásához ” s válasza (aminek +1-et adtam) …
Furcsa módon a megfelelően védett és biztonságos SQL Server jó mércéje az, hogy az xp_CmdShell engedélyezve van.Úgy értem, hogy ha a rendszere elég biztonságos, akkor nem kell aggódnia olyan apróságok miatt, mint például az xp_CmdShell engedélyezése és felhasználása.
Különösen az SQL Server 2005 óta gyakorlatilag nincs ok Miért kellene a DBA-któl eltérő felhasználóknak rendelkezniük a nyilvános jogosultságokkal és a VÉGREHAJTÁS jogosultságokkal a tárolt eljárásoknál egy megfelelően lezárt rendszerben. Valójában a megfelelő módon megvalósítva a PUBLIC privilokkal rendelkező felhasználóknak képesnek kell lenniük egy tárolt eljárás végrehajtására, amely az xp_CmdShell hívásait tartalmazza, anélkül, hogy maguk tudnák futtatni az xp_CmdShell fájlt.
Ironikusnak tartom, hogy az MS létrehozta a parancshéj proxyt. hogy az alacsony privát szintű felhasználók futtathassák az xp_CmdShell fájlt közvetlenül, ha még táblázatot sem kellene látniuk.