xp_cmdshell: měl by být někdy použit?

Vždy jde o riziko . Mělo by být vždy zkontrolováno . Může být správně zmírněno .

Existují legitimní použití, někdy i nezbytnosti, ale pozorně sledujte svůj vstup!

Komentáře

• Jaký je problém, že neexistuje způsob, jak omezit uživatele na předem definovanou skupinu operací, a proto jakékoli udělení oprávnění umožňuje uživateli provést libovolný příkazový řetězec, tj. ‚ Nelze povolit granularitu privilage nebo odlišně uvedeno, jakákoli kontrola se stane úplnou kontrolou?
• Nyní je pro mě SQL Server sekundární, takže mi řekněte, jestli ‚ špatně: Přidělení oprávnění k provedení uložené procedury uživateli umožňuje spuštění této procedury. Neumožňuje jim to upravit a neznamená to ‚ udělení oprávnění pro vše, co tato uložená procedura používá. Pokud jim musí být uděleno xp_cmdshell oprávnění ke spuštění uložené procedury, která ji obsahuje, pak jste ‚ určitě dostali problém. Jsem ‚ přiměřeně přesvědčen, že to není nutné – postup by neměl vlastnit běžný uživatel.
• @TobyS … to je problém těchto uživatelů druhy výpisů. Krátká odpověď: xp_cmdshell je zlo. Dlouhá odpověď: záleží. 😉
• @SteveS – aktuální verze MSSQL vám umožňuje nastavit jiný účet OS, na kterém budou spuštěny příkazy xp_cmdshell.
• @JeffFerland … vy napsal “ Jsem ‚ m přiměřeně přesvědčen, že to není nutné – postup by neměl být vlastněn běžným uživatelem. “ To ‚ je 100% správné. ‚ není tedy třeba, aby uživatel věděl, jestli je tabulka zapojena, nevadí xp_CmdShell. A ano, ‚ nastavení je celkem snadné.

Vypnutí xp_CmdShell je něco jako přikrytí závoje hnijícím masem. Přináší falešný pocit bezpečí na stůl a mouchy se stále mohou dostat k masu. Dovolte mi to vysvětlit.

Kdo může používat xp_CmdShell? To má pravdu. Mohou jej používat pouze přihlášeni lidé / aplikace s privátními soubory „SA“ nebo lidé, u kterých jste udělali tu hroznou chybu, že jste poskytli proxy.

Další otázka. Pokud máte vypnutý xp_CmdShell, kdo jsou jediní lidé, kteří jej mohou znovu zapnout? Opravit znovu! Znovu je mohou zapnout pouze lidé / aplikace s priváty typu „SA“.

Takže, jaký je skutečný problém, když je xp_CmdShell bezpečnostní riziko ? Odpověď zní xp_CmdShell NENÍ bezpečnostní riziko. Špatná bezpečnost je jediným bezpečnostním rizikem. Pokud se hacker nebo interní uživatel se zlými úmysly dostane do systému s privátními soubory „SA“, pak může mpx zapnout xp_CmdShell. Ano, tato akce se zaznamená, ale poskytuje pouze dokumentované svědectví, že zabezpečení na začátku hrubě chybělo.

Vypnutí xp_CmdShell neudělá nic pro bezpečnost, kromě poskytnutí možnosti, aby ta část hackerského kódu mohla znovu spustit.

Řeknu to znovu. xp_CmdShell není bezpečnostní riziko. Pouze špatné zabezpečení je bezpečnostním rizikem. Opravte zabezpečení a poté zapněte xp_CmdShell. Je to úžasný nástroj a vy o něj přicházíte kvůli špatným bezpečnostním praktikám a mýtu.

Komentáře

• zcela s vámi souhlasím, Jeffe. Útočník, který získal oprávnění syadminu, mohl vytvořit úlohu agenta SQL ve vlastnictví sa s jobstep CmdExec a dosáhnout stejné jako xp_cmdshell. Mohl by také vytvořit uloženou proceduru CLR, která spustí proces. Jak by se to lišilo od xp_cmdshell?Správné zabezpečení serveru je jediný způsob, jak zabránit bezpečnostním rizikům.
• Ach, můj starý ‚ přítel. Děkujeme za zpětnou vazbu. Rádi vás “ znovu uvidíme „.
• +1, že se mýlíte, ale líbí se mi, že se mýlíte protože povzbuzujete lidi k tomu, aby byli méně zabezpečeni, a díky tomu je zájem zábavnějším místem. Ano Nainstalujte SQL Server na všechno a ano další část o tom, jak je snadné opravit konfiguraci. Milujte < 3. Jeho servery SQL 2020 a 9/10 nebudou správně zpevněny – ale samozřejmě obviňujte správce databáze DB XD
• Heh … já ‚ dám ty samé plus jedna za to, že jsi se mýlil. Přál bych si, abych vám mohl dát plus za to, že jste se mylně domnívali, že deaktivace xp_CmdShell způsobí “ zpevnění “ serveru vůbec. Prostě to nejde ‚ t.

Myslím, že „nemělo by se to používat“ je pravděpodobně docela dobrá rada. To není kategorické „Je to vždy nejisté“, ale spíše poznání, že xp_cmdshell je nebezpečný a jakékoli jeho použití je důvodem k obavám a pečlivé kontrole.

A i když si myslíte, že víte, jak se vyhnout bezpečnostním rizikům, xp_cmdshell stále pravděpodobně není tím nejlepším nástrojem. Kurz je v tom, že existuje lepší řešení (takové, které je ale naštěstí méně riskantní).

„S velká síla přichází velká odpovědnost. “ Jak už bylo řečeno, myslím si, že xp_cmdshell je jedním z nejhorších způsobů zabezpečení vlaku, který se dostal z Redmondu.

Edit: 2020, as a penetration tester for 10+ years – xp_cmdshell stále jedno z nejděsivějších bezpečnostních rizik, se kterými jsem se setkal, protože má nejlepší kombinaci z; být široce rozšířen, využíván důležitými podniky, jako jsou banky, a maximální dopad. SQLmap lze použít k získání SA a opětovnému povolení xp_cmdshell … pouze s použitím SQL Injection ve webové aplikaci.

Jako jeden inženýr druhému děkuji Microsoftu – tyto skořápky bych bez vás doslova nemohl získat.

Komentáře

• Vím, že ‚ je stará otázka, ale opravdu ji musím říct: ‚ m překvapil 3 lidi, kteří váš trollování brali vážně dost na to, abych hlasoval pro vaši odpověď.
• @spaghettidba to myslím vážně, protože pentester xp_cmdshell() je bůh poslat. To je tak špatné, že nikdo v Microsoftu ani nepomyslí na vyřešení tohoto problému. Jsem ‚ velmi rád, že se mohu setkat s produkty a aplikacemi Microsoft postavenými na platformě Microsoft, protože jsou slabé. Zábavný fakt, že můj první den 0 byl v bezpečnostním produktu Microsoft, když mi bylo 16, což bylo před více než deseti lety.
• @rook – It ‚ Nestává se často, že bych si promluvil se skutečným testerem PEN, takže jsem ‚ využil této příležitosti a zeptal se (nehledám boj … já ‚ upřímně a skutečně se zajímám o vaše dobré zkušenosti), pokud NEMŮŽETE ‚ T dostat se do někoho ‚ s dobrá skříňka s priváty SysAdmin, stále se ti podařilo použít xp_CmdShell jako útočníka, i když je ‚ povolen? Pokud ano, existuje způsob, jak se proti němu chránit?
• @Jeff Moden. ANO , takže sqlmap to dělá celkem dobře. I když nejste SA – z důvodu skládání dotazů se můžete přihlásit k účtu SA pomocí SQL QUERY – ano, můžete použít injektovaný sql dotaz k získání SA a opětovnému povolení libovolného příkazu. Stále musíte znát heslo … ale může být vynuceně vynuceno a pokud tento útok nebyl ‚ zohledněn, mohl by mít účet SA slabé heslo … a viděl jsem to mnohokrát, dokonce i v bankách. Nejsem odborník na SQL-Server, ale myslím, že existuje posílení, které může zabránit tomuto útoku … ale ne výchozí !!!! SQLMap pro vítězství!

Jaký druh zabezpečení se používá ve vašem prostředí serveru SQL, Mixed nebo integrovaný (Windows)? Kolik jich je v roli SQL serveru sysadmin? Osvědčené postupy MS vyžadují integrované ověřování (žádné přihlášení, žádné přihlášení SQL) a pouze dvě role sysadmin SQL Server. Předkládám, že dodržování těchto osvědčených postupů výrazně zmírňuje vystavení člověka. Dále xp_cmdshell (režim pre sqlcmd a pre-Powershell) umožňuje kopírovat soubory protokolu transakcí z produkčního serveru na server DR vzdálený stovky mil od naplánovaného Úloha agenta SQL. Žádné zlo zde, ale jak uvádí jeden plakát, „záleží“.

Zdůraznit jl01 “ s odpovědí (které jsem dal +1) …

Kupodivu, dobrým měřítkem správně zabezpečeného a bezpečného serveru SQL Server je skutečně mít povolený xp_CmdShell.Tím mám na mysli to, že pokud je váš systém dostatečně zabezpečený, nemusíte se starat o triviální záležitosti, jako je povolení a POUŽÍVÁNÍ xp_CmdShell.

Zejména u serveru SQL Server 2005 neexistuje prakticky žádný důvod proč by všichni uživatelé kromě DBA měli mít privy větší než PUBLIC privs a EXECUTE privs na uložené procedury ve správně uzamčeném systému. Ve skutečnosti by uživatelé s PUBLIC privs měli být správně implementováni, měli by být schopni provést uloženou proceduru, která obsahuje volání xp_CmdShell, aniž by mohli přímo spustit xp_CmdShell.

Myslím, že je ironií, že MS vytvořilo proxy příkazového prostředí umožnit uživatelům s nízkým oprávněním spouštět xp_CmdShell přímo, když by neměli ani vidět tabulku.