xp_cmdshell: dovrebbe mai essere usato?

È sempre un rischio . Dovrebbe essere sempre revisionato . Può essere adeguatamente mitigato .

Ci sono usi legittimi, a volte necessità, ma osserva attentamente il tuo contributo!

Commenti

• Qual è il problema che non cè modo di limitare un utente a un gruppo predefinito di operazioni e quindi qualsiasi concessione di privilegi consente allutente di eseguire qualsiasi stringa di comando, cioè non ‘ t consentire la granularità del privilegio o dichiarato diversamente qualsiasi controllo diventa controllo completo?
• Ora, SQL Server è secondario per me, quindi dimmi se ‘ Sbaglio: la concessione a un utente dei permessi di esecuzione sulla procedura memorizzata consente a quella procedura di essere eseguita da lui. Non consente loro di modificarlo e ‘ non implica la concessione di autorizzazioni per tutto ciò che viene utilizzato da quella procedura memorizzata. Se è necessario concedere loro le xp_cmdshell autorizzazioni per eseguire una stored procedure che la contiene, allora ‘ hai sicuramente un problema. Sono ‘ ragionevolmente sicuro che non sia necessario: la procedura non dovrebbe essere di proprietà dellutente normale.
• @TobyS … questo è il problema con quelli tipi di dichiarazioni. Risposta breve: xp_cmdshell è il male. Risposta lunga: dipende. 😉
• @SteveS – la versione corrente di MSSQL ti consente di impostare un account del sistema operativo diverso per eseguire i comandi xp_cmdshell sotto.
• @JeffFerland … tu ha scritto ” I ‘ sono ragionevolmente sicuro che non sia necessario: la procedura non dovrebbe essere di proprietà dellutente normale. ” Questo ‘ è corretto al 100%. ‘ non è necessario che lutente sappia nemmeno se è coinvolta una tabella, figuriamoci xp_CmdShell. E sì, ‘ è abbastanza facile da configurare.

Disattivare xp_CmdShell è un po come mettere un velo sulla carne in decomposizione. Porta un falso senso di sicurezza in tavola e le mosche possono ancora arrivare alla carne. Consentitemi di spiegare.

Chi può utilizzare xp_CmdShell? Esatto. Solo persone / app che accedono con priv “SA” o persone a cui hai commesso il terribile errore di concedere un proxy possono usarlo.

Prossima domanda. Se xp_CmdShell è disattivato, chi sono le uniche persone che possono riattivarlo? Correggere di nuovo! Solo le persone / app con priv “SA” possono riattivarlo.

Allora, qual è il vero problema con xp_CmdShell che rappresenta un rischio per la sicurezza ? La risposta è xp_CmdShell NON è un rischio per la sicurezza. La scarsa sicurezza è lunico rischio per la sicurezza. Se un hacker o un utente interno malintenzionato entra nel sistema con i privati “SA”, allora possono attivare xp_CmdShell in pochi istanti. Sì, quellazione viene registrata ma fornisce solo una testimonianza documentata che la sicurezza era gravemente carente allinizio.

Disattivare xp_CmdShell non fa nulla per la sicurezza tranne che per fornire una possibilità per quella parte di un codice hacker di riattivarlo per lesecuzione.

Lo ripeto. xp_CmdShell non è un rischio per la sicurezza. Solo una cattiva sicurezza è un rischio per la sicurezza. Correggi la tua sicurezza e quindi attiva xp_CmdShell. È “uno strumento meraviglioso e te lo stai perdendo a causa di cattive pratiche di sicurezza e miti.

Commenti

• Sono completamente daccordo con te, Jeff. Un utente malintenzionato che ha ottenuto i privilegi di syadmin potrebbe creare un lavoro di SQL Agent di proprietà di sa con un jobtep CmdExec e ottenere lo stesso risultato di xp_cmdshell. Potrebbe anche creare una stored procedure CLR che avvia un processo. In che modo sarebbe diverso da xp_cmdshell?Proteggere adeguatamente il server è lunico modo per prevenire i rischi per la sicurezza.
• Ah, il mio vecchio ‘ amico. Grazie per il feedback. Piacere di ” rivederti “.
• +1 ti sbagli, ma mi piace che ti sbagli perché stai incoraggiando le persone a essere meno sicure, il che a sua volta rende linteresse un posto più divertente. Sì Installa SQL Server su tutto e sì la parte extra su come è facile risolvere con la configurazione. Lo adoro < 3. I suoi server SQL 2020 e 9/10 non verranno rafforzati correttamente, ma ovviamente incolpa lamministratore del DB XD
• Heh … I ‘ darò tu lo stesso più uno per aver sbagliato. Vorrei poterti dare un vantaggio per aver sbagliato nel pensare che disabilitare xp_CmdShell fa qualcosa per ” harden ” un server. Semplicemente non ‘ t.

Penso “non dovrebbe essere usato” è probabilmente un buon consiglio. “Non è un” categorico “È” sempre insicuro “, ma piuttosto un riconoscimento che xp_cmdshell è pericoloso e che qualsiasi suo utilizzo è motivo di preoccupazione e di attento esame.

E anche se pensi di sapere come evitare i rischi per la sicurezza, xp_cmdshell probabilmente non è ancora lo strumento migliore da usare. È probabile che esista una soluzione migliore (una che, casualmente, è anche meno rischiosa).

“Con da un grande potere derivano grandi responsabilità “. Detto questo, penso che xp_cmdshell sia uno dei peggiori segnali di sicurezza per arrivare a Redmond.

Modifica: 2020, come penetration tester per oltre 10 anni – xp_cmdshell è ancora uno dei rischi per la sicurezza più terrificanti che ho incontrato perché ha la migliore combinazione di; essendo ampiamente diffuso, utilizzato da aziende importanti come le banche e con il massimo impatto. SQLmap può essere utilizzato per ottenere SA e riabilitare xp_cmdshell … utilizzando solo SQL Injection in una webapp.

Da ingegnere a ingegnere, grazie Microsoft: letteralmente non avrei potuto ottenere queste shell senza di te.

Commenti

• Lo so ‘ è una vecchia domanda, ma devo davvero dirlo: ‘ sono sorpreso che 3 persone abbiano preso sul serio il tuo trolling abbastanza per dare un voto positivo alla tua risposta.
• @spaghettidba Dico sul serio, dato che un pentester xp_cmdshell() è un dio inviato. Ciò che lo rende così grave è che nessuno in Microsoft pensa nemmeno a risolvere questo problema. ‘ sono molto felice di incontrare prodotti e applicazioni Microsoft costruiti sulla piattaforma Microsoft perché sono deboli. Una curiosità, il mio primo 0-day è stato in un prodotto di sicurezza Microsoft quando avevo 16 anni, ovvero più di dieci anni fa.
• @rook – It ‘ Non capita spesso di parlare con un vero tester PEN, quindi ‘ devo cogliere loccasione per chiedere (non sto cercando una rissa … io ‘ sono sinceramente e veramente interessato alla tua buona esperienza), se PUOI ‘ T entrare in qualcuno ‘ goodie locker con SysAdmin privs, sei ancora stato in grado di utilizzare xp_CmdShell come un attaccante anche se ‘ è abilitato? In tal caso, esiste un modo per proteggersi?
• @Jeff Moden. SÌ , quindi sqlmap lo fa abbastanza bene. Anche se non sei SA – a causa dello stacking delle query puoi accedere allaccount SA utilizzando una QUERY SQL – sì, una query sql iniettata può essere utilizzata per ottenere SA e quindi riabilitare qualsiasi comando. Hai ancora bisogno di conoscere la password … ma può essere forzata e se questo attacco non è stato ‘ preso in considerazione, laccount SA potrebbe avere una password debole … e lho visto accadere molte volte, anche alle banche. Non sono un esperto di SQL-Server ma penso che ci sia un rafforzamento che possa prevenire questo attacco … ma non predefinito !!!! SQLMap per la vittoria!

Che tipo di sicurezza viene utilizzato nel tuo ambiente SQL Server, misto o integrato (Windows)? Quanti sono nel ruolo sysadmin di SQL Server? Le best practice di MS richiedono lautenticazione integrata (nessun login sa, nessun login SQL) e solo due nel ruolo sysadmin di SQL Server. Dichiaro che seguire queste best practice attenua notevolmente lesposizione. Inoltre, xp_cmdshell (modalità pre sqlcmd e pre-Powershell) offre la possibilità di copiare i file di registro delle transazioni dal server di produzione al server DR a centinaia di miglia di distanza da un Lavoro di SQL Agent. Nessun male qui, ma come ha scritto un poster, “dipende”.

Per enfatizzare jl01 ” s risposta (a cui ho dato un +1) …

Stranamente, una buona misura di un server SQL adeguatamente protetto e sicuro è avere effettivamente xp_CmdShell abilitato.Quello che voglio dire è che se il tuo sistema è abbastanza sicuro, non dovresti preoccuparti di cose banali come xp_CmdShell che viene abilitato E UTILIZZATO.

Soprattutto a partire da SQL Server 2005, non cè praticamente alcun motivo perché tutti gli utenti diversi dai DBA dovrebbero avere privs maggiori di PUBLIC privs e EXECUTE privs sulle stored procedure in un sistema adeguatamente bloccato. In effetti, implementato correttamente, gli utenti con privati PUBLIC dovrebbero essere in grado di eseguire una stored procedure che contiene chiamate a xp_CmdShell senza essere in grado di eseguire xp_CmdShell direttamente da soli.

Penso che sia ironico che MS abbia creato il proxy della shell di comando per consentire agli utenti a basso numero di utenti di eseguire xp_CmdShell direttamente quando non dovrebbero nemmeno essere in grado di vedere una tabella.