xp_cmdshell: Pitäisikö sitä koskaan käyttää?

Se on aina riski . Se tulisi aina tarkistaa . Sitä voidaan asianmukaisesti lieventää .

On olemassa laillisia käyttötarkoituksia, joskus välttämättömiä, mutta tarkkaile palautettasi tarkkaan!

Kommentit

• Mikä on ongelma, että käyttäjää ei ole mahdollista rajoittaa ennalta määritettyyn toimintaryhmään, joten minkä tahansa käyttöoikeuksien myöntämisen avulla käyttäjä voi suorittaa minkä tahansa komentosarjan, ts. se ei ’ eivät salli etuoikeuden tarkkuutta tai toisin sanoen, mistä tahansa ohjauksesta tulee täydellinen hallinta?
• Nyt SQL Server on toissijainen minulle, joten kerro minulle ’ m väärä: Käyttäjän käyttöoikeuksien myöntäminen tallennetulle menettelylle antaa heille mahdollisuuden suorittaa kyseinen menettely. Se ei salli heidän muokata sitä, eikä se merkitse ’ ei oikeuksien myöntämistä kaikelle, mitä kyseinen tallennettu prosessi käyttää. Jos heille on myönnettävä xp_cmdshell käyttöoikeudet sitä sisältävän tallennetun menettelyn suorittamiseen, sinulla on ’ varmasti ongelma. Olen ’ olen kohtuullisen varma siitä, että sitä ei vaadita – normaalin käyttäjän ei pitäisi omistaa menettelyä.
• @TobyS … siinä on ongelma näiden käyttäjien kanssa erilaisia lausuntoja. Lyhyt vastaus: xp_cmdshell on paha. Pitkä vastaus: se riippuu. 😉
• @SteveS – MSSQL: n nykyisen version avulla voit asettaa toisen käyttöjärjestelmän tilin suorittamaan xp_cmdshell-komentoja alla.
• @JeffFerland … sinä kirjoitti ” I ’ m kohtuullisen varma, että sitä ei vaadita – menettelyn ei pitäisi olla tavallisen käyttäjän omistuksessa. ” Se, että ’ on 100% oikein. ’ käyttäjän ei tarvitse edes tietää, onko taulukko mukana, xp_CmdShell ei välitä. Ja kyllä, se ’ on melko helppo asentaa.

xp_CmdShellin sammuttaminen on vähän kuin verhon asettaminen mätänevälle lihalle. Se tuo väärän turvallisuuden tunteen pöydälle ja kärpäset voivat silti päästä lihaan. Sallikaa minun selittää.

Kuka voi käyttää xp_CmdShell-tiedostoa? Se on totta. Vain ihmiset / sovelluksen käyttäjätunnukset, joilla on ”SA” -käyttäjät, tai henkilöt, joille teit kauhean virheen myöntämällä välityspalvelimen, voivat käyttää sitä.

Seuraava kysymys. Jos xp_CmdShell on pois päältä, kuka ovat ainoat ihmiset, jotka voivat ottaa sen takaisin käyttöön? Korjaa uudelleen! Vain ihmiset / sovellukset, joilla on ”SA” -käyttöoikeudet, voivat ottaa sen takaisin käyttöön.

Joten mikä on todellinen ongelma, kun xp_CmdShell on tietoturvariski ? Vastaus on, että xp_CmdShell EI OLE tietoturvariski. Heikko turvallisuus on ainoa turvallisuusriski. Jos hakkeri tai haitallinen sisäinen käyttäjä pääsee järjestelmään ”SA” -käyttöoikeuksilla, he voivat ottaa xp_CmdShell-toiminnon käyttöön hetkessä. Joo, tämä toiminto kirjataan, mutta se antaa vain dokumentoidun todistuksen siitä, että turvallisuudesta puuttui aluksi karkeasti.

xp_CmdShell-toiminnon poistaminen käytöstä ei tee turvallisuudelle mitään muuta kuin antaa mahdollisuuden hakkerikoodin kyseiselle osalle käynnistää se uudelleen.

Sanon sen uudelleen. xp_CmdShell ei ole tietoturvariski. Vain huono turvallisuus on turvallisuusriski. Korjaa suojaus ja kytke sitten xp_CmdShell päälle. Se on hieno työkalu, ja sinulta puuttuu se huonojen turvallisuuskäytäntöjen ja myyttien takia.

Kommentit

• Olen täysin samaa mieltä kanssasi, Jeff. Hyökkääjä, joka sai syadmin-käyttöoikeudet, voisi luoda sa: n omistaman SQL Agent -työn CmdExec-työvaiheella ja saavuttaa saman kuin xp_cmdshell. Hän voisi myös luoda CLR-tallennetun menettelyn, joka aloittaa prosessin. Kuinka se eroaisi xp_cmdshellistä?Palvelimen oikea suojaaminen on ainoa tapa estää tietoturvariskit.
• Ah, ol ’ ystäväni. Kiitos palautteestasi. Hyvä ” nähdä ” sinut uudelleen.
• +1 olet väärässä, mutta pidän väärässä koska rohkaiset ihmisiä olemaan vähemmän turvallisia, mikä tekee kiinnostuksesta hauskempaa paikkaa. Kyllä Asenna SQL Server kaikkeen ja kyllä ylimääräinen osa siitä, kuinka se on helppo korjata kokoonpanolla. Rakasta sitä < 3. Sen vuoden 2020 ja 9/10 SQL-palvelimia ei tule kovettua oikein – mutta tietysti syytän DB-järjestelmänvalvojan XD: tä
• Heh … I ’ ll sinulle sama plus yksi väärästä. Toivon, että voisin antaa sinulle plus-arvon väärästä ajattelusta, että xp_CmdShell-palvelun poistaminen käytöstä tekee mitään ” kovettamaan ” palvelinta. Se ei vain ’ t.

Luulen ”Sitä ei pidä käyttää” on todennäköisesti aika hyvä neuvoja. Se ei ole kategorinen ”se” aina epävarma ”, vaan sen tunnustaminen, että xp_cmdshell on vaarallinen, ja sen käyttö on syytä huoleen ja huolelliseen tarkasteluun.

Ja Vaikka luulet tietävän kuinka välttää tietoturvariskit, xp_cmdshell ei silti todennäköisesti ole paras työkalu käytettäväksi. On todennäköistä, että on olemassa parempi ratkaisu (joka myös satunnaisesti sattuu olemaan vähemmän riskialtista).

”Kanssa suuresta voimasta tulee suuri vastuu. ” Tästä huolimatta mielestäni xp_cmdshell on yksi pahimmista turvajunien haavoista päästä Redmondista.

Muokkaa: 2020, levinneisyystestaajana yli 10 vuoden ajan – xp_cmdshell edelleen yksi kauhistuttavimmista turvallisuusriskeistä, joita olen kohdannut, koska siinä on paras yhdistelmä of; se on laajalle levinnyt, tärkeiden yritysten, kuten pankkien, käyttämä ja suurin vaikutus. SQLmapia voidaan käyttää SA: n hankkimiseen ja xp_cmdshellin ottamiseen uudelleen käyttöön käyttämällä vain SQL-injektiota web-sovelluksessa.

Insinöörinä toiseen, kiitos Microsoft – kirjaimellisesti en olisi voinut saada näitä kuoria ilman sinua.

Kommentit

• Tiedän sen ’ on vanha kysymys, mutta minun on todellakin sanottava se: Olen ’ yllättynyt siitä, että 3 ihmistä otti uistelusi vakavasti tarpeeksi voidakseni äänestää vastaustasi.
• @spaghettidba Olen kuollut vakavasti, koska katukivi xp_cmdshell() on jumalan lähettämä. Mikä tekee siitä niin pahan, että kukaan Microsoftissa ei edes ajattele korjata tätä ongelmaa. Olen ’ iloinen voidessani kohdata Microsoft-tuotteita ja -sovelluksia, jotka on rakennettu Microsoft-alustalle, koska ne ovat heikkoja. Hauska tosiasia, että ensimmäinen 0 päiväni oli Microsoftin tietoturvatuotteessa, kun olin 16-vuotias, mikä oli yli vuosikymmen sitten.
• @rook – It ’ Ei ole usein, että saan puhua todellisen PEN-testaajan kanssa, joten minun on käytettävä tätä tilaisuutta kysyäkseni (etsimättä taistelua … I iv id = ”.) ’ 7648e728d5 ”>

Millaista suojausta SQL Server -ympäristössäsi käytetään, Mixed vai integroitu (Windows)? Kuinka moni on sysadmin SQL Server -roolissa? MS: n parhaat käytännöt edellyttävät integroitua todennusta (ei SA-kirjautumista, ei SQL-kirjautumista) ja vain kaksi sysadmin SQL Server -roolissa. Olen sitä mieltä, että näiden parhaiden käytäntöjen noudattaminen lieventää huomattavasti käyttäjän altistumista. Lisäksi xp_cmdshell (pre sqlcmd -tila ja pre-Powershell) antaa mahdollisuuden kopioida tapahtumalokitiedostot tuotantopalvelimelta DR-palvelimelle satojen mailien päässä ajoitetusta SQL Agent -teos. Tässä ei ole pahaa, mutta kuten yksi julistaja sanoo, ”se riippuu”.

Korostamaan jl01 Vastaus (jonka annoin + 1-merkinnän) …

Kummallista kyllä, hyvä toimenpide oikein suojatusta ja turvallisesta SQL Serveristä on, että xp_CmdShell on todella otettu käyttöön.Tarkoitan sillä, että jos järjestelmäsi on riittävän turvallinen, sinun ei tarvitse huolehtia sellaisista vähäpätöisistä asioista kuten xp_CmdShell otetaan käyttöön ja käytetään.

Erityisesti SQL Server 2005: stä lähtien siihen ei ole käytännössä mitään syytä miksi muilla käyttäjillä kuin DBA: lla pitäisi olla suuremmat käyttöoikeudet kuin JULKISET ja SUORITA yksityisyydet tallennetuissa menettelyissä oikein lukitussa järjestelmässä. Oikein toteutettuna käyttäjien, joilla on JULKISET käyttöoikeudet, pitäisi pystyä suorittamaan tallennettu menettely, joka sisältää puhelut xp_CmdShellille, ilman että he voivat itse suorittaa xp_CmdShell-tiedostoa.

Minusta on ironista, että MS loi komentokäskyn välityspalvelimen. sallia matalan yksityisyyden käyttäjien suorittaa xp_CmdShell suoraan, kun heidän ei edes pitäisi nähdä taulukkoa.