xp_cmdshell: moet het ooit worden gebruikt?

Het is altijd een risico . Het moet altijd worden herzien . Het kan op de juiste manier worden verzacht .

Er zijn legitieme toepassingen, soms noodzakelijke dingen, maar let goed op uw input!

Opmerkingen

• Hoe zit het met het probleem dat er geen manier is om een gebruiker te beperken tot een vooraf gedefinieerde groep bewerkingen en daarom staat elke toekenning van privileges de gebruiker toe om elke opdrachtreeks uit te voeren, dat wil zeggen ‘ staat geen granulariteit van privileges toe of wordt anders aangegeven, wordt elke controle volledige controle?
• Nu is SQL Server een secundaire voor mij, dus vertel me als ik ‘ m fout: door een gebruiker uitvoerrechten toe te kennen voor de opgeslagen procedure, kan die procedure door hen worden uitgevoerd. Het staat hen niet toe om het te wijzigen, en het houdt niet ‘ niet in dat er machtigingen moeten worden verleend voor alles dat door die opgeslagen procedure wordt gebruikt. Als ze xp_cmdshell permissies moeten krijgen om een opgeslagen procedure uit te voeren die het bevat, dan heb je ‘ zeker een probleem. Ik ‘ ben er redelijk zeker van dat dit niet nodig is – de procedure mag niet het eigendom zijn van de gewone gebruiker.
• @TobyS … dat is het probleem met die soorten uitspraken. Kort antwoord: xp_cmdshell is slecht. Lang antwoord: het hangt ervan af. 😉
• @SteveS – met de huidige versie van MSSQL kun je een ander OS-account instellen om xp_cmdshell-commandos uit te voeren.
• @JeffFerland … jij schreef ” Ik ‘ m redelijk zeker dat dit niet nodig is – de procedure mag niet het eigendom zijn van de gewone gebruiker. ” Dat ‘ is 100% correct. Daar ‘ hoeft de gebruiker niet eens te weten of er een tabel bij betrokken is, laat staan xp_CmdShell. En ja, het ‘ is vrij eenvoudig in te stellen.

Het uitschakelen van xp_CmdShell is een beetje zoals een sluier over rottend vlees. Het geeft een vals gevoel van veiligheid aan tafel en de vliegen kunnen nog steeds bij het vlees komen. Sta me toe om het uit te leggen.

Wie kan xp_CmdShell gebruiken? Dat klopt. Alleen mensen / app-logins met “SA” -privs of mensen aan wie je de vreselijke fout hebt gemaakt door een proxy te verlenen, kunnen deze gebruiken.

Volgende vraag. Als je xp_CmdShell hebt uitgeschakeld, wie zijn de enige mensen die het weer kunnen inschakelen? Corrigeer nogmaals! Alleen mensen / apps met “SA” -privs kunnen het weer inschakelen.

Dus, wat is het echte probleem met xp_CmdShell als een beveiligingsrisico ? Het antwoord is dat xp_CmdShell GEEN beveiligingsrisico is. Slechte beveiliging is het enige beveiligingsrisico. Als een hacker of een kwaadwillende interne gebruiker in het systeem terechtkomt met “SA” -privs, dan kunnen ze xp_CmdShell in een paar ogenblikken inschakelen. Ja, die actie wordt gelogd, maar dat is alleen maar een gedocumenteerd bewijs dat de beveiliging in het begin schromelijk ontbrak.

Het uitschakelen van xp_CmdShell doet niets voor de veiligheid, behalve om dat deel van een hackerscode de kans te geven om het weer aan te zetten.

Ik zeg het nog eens. xp_CmdShell is geen beveiligingsrisico. Alleen slechte beveiliging is een beveiligingsrisico. Herstel uw beveiliging en schakel vervolgens xp_CmdShell in. Het “een geweldig hulpmiddel” en je loopt het mis vanwege slechte beveiligingspraktijken en mythe.

Opmerkingen

• Ik ben het helemaal met je eens, Jeff. Een aanvaller die syadmin-rechten heeft verkregen, kan een SQL Agent-taak maken die eigendom is van sa met een CmdExec-taakstap en hetzelfde bereiken als xp_cmdshell. Hij zou ook een opgeslagen CLR-procedure kunnen maken die een proces start. Hoe zou dat anders zijn dan xp_cmdshell?Het correct beveiligen van de server is de enige manier om veiligheidsrisicos te voorkomen.
• Ah, mijn oude ‘ vriend. Bedankt voor de feedback. Goed om ” ” je weer te zien.
• +1 je hebt het mis, maar ik vind het leuk dat je het mis hebt omdat je mensen aanmoedigt om minder zeker te zijn, wat op hun beurt de interesse leuker maakt. Ja Installeer SQL Server op alles, en ja, het extra deel over hoe het gemakkelijk te repareren is met de configuratie. Ik vind het geweldig < 3. Zijn SQL-servers voor 2020 en 9/10 zullen niet correct worden gehard – maar geef natuurlijk de DB-beheerder XD de schuld.
• Heh … ik ‘ geef jij dezelfde plus één omdat je ongelijk hebt. Ik zou willen dat ik je een pluspunt kon geven omdat je het bij het verkeerde eind had door te denken dat het uitschakelen van xp_CmdShell helemaal niets doet om ” ” een server te verharden. Het doet gewoon niet ‘ t.

Ik denk “het mag niet worden gebruikt” is waarschijnlijk een redelijk goed advies. Dat is geen categorische “Het is altijd onzeker”, maar eerder een erkenning dat xp_cmdshell gevaarlijk is en dat elk gebruik ervan een reden tot bezorgdheid en zorgvuldig onderzoek is.

En zelfs als u denkt te weten hoe u de beveiligingsrisicos kunt vermijden, is xp_cmdshell waarschijnlijk niet de beste tool om te gebruiken. De kans is groot dat er een betere oplossing is (een die toevallig ook minder riskant is).

“Met grote kracht komt met grote verantwoordelijkheid. ” Dat gezegd hebbende, denk ik dat xp_cmdshell een van de ergste veiligheidstreinen is om Redmond te verlaten.

Bewerken: 2020, als penetratietester voor meer dan 10 jaar – xp_cmdshell nog steeds een van de meest angstaanjagende veiligheidsrisicos die ik ben tegengekomen omdat het de beste combinatie heeft van; wijd verspreid, gebruikt door belangrijke bedrijven zoals banken, en maximale impact. SQLmap kan worden gebruikt om SA te krijgen en xp_cmdshell … opnieuw in te schakelen met alleen SQL-injectie in een webapp.

Als ingenieur voor de andere, bedankt Microsoft – ik had deze hulzen letterlijk niet kunnen krijgen zonder jou.

Reacties

• Ik weet dat het ‘ een oude vraag is, maar ik moet het echt zeggen: ik ‘ ben verrast dat 3 mensen je trollen serieus namen genoeg om je antwoord positief te stemmen.
• @spaghettidba Ik ben bloedserieus, aangezien een pentester xp_cmdshell() een godsgeschenk is. Wat het zo erg maakt, is dat niemand bij Microsoft er zelfs maar aan denkt dit probleem op te lossen. Ik ‘ ben erg blij om Microsoft-producten en applicaties tegen te komen die op het Microsoft-platform zijn gebouwd, omdat ze zwak zijn. Leuk feit, mijn eerste 0-dag was in een Microsoft-beveiligingsproduct toen ik 16 was, wat meer dan tien jaar geleden was.
• @rook – It ‘ Het komt niet vaak voor dat ik met een echte PEN-tester kan praten, dus ik ‘ moet deze gelegenheid aangrijpen om het te vragen (niet op zoek naar ruzie … ik ‘ ben eerlijk en oprecht geïnteresseerd in je goede ervaring), als je KAN ‘ Iemand ‘ s goodie locker met SysAdmin privs, heb je xp_CmdShell nog steeds als aanvaller kunnen gebruiken, zelfs als het ‘ s is ingeschakeld? Zo ja, is er een manier om u ertegen te beschermen?
• @Jeff Moden. JA , dus sqlmap doet dit redelijk goed. Zelfs als u geen SA bent – vanwege het stapelen van querys kunt u inloggen op het SA-account met behulp van een SQL QUERY – ja, een geïnjecteerde SQL-query kan worden gebruikt om SA te verkrijgen en vervolgens een commando opnieuw inschakelen. Je moet nog steeds het wachtwoord weten … maar het kan brute-geforceerd zijn en als er geen ‘ rekening werd gehouden met deze aanval, zou het SA-account een zwak wachtwoord kunnen hebben … en ik heb dit vaak zien gebeuren, zelfs bij banken. Geen SQL-Server-expert, maar ik denk dat er verharding is die deze aanval kan voorkomen … maar niet standaard !!!! SQLMap voor de overwinning!

Wat voor soort beveiliging wordt er gebruikt in uw SQL Server-omgeving, Mixed of geïntegreerd (Windows)? Hoeveel zijn er in de rol van sysadmin SQL Server? MS best practices vragen om geïntegreerde authenticatie (geen sa-login, geen SQL-logins) en slechts twee in de sysadmin SQL Server-rol. Ik stel dat het volgen van deze best practices iemands blootstelling aanzienlijk vermindert. Verder biedt xp_cmdshell (pre sqlcmd-modus en pre-Powershell) de mogelijkheid om transactielogbestanden van de productieserver naar de DR-server te kopiëren, honderden kilometers verwijderd van binnen een geplande SQL Agent-taak. Geen kwaad hier, maar zoals de ene poster zei, “het hangt ervan af”.

Om jl01 “te benadrukken” s antwoord (dat ik een +1 gaf) …

Vreemd genoeg is een goede maatstaf voor een goed beveiligde en veilige SQL Server het feit dat xp_CmdShell is ingeschakeld.Wat ik daarmee bedoel, is dat als je systeem veilig genoeg is, je je geen zorgen hoeft te maken over triviale zaken, zoals het inschakelen en gebruiken van xp_CmdShell.

Vooral vanaf SQL Server 2005 is er vrijwel geen reden voor waarom andere gebruikers dan DBA s privs zouden moeten hebben groter dan PUBLIC privs en privs zouden moeten EXECUTE op opgeslagen procedures in een correct vergrendeld systeem. In feite, correct geïmplementeerd, zouden gebruikers met PUBLIC privs in staat moeten zijn om een opgeslagen procedure uit te voeren die aanroepen naar xp_CmdShell bevat zonder xp_CmdShell rechtstreeks zelf te kunnen draaien.

Ik vind het ironisch dat MS de opdrachtshell-proxy heeft gemaakt om gebruikers met weinig privacy toe te staan xp_CmdShell direct uit te voeren wanneer ze niet eens een tabel zouden moeten kunnen zien.