xp_cmdshell: ar trebui să fie folosit vreodată?

Dezactivarea xp_CmdShell este un pic ca a pune un voal peste carnea putrezită. Aduce un fals sentiment de siguranță la masă, iar muștele pot ajunge încă la carne. Permiteți-mi să explic.

Cine poate folosi xp_CmdShell? Așa este. Numai persoanele care se conectează la aplicații / aplicații cu privilegiile „SA” sau persoanele cărora le-ați făcut greșeala oribilă de a acorda un proxy îl pot folosi.

Întrebarea următoare. Dacă ați dezactivat xp_CmdShell, cine sunt singurele persoane care îl pot reporni? Corectați din nou! Doar persoanele / aplicațiile cu privilegii „SA” îl pot reporni.

Deci, care este adevărata problemă cu xp_CmdShell care reprezintă un risc de securitate ? Răspunsul este xp_CmdShell NU este un risc de securitate. Securitatea slabă este singurul risc de securitate. Dacă un hacker sau un utilizator intern rău intenționat intră în sistem cu privilegiile „SA”, atunci pot activa xp_CmdShell în momente. Da, acțiunea respectivă este înregistrată, dar aceasta oferă doar mărturii documentate despre care securitatea lipsea în mare măsură pentru început.

Dezactivarea xp_CmdShell nu face nimic pentru securitate decât pentru a oferi șansa ca acea parte a codului hackerilor să o reactiveze pentru a rula.

Voi spune din nou. xp_CmdShell nu reprezintă un risc de securitate. Numai o securitate proastă este un risc de securitate. Remediați securitatea și apoi activați xp_CmdShell. Este „un instrument minunat și pierzi din cauza practicilor de securitate și a mitului.

Comentarii

• Sunt complet de acord cu tine, Jeff. Un atacator care a câștigat privilegii de administrare ar putea crea un job SQL Agent deținut de sa cu un pas CmdExec job și să obțină același lucru ca și xp_cmdshell. El ar putea crea, de asemenea, o procedură stocată CLR care începe un proces. Cum ar fi diferit de xp_cmdshell?Securizarea corectă a serverului este singura modalitate de a preveni riscurile de securitate.
• Ah, ol ‘ prieten. Vă mulțumim pentru feedback. Bine ” vă revedem „.
• +1 greșești, dar îmi place că greșești pentru că încurajați oamenii să fie mai puțin siguri, ceea ce face ca interesul să devină un loc mai distractiv. Da, instalați SQL Server pe orice și da, partea suplimentară despre modul în care este ușor de remediat cu configurarea. Îmi place < 3. Serverele SQL din 2020 și 9/10 nu vor fi întărite corect – dar, desigur, dați vina pe administratorul DB XD
• Heh … Voi da ‘ tu același plus unu pentru că ai greșit. Aș vrea să vă pot oferi un plus pentru că ați greșit când ați crezut că dezactivarea xp_CmdShell face orice pentru a ” întări ” un server. Doar nu ‘ t.

Cred „nu trebuie folosit” este probabil un sfat destul de bun. Acest lucru nu este „categoric” este „nesigur”, ci mai degrabă o recunoaștere a faptului că xp_cmdshell este periculos și că orice utilizare a acestuia este motiv de îngrijorare și examinare atentă.

Și chiar dacă credeți că știți cum să evitați riscurile de securitate, xp_cmdshell probabil că nu este cel mai bun instrument de utilizat. Șansele sunt că există o soluție mai bună (una care, de asemenea, întâmplător este mai puțin riscantă).

„Cu o mare putere vine cu o mare responsabilitate „. Acestea fiind spuse, cred că xp_cmdshell este una dintre cele mai grave provocări ale trenului de securitate care a ieșit din Redmond.

Edit: 2020, ca tester de penetrare de peste 10 ani – xp_cmdshell încă unul dintre cele mai terifiante riscuri de securitate pe care le-am întâmpinat, deoarece are cea mai bună combinație de; fiind răspândit pe scară largă, utilizat de afaceri importante precum băncile și impact maxim. SQLmap poate fi utilizat pentru a obține SA și pentru a reactiva xp_cmdshell … folosind numai SQL Injection într-o aplicație web.

Ca un inginer la altul, mulțumesc Microsoft – literalmente nu aș fi putut obține aceste cochilii fără tine.

Comentarii

• Știu că ‘ este o întrebare veche, dar chiar trebuie să o spun: ‘ m-am surprins că 3 persoane ți-au luat în serios trollingul suficient pentru a susține răspunsul dvs.
• @spaghettidba Sunt foarte serios, deoarece un pentester xp_cmdshell() este un trimis de Dumnezeu. Ceea ce o face atât de rău este că nimeni de la Microsoft nici măcar nu se gândește să rezolve această problemă. Sunt ‘ foarte bucuros că am întâlnit produse și aplicații Microsoft construite pe platforma Microsoft, deoarece acestea sunt slabe. Fapt amuzant, prima mea zi de 0 a fost într-un produs de securitate Microsoft la 16 ani, ceea ce a fost acum mai bine de un deceniu.
• @rook – It ‘ Nu de multe ori ajung să vorbesc cu un tester PEN adevărat, așa că ‘ trebuie să profitez de această ocazie pentru a întreba (nu caut o luptă … Eu ‘ sunt sincer și cu adevărat interesat de experiența voastră bună), dacă puteți ‘ să intrați în cineva ‘ goodie locker cu privilegiile SysAdmin, ați reușit în continuare să utilizați xp_CmdShell ca atacator chiar dacă ‘ este activat? Dacă da, există o modalitate de a vă proteja împotriva acestuia?
• @Jeff Moden. DA , deci sqlmap face asta destul de bine. Chiar dacă nu sunteți SA – din cauza stivuirii interogărilor, vă puteți conecta la contul SA utilizând o întrebare SQL – da, o interogare sql injectată poate fi utilizată pentru a obține SA și apoi reactivați orice comandă. Încă trebuie să cunoașteți parola … dar poate fi forțată brutal și dacă nu s-a luat în considerare acest atac, atunci contul SA ar putea avea o parolă slabă … și am văzut acest lucru întâmplându-se de multe ori, chiar și la bănci. Nu este un expert SQL-Server, dar cred că există o întărire care poate preveni acest atac … dar nu implicit !!!! SQLMap pentru câștig!

Ce tip de securitate este utilizat în mediul dvs. SQL Server, mixt sau integrat (Windows)? Câți sunt în rolul sysadmin SQL Server? Cele mai bune practici MS necesită autentificare integrată (fără conectare, fără conectări SQL) și doar două în rolul sysadmin SQL Server. Susțin că respectarea acestor cele mai bune practici atenuează foarte mult expunerea. În plus, xp_cmdshell (pre sqlcmd mode și pre-Powershell) oferă posibilitatea de a copia fișierele jurnal de tranzacții de pe serverul de producție pe serverul DR la sute de kilometri distanță dintr-un programat Slujba agentului SQL. Niciun rău aici, dar așa cum se spune în poster, „depinde”.

Pentru a sublinia jl01 ” Răspunsul (căruia i-am dat un +1) …

În mod ciudat, o măsură bună a unui server SQL securizat și sigur în mod corespunzător este să aveți xp_CmdShell activat.Ceea ce vreau să spun prin asta este că, dacă sistemul dvs. este suficient de sigur, nu ar trebui să vă faceți griji cu privire la chestiuni banale precum xp_CmdShell activat și utilizat.

În special începând cu SQL Server 2005, practic nu există niciun motiv de ce orice alt utilizator decât DBA ar trebui să aibă privilegii mai mari decât privirile PUBLICE și EXECUTĂ privirile privind procedurile stocate într-un sistem blocat corespunzător. De fapt, implementate corect, utilizatorii cu privilegii PUBLIC ar trebui să poată executa o procedură stocată care conține apeluri către xp_CmdShell fără a putea rula xp_CmdShell direct ei înșiși.

Cred că este ironic faptul că MS a creat proxy-ul shell de comandă pentru a permite utilizatorilor cu privilegii reduse să ruleze xp_CmdShell direct atunci când nici măcar nu ar trebui să poată vedea un tabel.