Kan xp_cmdshell någonsin användas säkert i en lagrad proc och finns det några situationer för vilka det verkligen inte finns något annat alternativ? Med andra ord, bör dess användning inom en lagrad proc alltid flaggas som ett säkerhetsproblem (som rekommenderas av en välkänd källkodsanalysator)?
Säg annorlunda, skulle du hålla med följande uttalande ( direkt citat)?
Funktionen xp_cmdshell kan inte användas säkert. Den ska inte användas.
Kommentarer
- För de som inte känner till ” xp_cmdshell ”, det är ” en utökad lagrad procedur som tillhandahålls av Microsoft och lagras i huvuddatabasen. Med den här proceduren kan du utfärda operativsystemskommandon direkt till Windows-kommandoskalet via T-SQL-kod. ” Yikes !!
- Nej, jag don ’ håller inte med. Det kan absolut användas säkert med minst två olika metoder som jag känner till och en av dem är ganska darned lätt att installera. Problemet är att BOL inte ’ inte berättar hur du gör det.
Svar
Det är alltid en risk . Det bör alltid granskas . Det kan korrekt lindras .
Det finns legitima användningsområden, ibland nödvändigheter, men se noga på din inmatning!
Kommentarer
- Vilket av problemet är att det inte finns något sätt att begränsa en användare till en fördefinierad grupp av operationer och därför tillåter varje beviljande av behörighet användaren att köra vilken kommandosträng som helst, det vill säga ’ t tillåter granularitet av privilage eller anges annorlunda någon kontroll blir fullständig kontroll?
- Nu är SQL Server en sekundär för mig, så berätta om jag ’ m fel: Att bevilja en användare som kör behörigheter för den lagrade proceduren gör att proceduren kan köras av dem. Det tillåter dem inte att ändra det, och det innebär inte ’ att bevilja behörigheter för allt som används av den lagrade proceduren. Om de måste ges
xp_cmdshellbehörighet för att köra en lagrad procedur som innehåller den, så har du ’ definitivt ett problem. Jag ’ är rimligt säker på att det inte krävs – proceduren bör inte ägas av den vanliga användaren. - @TobyS … det är problemet med dem olika påståenden. Kort svar: xp_cmdshell är ond. Långt svar: det beror på. 😉
- @SteveS – nuvarande version av MSSQL låter dig ställa in ett annat OS-konto för att köra xp_cmdshell-kommandon under.
- @JeffFerland … du skrev ” Jag ’ är rimligt säker på att det inte krävs – proceduren bör inte ägas av den vanliga användaren. ” Att ’ är 100% korrekt. Det finns inget ’ för användaren att ens veta om en tabell är involverad, tänk inte på xp_CmdShell. Och ja, det är ’ ganska enkelt att installera.
Svar
Att stänga av xp_CmdShell är lite som att lägga en slöja över ruttnande kött. Det ger en falsk känsla av säkerhet vid bordet och flugorna kan fortfarande komma till köttet. Låt mig förklara.
Vem kan använda xp_CmdShell? Det stämmer. Endast personer / appar loggar in med ”SA” privs eller personer som du gjorde det hemska misstaget att bevilja en proxy till kan använda den.
Nästa fråga. Om du har stängt av xp_CmdShell, vem är de enda personerna som kan slå på den igen? Korrigera igen! Endast personer / appar med ”SA” privs kan aktivera den igen.
Så, vad är det som är det verkliga problemet med xp_CmdShell som en säkerhetsrisk? ? Svaret är xp_CmdShell är INTE en säkerhetsrisk. Dålig säkerhet är den enda säkerhetsrisken. Om en hackare eller en skadlig intern användare kommer in i systemet med ”SA” privs, kan de aktivera xp_CmdShell i moment. Ja, den åtgärden loggas men det ger bara dokumenterat vittnesbörd om att säkerheten helt saknades till att börja med.
Att stänga av xp_CmdShell gör ingenting för säkerhet förutom att ge en chans för den delen av en hackarkod att sätta på den igen för att köra.
Jag säger det igen. xp_CmdShell är inte en säkerhetsrisk. Endast dålig säkerhet är en säkerhetsrisk. Åtgärda din säkerhet och slå sedan på xp_CmdShell. Det är ett underbart verktyg och du missar det på grund av dåliga säkerhetsrutiner och myter.
Kommentarer
- Jag håller helt med dig, Jeff. En angripare som fick syadmin-behörigheter kan skapa ett SQL Agent-jobb som ägs av sa med ett CmdExec-jobbsteg och uppnå samma som xp_cmdshell. Han kunde också skapa en CLR-lagrad procedur som startar en process. Hur skulle det skilja sig från xp_cmdshell?Att säkra servern ordentligt är det enda sättet att förhindra säkerhetsrisker.
- Ah, min ol ’ vän. Tack för återkopplingen. Bra att ” se ” dig igen.
- +1 du har fel, men jag gillar att du har fel eftersom du uppmuntrar människor att vara mindre säkra, vilket gör intresset till ett roligare ställe. Ja Installera SQL Server på allt, och ja den extra delen om hur det är enkelt att fixa med konfigurationen. Älskar det < 3. Dess 2020- och 9/10 SQL-servrar kommer inte att härdas korrekt – men skylla naturligtvis DB-administratören XD
- Heh … Jag ’ jag ger du samma plus en för att ha fel. Jag önskar att jag kunde ge dig ett plus för att du hade fel när du trodde att inaktivera xp_CmdShell gör någonting alls för att ” härda ” en server. ’ t.
Svar
tror jag ”det ska inte användas” är förmodligen ganska bra råd. Det är inte ett kategoriskt ”Det” är alltid osäkert ”, utan snarare ett erkännande av att xp_cmdshell är farligt och all användning av det är anledning till oro och noggrann granskning.
Och även om du tror att du vet hur du undviker säkerhetsriskerna är xp_cmdshell fortfarande inte det bästa verktyget att använda. Oddsen är att det finns en bättre lösning (en som också råkar vara mindre riskfylld).
Svar
”Med stor makt kommer stort ansvar. ” Med detta sagt tror jag xp_cmdshell är en av de värsta säkerhetstågsvängningarna för att ta sig ur Redmond.
Redigera: 2020, som en penetrationstestare i 10+ år – xp_cmdshell fortfarande en av de mest skrämmande säkerhetsriskerna jag har stött på eftersom den har den bästa kombinationen av; är brett spridd, används av viktiga företag som banker, och maximal påverkan. SQLmap kan användas för att få SA och återaktivera xp_cmdshell … med endast SQL Injection i en webbapp.
Som ingenjör till en annan, tack Microsoft – jag kunde bokstavligen inte ha fått dessa skal utan dig.
Kommentarer
- Jag vet att det ’ är en gammal fråga, men jag måste verkligen säga det: Jag ’ jag förvånade mig över att 3 personer tog ditt trolling på allvar tillräckligt för att rösta upp ditt svar.
- @spaghettidba Jag är dödligt allvarlig, eftersom en pentester
xp_cmdshell()är en gudsändning. Vad som gör det så dåligt är att ingen hos Microsoft ens tänker lösa problemet. Jag ’ är väldigt glad över att stöta på Microsoft-produkter och applikationer som bygger på Microsoft-plattformen eftersom de är svaga. Roligt faktum, min första 0-dag var i en säkerhetsprodukt från Microsoft när jag var 16, vilket var för mer än ett decennium sedan. - @rook – Det ’ s inte ofta att jag får prata med en riktig PEN-testare så jag ’ måste ta tillfället i akt att fråga (inte letar efter en kamp … Jag ’ är ärligt och verkligen intresserad av din goda upplevelse), om du KAN ’ T komma in i någon ’ s goodie locker med SysAdmin privs, har du fortfarande kunnat använda xp_CmdShell som angripare även om det ’ är aktiverat? Om så är fallet, finns det ett sätt att skydda mot det?
- @Jeff Moden. JA , så sqlmap gör det ganska bra. Även om du inte är SA – på grund av frågestapling kan du logga in på SA-kontot med hjälp av en SQL-FRÅGA – ja, en injicerad SQL-fråga kan användas för att få SA och sedan återaktivera alla kommandon. Du behöver fortfarande känna till lösenordet … men det kan vara tvingat och om den här attacken inte beaktades ’ kan SA-kontot ha ett svagt lösenord … och jag har sett detta hända många gånger, även i banker. Inte en SQL-Server-expert men jag tror att det finns härdning som kan förhindra denna attack … men inte standard !!!! SQLMap för att vinna!
Svar
Vilken typ av säkerhet används i din SQL Server-miljö, Mixed eller Integrerad (Windows)? Hur många är i sysadmin SQL Server-rollen? MS bästa metoder kräver integrerad autentisering (ingen inloggning, inga SQL-inloggningar) och bara två i sysadmin SQL Server-rollen. Jag hävdar att genom att följa dessa bästa metoder i hög grad mildrar exponeringen. Dessutom ger xp_cmdshell (pre sqlcmd-läge och pre-Powershell) möjligheten att kopiera transaktionsloggfiler från produktionsservern till DR-servern hundratals mil bort från en planerad SQL Agent-jobb. Inget ont här men som en affisch uttryckte, ”det beror”.
Svar
För att betona jl01 ” s svar (som jag gav +1 till) …
Konstigt nog är ett bra mått på en korrekt säker och säker SQL Server att faktiskt ha xp_CmdShell aktiverad.Vad jag menar med det är att om ditt system är tillräckligt säkert, borde du inte behöva oroa dig för triviala frågor som xp_CmdShell aktiveras OCH ANVÄNDS.
Särskilt från SQL Server 2005 finns det praktiskt taget ingen anledning varför alla andra användare än DBA: s bör ha privs som är större än PUBLIC privs och EXECUTE privs på lagrade procedurer i ett ordentligt låst system. Faktiskt, implementerat korrekt, bör användare med PUBLIC privs kunna utföra en lagrad procedur som innehåller samtal till xp_CmdShell utan att kunna köra xp_CmdShell direkt själva.
Jag tycker det är ironiskt att MS skapade kommandot shell proxy för att låta privata användare att köra xp_CmdShell direkt när de inte ens skulle kunna se en tabell.