Kan xp_cmdshell nogensinde bruges sikkert i en gemt proc, og er der nogen situationer, hvor der virkelig ikke er nogen anden mulighed? Med andre ord, skal dens anvendelse inden for en lagret proc altid markeres som et sikkerhedsproblem (som det anbefales af en velkendt kildekodeanalysator)?
Sagt på en anden måde, er du enig i følgende udsagn ( direkte citat)?
Funktionen xp_cmdshell kan ikke bruges sikkert. Det bør ikke bruges.
Kommentarer
- For de ukendte ” xp_cmdshell “, det er ” en udvidet lagret procedure leveret af Microsoft og gemt i masterdatabasen. Denne procedure giver dig mulighed for at udstede operativsystemkommandoer direkte til Windows-kommandoskallen via T-SQL-kode. ” Yikes !!
- Nej, jeg don ‘ er ikke enig. Det kan absolut bruges sikkert ved hjælp af mindst 2 forskellige metoder, som jeg kender til, og en af dem er ret darnet let at opsætte. Problemet er, at BOL ikke ‘ faktisk ikke fortæller dig, hvordan du gør det.
Svar
Det er altid en risiko . Det skal altid være revideret . Det kan korrekt afbødes .
Der er legitime anvendelser, nogle gange nødvendigheder, men se dit input nøje!
Kommentarer
- Hvad med problemet, at der ikke er nogen måde at begrænse en bruger til en foruddefineret gruppe af operationer, og derfor giver ethvert privilegietildeling brugeren mulighed for at udføre en kommandostreng, dvs. det ‘ t tillader granularitet af privilage eller angivet forskellige enhver kontrol bliver fuldstændig kontrol?
- Nu er SQL Server en sekundær for mig, så fortæl mig, hvis jeg ‘ m forkert: Ved at give en bruger udføre tilladelser til den lagrede procedure kan denne procedure køres af dem. Det tillader dem ikke at ændre det, og det betyder ikke ‘ at give tilladelser til alt, hvad der bruges af den gemte procedure. Hvis de skal have
xp_cmdshelltilladelser til at køre en gemt procedure, der indeholder den, så har du ‘ helt sikkert et problem. Jeg ‘ er rimelig sikker på, at det ikke er nødvendigt – proceduren bør ikke ejes af den almindelige bruger. - @TobyS … det er problemet med dem slags udsagn. Kort svar: xp_cmdshell er ond. Langt svar: det afhænger. 😉
- @SteveS – den aktuelle version af MSSQL giver dig mulighed for at indstille en anden OS-konto til at køre xp_cmdshell-kommandoer under.
- @JeffFerland … dig skrev ” I ‘ m med rimelig tillid til, at det ikke er nødvendigt – proceduren bør ikke ejes af den almindelige bruger. ” At ‘ er 100% korrekt. Der er ‘ intet behov for, at brugeren selv ved, om en tabel er involveret, skal du ikke tænke på xp_CmdShell. Og ja, det er ‘ ret nemt at opsætte.
Svar
At slukke for xp_CmdShell er lidt som at lægge et slør over rådnende kød. Det bringer en falsk følelse af sikkerhed til bordet, og fluerne kan stadig komme til kødet. Tillad mig at forklare.
Hvem kan bruge xp_CmdShell? Det er rigtigt. Kun personer / app logger ind med “SA” privs eller personer, som du begik den forfærdelige fejl ved at tildele en proxy, kan bruge den.
Næste spørgsmål. Hvis du har slået xp_CmdShell fra, hvem er de eneste mennesker, der kan tænde det igen? Ret igen! Kun personer / apps med “SA” privs kan tænde det igen.
Så hvad er det virkelige problem med xp_CmdShell som en sikkerhedsrisiko ? Svaret er xp_CmdShell er IKKE en sikkerhedsrisiko. Dårlig sikkerhed er den eneste sikkerhedsrisiko. Hvis en hacker eller en ondsindet intern bruger kommer ind i systemet med “SA” privs, kan de slå xp_CmdShell til i øjeblikke. Ja, den handling bliver logget, men det giver kun dokumenteret vidnesbyrd om, at sikkerheden manglede groft til at begynde med.
At slukke for xp_CmdShell gør intet for sikkerheden undtagen at give en chance for den del af en hackerkode til at tænde den igen til at køre.
Jeg siger det igen. xp_CmdShell er ikke en sikkerhedsrisiko. Kun dårlig sikkerhed er en sikkerhedsrisiko. Ret din sikkerhed, og tænd derefter xp_CmdShell. Det er et vidunderligt værktøj, og du går glip af det på grund af dårlig sikkerhedspraksis og myte.
Kommentarer
- Jeg er helt enig med dig, Jeff. En hacker, der fik syadmin-rettigheder, kunne oprette et SQL Agent-job, der ejes af sa med et CmdExec-jobtrin og opnå det samme som xp_cmdshell. Han kunne også oprette en CLR-lagret procedure, der starter en proces. Hvordan ville det være anderledes end xp_cmdshell?At sikre serveren korrekt er den eneste måde at forhindre sikkerhedsrisici på.
- Ah, min ol ‘ ven. Tak for tilbagemeldingen. Godt at ” se ” dig igen.
- +1 du tager fejl, men jeg kan godt lide, at du tager fejl fordi du opmuntrer folk til at være mindre sikre, hvilket gør interessen til et sjovere sted. Ja Installer SQL Server på alt, og ja den ekstra del om, hvordan det er let at rette med konfiguration. Elsker det < 3. Dens SQL-servere fra 2020 og 9/10 bliver ikke hærdet korrekt – men skylder naturligvis DB-administratoren XD
- Heh … Jeg ‘ Jeg giver du den samme plus en for at være forkert. Jeg ville ønske, jeg kunne give dig et plus for at være forkert ved at tro, at deaktivering af xp_CmdShell overhovedet gør noget for at ” hærde ” en server. ‘ t.
Svar
Jeg tror “det skal ikke bruges” er sandsynligvis ret godt råd. Det “er ikke et kategorisk” Det “er altid usikkert”, men snarere en anerkendelse af, at xp_cmdshell er farligt, og enhver brug af det er grund til bekymring og omhyggelig kontrol.
Og selvom du tror, du ved, hvordan du undgår sikkerhedsrisici, er xp_cmdshell stadig sandsynligvis ikke det bedste værktøj at bruge. Odds er, at der er en bedre løsning (en, der tilfældigvis også tilfældigvis er mindre risikabel).
Svar
“Med stor magt kommer stort ansvar. ” Når det er sagt, tror jeg xp_cmdshell er en af de værste sikkerhedstogforbedringer for at gøre det ud af Redmond.
Rediger: 2020, som en penetrationstester i mere end 10 år – xp_cmdshell stadig en af de mest skræmmende sikkerhedsrisici, jeg er stødt på, fordi den har den bedste kombination af; udbredt, brugt af vigtige virksomheder som banker, og maksimal effekt. SQLmap kan bruges til at få SA og genaktivere xp_cmdshell … kun ved hjælp af SQL Injection i en webapp.
Som en ingeniør til en anden, tak Microsoft – jeg kunne bogstaveligt talt ikke have fået disse skaller uden dig.
Kommentarer
- Jeg ved det ‘ er et gammelt spørgsmål, men jeg må virkelig sige det: Jeg ‘ Jeg er overrasket over, at 3 personer tog din trolling alvorligt nok til at opstemme dit svar.
- @spaghettidba Jeg er død alvorlig, da en pentester
xp_cmdshell()er en gudssend. Hvad der gør det så dårligt er, at ingen hos Microsoft engang tænker at løse dette problem. Jeg ‘ er meget glad for at støde på Microsoft-produkter og applikationer bygget på Microsoft-platformen, fordi de er svage. Sjovt, min første 0-dag var i et Microsoft-sikkerhedsprodukt, da jeg var 16, hvilket var for mere end et årti siden. - @rook – Det ‘ s ikke ofte, at jeg kommer til at tale med en rigtig PEN-tester, så jeg ‘ har været nødt til at benytte lejligheden til at spørge (ikke på udkig efter en kamp … Jeg ‘ er ærligt og virkelig interesseret i din gode oplevelse), hvis du KAN ‘ T kommer ind i nogen ‘ s goodie locker med SysAdmin privs, har du stadig været i stand til at bruge xp_CmdShell som en angriber, selvom det ‘ er aktiveret? Er der i så fald en måde at beskytte mod det?
- @Jeff Moden. JA , så sqlmap gør dette ret godt. Selvom du ikke er SA – på grund af stabling af forespørgsler, kan du logge ind på SA-kontoen ved hjælp af en SQL-FORESPØRGSEL – ja, en injiceret SQL-forespørgsel kan bruges til at få SA og derefter genaktivere enhver kommando. Du har stadig brug for at kende adgangskoden … men den kan tvinges hårdt, og hvis dette angreb ikke blev taget i betragtning ‘, kunne SA-kontoen have en svag adgangskode … og jeg har set dette ske mange gange, selv i banker. Ikke en SQL-Server-ekspert, men jeg tror, der er hærdning, der kan forhindre dette angreb … men ikke standard !!!! SQLMap til sejren!
Svar
Hvilken slags sikkerhed bruges i dit SQL Server-miljø, blandet eller Integreret (Windows)? Hvor mange er i sysadmin SQL Server-rollen? MS bedste praksis kræver integreret godkendelse (ingen sa login, ingen SQL-login) og kun to i rollen sysadmin SQL Server. Jeg hævder, at ved at følge disse bedste fremgangsmåder i høj grad mindsker eksponeringen. Yderligere giver xp_cmdshell (pre sqlcmd-tilstand og pre-Powershell) muligheden for at kopiere transaktionslogfiler fra produktionsserveren til DR-serveren hundreder af miles væk inden for en planlagt SQL Agent-job. Intet ondt her, men som den ene plakat sagde, “det afhænger”.
Svar
For at understrege jl01 ” s svar (som jeg gav +1 til) …
Mærkeligt nok er et godt mål for en korrekt sikret og sikker SQL Server faktisk at have xp_CmdShell aktiveret.Hvad jeg mener med det er, at hvis dit system er sikkert nok, skal du ikke bekymre dig om trivielle forhold som xp_CmdShell, der er aktiveret OG BRUGT.
Især fra SQL Server 2005 er der næsten ingen grund hvorfor andre brugere end DBAer skal have privs større end PUBLIC privs og EXECUTE privs på lagrede procedurer i et korrekt låst system. Faktisk, implementeret korrekt, skal brugere med PUBLIC privs være i stand til at udføre en lagret procedure, der indeholder opkald til xp_CmdShell uden at være i stand til at køre xp_CmdShell direkte selv. for at tillade, at brugere med lavt privatliv kører xp_CmdShell direkte, når de ikke engang skulle kunne se en tabel.