Kan xp_cmdshell noen gang brukes trygt i en lagret prosess, og er det noen situasjoner som det egentlig ikke er noe annet alternativ for? Med andre ord, bør bruken av den i en lagret prosess alltid bli markert som et sikkerhetsproblem (slik det er anbefalt av en kjent kildekodeanalysator)?
Sagt på en annen måte, er du enig i følgende påstand ( direkte sitat)?
Funksjonen xp_cmdshell kan ikke brukes trygt. Den skal ikke brukes.
Kommentarer
- For de ukjente » xp_cmdshell «, det er » en utvidet lagret prosedyre levert av Microsoft og lagret i hoveddatabasen. Denne prosedyren lar deg utstede operativsystemkommandoer direkte til Windows-kommandoskallet via T-SQL-kode. » Yikes !!
- Nei, jeg har ikke ‘ er ikke enig. Det kan absolutt brukes trygt ved hjelp av minst to forskjellige metoder som jeg kjenner til, og en av dem er ganske darned enkel å installere. Problemet er at BOL ikke ‘ t faktisk forteller deg hvordan du gjør det.
Svar
Det er alltid en risiko . Det bør alltid gjennomgås . Det kan skikkelig reduseres .
Det er legitime bruksområder, noen ganger nødvendigheter, men se nøye på innspillene dine!
Kommentarer
- Hva med problemet at det ikke er noen måte å begrense en bruker til en forhåndsdefinert gruppe operasjoner, og derfor tillater ethvert privilegium at brukeren kan utføre en hvilken som helst kommandostreng, dvs. det ‘ t tillate granularitet av privilage eller uttalt forskjellige kontroll blir full kontroll?
- Nå er SQL Server et sekundært for meg, så fortell meg om jeg ‘ m feil: Å gi en bruker utføre tillatelser til den lagrede prosedyren gjør at prosedyren kan kjøres av dem. Det tillater dem ikke å endre det, og det ‘ t innebærer å gi tillatelser for alt som brukes av den lagrede prosedyren. Hvis de må få
xp_cmdshelltillatelser for å kjøre en lagret prosedyre som inneholder den, så har du ‘ definitivt et problem. Jeg ‘ er rimelig sikker på at det ikke er nødvendig – prosedyren bør ikke eies av den vanlige brukeren. - @TobyS … det er problemet med de slags utsagn. Kort svar: xp_cmdshell er ond. Langt svar: det kommer an på. 😉
- @SteveS – gjeldende versjon av MSSQL lar deg sette en annen OS-konto for å kjøre xp_cmdshell-kommandoer under.
- @JeffFerland … deg skrev » Jeg ‘ er rimelig trygg på at det ikke er nødvendig – prosedyren skal ikke eies av den vanlige brukeren. » At ‘ er 100% riktig. Det ‘ er ikke noe behov for at brukeren selv vet om en tabell er involvert, husk ikke xp_CmdShell. Og ja, det er ‘ ganske enkelt å sette opp.
Svar
Å slå av xp_CmdShell er litt som å legge et slør over råtnende kjøtt. Det bringer en falsk følelse av sikkerhet til bordet, og fluene kan fremdeles komme på kjøttet. Tillat meg å forklare.
Hvem kan bruke xp_CmdShell? Det er riktig. Bare personer / app logger på med «SA» privs eller personer som du gjorde den forferdelige feilen med å gi en proxy, kan bruke den.
Neste spørsmål. Hvis du har slått av xp_CmdShell, hvem er de eneste som kan slå den på igjen? Korrigere igjen! Bare personer / apper med «SA» privs kan slå den på igjen.
Så hva er egentlig problemet med xp_CmdShell som en sikkerhetsrisiko ? Svaret er xp_CmdShell er IKKE en sikkerhetsrisiko. Dårlig sikkerhet er den eneste sikkerhetsrisikoen. Hvis en hacker eller en ondsinnet intern bruker kommer inn i systemet med «SA» privs, kan de slå på xp_CmdShell på i momenter. Ja, den handlingen blir logget, men det gir bare dokumentert vitnesbyrd om at sikkerhet manglet grovt til å begynne med.
Å slå av xp_CmdShell gjør ikke noe for sikkerhet bortsett fra å gi en sjanse for den delen av hackerkoden til å slå den på igjen for å kjøre.
Jeg vil si det igjen. xp_CmdShell er ikke en sikkerhetsrisiko. Bare dårlig sikkerhet er en sikkerhetsrisiko. Løs sikkerheten din, og slå deretter på xp_CmdShell. Det er et fantastisk verktøy, og du går glipp av det på grunn av dårlig sikkerhetspraksis og myte.
Kommentarer
- Jeg er helt enig med deg, Jeff. En angriper som fikk syadmin-privilegier, kunne opprette en SQL Agent-jobb som eies av sa med en CmdExec-trinn og oppnå det samme som xp_cmdshell. Han kunne også lage en CLR-lagret prosedyre som starter en prosess. Hvordan ville det være forskjellig fra xp_cmdshell?Å sikre serveren riktig er den eneste måten å forhindre sikkerhetsrisiko.
- Ah, min ol ‘ venn. Takk for tilbakemeldingen. Greit å » se » deg igjen.
- +1 du tar feil, men jeg liker at du tar feil fordi du oppfordrer folk til å være mindre sikre, noe som gjør interessen til et morsommere sted. Ja Installer SQL Server på alt, og ja den ekstra delen om hvordan det er enkelt å fikse med konfigurasjon. Elsker det < 3. Dens SQL-servere for 2020 og 9/10 kommer ikke til å herdes riktig – men skylder selvfølgelig DB-administratoren XD
- Heh … Jeg ‘ Jeg gir du samme pluss en for å ha tatt feil. Jeg skulle ønske jeg kunne gi deg et pluss for å ha tatt feil når du tenker at deaktivering av xp_CmdShell i det hele tatt gjør noe for å » herde » en server. ‘ t.
Svar
tror jeg «det skal ikke brukes» er nok ganske godt råd. Det «er ikke et kategorisk» Det «er alltid usikkert», men snarere en erkjennelse av at xp_cmdshell er farlig, og enhver bruk av det er grunn til bekymring og nøye gransking.
Og selv om du tror du vet hvordan du kan unngå sikkerhetsrisikoen, er xp_cmdshell fortsatt ikke det beste verktøyet å bruke. Oddsen er at det finnes en bedre løsning (en som også tilfeldigvis er mindre risikabel).
Svar
«Med stor makt kommer stort ansvar. » Når det er sagt, tror jeg xp_cmdshell er en av de verste sikkerhetstogforbedringene for å gjøre det ut av Redmond.
Rediger: 2020, som en penetrasjonstester i 10+ år – xp_cmdshell fortsatt en av de mest skremmende sikkerhetsrisikene jeg har opplevd fordi den har den beste kombinasjonen av; er bredt spredt, brukt av viktige virksomheter som banker, og maksimal innvirkning. SQLmap kan brukes til å få SA og aktivere xp_cmdshell på nytt … bare ved bruk av SQL Injection i en webapp.
Som en ingeniør til en annen, takk Microsoft – jeg kunne bokstavelig talt ikke ha fått disse skjellene uten deg.
Kommentarer
- Jeg vet det ‘ er et gammelt spørsmål, men jeg må virkelig si det: Jeg ‘ Jeg overrasket over at 3 personer tok trollingen din på alvor nok til å oppstemme svaret ditt.
- @spaghettidba Jeg er dødelig seriøs, da en pentester
xp_cmdshell()er en gudssending. Det som gjør det så ille er at ingen hos Microsoft engang tenker å løse dette problemet. Jeg ‘ er veldig glad for å møte Microsoft-produkter og applikasjoner bygget på Microsoft-plattformen fordi de er svake. Morsomt faktum, den første 0-dagen min var i et sikkerhetsprodukt fra Microsoft da jeg var 16, som var for mer enn et tiår siden. - @rook – Det ‘ s ikke ofte at jeg får snakke med en ekte PEN-tester, så jeg ‘ har fått benytte anledningen til å spørre (ikke på utkikk etter en kamp … Jeg ‘ er ærlig og virkelig interessert i din gode opplevelse), hvis du KAN ‘ T kommer inn i noen ‘ s goodie locker med SysAdmin privs, har du fortsatt vært i stand til å bruke xp_CmdShell som angriper selv om den ‘ er aktivert? Er det i så fall en måte å beskytte mot det?
- @Jeff Moden. JA , så sqlmap gjør dette ganske bra. Selv om du ikke er SA – på grunn av spørringsstapling, kan du logge på SA-kontoen ved hjelp av en SQL-SPØRSMÅL – ja, et injisert SQL-spørsmål kan brukes til å få SA og deretter aktivere en hvilken som helst kommando. Du trenger fortsatt å vite passordet … men det kan være tøft og hvis dette angrepet ikke ble tatt i betraktning ‘ t, kunne SA-kontoen ha et svakt passord … og jeg har sett dette skje mange ganger, selv i banker. Ikke en SQL-Server-ekspert, men jeg tror det er herding som kan forhindre dette angrepet … men ikke standard !!!! SQLMap for seier!
Svar
Hva slags sikkerhet blir brukt i SQL Server-miljøet ditt, Mixed eller Integrert (Windows)? Hvor mange er i sysadmin SQL Server-rollen? MS beste praksis krever integrert godkjenning (ingen innlogging, ingen SQL-pålogginger) og bare to i sysadmin SQL Server-rollen. Jeg hevder at ved å følge disse beste fremgangsmåtene, reduseres eksponeringen i stor grad. Videre gir xp_cmdshell (pre sqlcmd-modus og pre-Powershell) muligheten til å kopiere transaksjonsloggfiler fra produksjonsserveren til DR-serveren hundrevis av miles unna fra en planlagt SQL Agent-jobb. Ikke noe ondt her, men som den ene plakaten uttrykte, «det kommer an».
Svar
For å understreke jl01 » s svar (som jeg ga +1 til) …
Merkelig nok er et godt mål på en riktig sikret og sikker SQL Server å ha xp_CmdShell aktivert.Det jeg mener med det er at hvis systemet ditt er sikkert nok, trenger du ikke å bekymre deg for trivielle saker som xp_CmdShell blir aktivert OG BRUKT.
Spesielt fra og med SQL Server 2005 er det praktisk talt ingen grunn hvorfor andre brukere enn DBA skal ha privs som er større enn OFFENTLIG privs og EXECUTE privs på lagrede prosedyrer i et ordentlig låst system. Faktisk, implementert riktig, bør brukere med PUBLIC privs kunne utføre en lagret prosedyre som inneholder anrop til xp_CmdShell uten å kunne kjøre xp_CmdShell direkte selv.
Jeg synes det er ironisk at MS opprettet kommandoskallet proxy for å tillate brukere med lavt privatpersoner å kjøre xp_CmdShell direkte når de ikke engang kunne se en tabell.