xp_cmdshell peut-il être utilisé en toute sécurité dans un processus stocké et y a-t-il des situations pour lesquelles il ny a vraiment pas dautre option? En dautres termes, son utilisation dans un processus stocké devrait-elle toujours être signalée comme un problème de sécurité (comme le conseille un analyseur de code source bien connu)?
En dautres termes, seriez-vous daccord avec la déclaration suivante ( guillemet direct)?
La fonction xp_cmdshell ne peut pas être utilisée en toute sécurité. Il ne doit pas être utilisé.
Commentaires
- Pour les inconnus » xp_cmdshell « , il sagit de » une procédure stockée étendue fournie par Microsoft et stockée dans la base de données principale. Cette procédure vous permet démettre des commandes du système dexploitation directement vers le shell de commande Windows via le code T-SQL. » Yikes !!
- Non, je ne ‘ Je suis daccord. Il peut absolument être utilisé en toute sécurité en utilisant au moins 2 méthodes différentes que je connais et lune dentre elles est très facile à configurer. Le problème est que BOL ne vous dit pas ‘ comment le faire.
Réponse
Cest toujours un risque . Il doit toujours être révisé . Cela peut être correctement atténué .
Il y a des utilisations légitimes, parfois des nécessités, mais surveillez attentivement vos entrées!
Commentaires
- Quen est-il du problème quil ny a aucun moyen de limiter un utilisateur à un groupe dopérations prédéfini et donc, par conséquent, toute octroi de privilèges permet à lutilisateur dexécuter nimporte quelle chaîne de commande, cest-à-dire quil ne le fait pas « >
t autoriser la granularité des privilèges ou déclaré différent tout contrôle devient un contrôle complet?
xp_cmdshell pour exécuter une procédure stockée qui la contient, alors vous ‘ avez définitivement un problème. Je ‘ je suis raisonnablement sûr que ce nest pas nécessaire – la procédure ne doit pas appartenir à lutilisateur régulier. Réponse
Désactiver xp_CmdShell, cest un peu comme mettre un voile sur la viande en décomposition. Cela apporte un faux sentiment de sécurité à la table et les mouches peuvent encore sattaquer à la viande. Permettez-moi de vous expliquer.
Qui peut utiliser xp_CmdShell? Cest vrai. Seules les personnes / applications avec des privilèges « SA » ou les personnes à qui vous avez commis la terrible erreur daccorder un proxy peuvent lutiliser.
Question suivante. Si xp_CmdShell est désactivé, qui sont les seules personnes qui peuvent le réactiver? Corrigez à nouveau! Seules les personnes / applications avec des privilèges « SA » peuvent le réactiver.
Alors, quel est le véritable problème avec xp_CmdShell étant un risque de sécurité ? La réponse est que xp_CmdShell nest PAS un risque pour la sécurité. Une mauvaise sécurité est le seul risque de sécurité. Si un pirate informatique ou un utilisateur interne malveillant pénètre dans le système avec des privilèges « SA », il peut activer xp_CmdShell par moments. Oui, cette action est enregistrée mais cela ne fournit que des preuves documentées que la sécurité manquait cruellement au départ.
Désactiver xp_CmdShell ne fait rien pour la sécurité, sauf pour donner une chance à cette partie du code dun hack de le réactiver pour quil sexécute.
Je le répète. xp_CmdShell nest pas un risque de sécurité. Seule une mauvaise sécurité est un risque pour la sécurité. Corrigez votre sécurité, puis activez xp_CmdShell. Cest un outil formidable et vous le manquez à cause de mauvaises pratiques de sécurité et dun mythe.
Commentaires
- Je suis entièrement daccord avec vous, Jeff. Un attaquant qui obtenait les privilèges syadmin pourrait créer un travail SQL Agent appartenant à sa avec un jobstep CmdExec et obtenir la même chose que xp_cmdshell. Il peut également créer une procédure stockée CLR qui démarre un processus. En quoi cela serait-il différent de xp_cmdshell?Sécuriser correctement le serveur est le seul moyen déviter les risques de sécurité.
- Ah, mon vieux ‘ ami. Merci pour votre retour. Bien à » revoir » vous à nouveau.
- +1 vous vous trompez, mais jaime que vous vous trompiez parce que vous encouragez les gens à être moins en sécurité, ce qui rend lintérêt plus amusant. Oui Installez SQL Server sur tout, et oui, la partie supplémentaire sur la façon dont il est facile de résoudre avec la configuration. Jadore < 3. Ses serveurs SQL 2020 et 9/10 ne seront pas durcis correctement – mais bien sûr blâmer ladministrateur DB XD
- Heh … Je ‘ je vais donner vous le même plus un pour avoir tort. Jaimerais pouvoir vous donner un avantage pour avoir tort de penser que la désactivation de xp_CmdShell fait nimporte quoi pour » durcir » un serveur. Cela ne fait que ‘ t.
Réponse
Je pense « il ne devrait pas être utilisé » est probablement un très bon conseil. Ce nest pas un « Ce » nest toujours pas sûr « , mais plutôt une reconnaissance du fait que xp_cmdshell est dangereux et que toute utilisation de celui-ci est un motif de préoccupation et dexamen minutieux.
Et même si vous pensez savoir comment éviter les risques de sécurité, xp_cmdshell nest probablement pas le meilleur outil à utiliser. Il y a de fortes chances quil y ait une meilleure solution (une qui aussi, par hasard, est moins risquée).
Réponse
« Avec une grande puissance saccompagne dune grande responsabilité. » Cela étant dit, je pense que xp_cmdshell est lun des pires trains de sécurité pour sortir de Redmond.
Edit: 2020, en tant que testeur dintrusion depuis plus de 10 ans – xp_cmdshell reste lun des risques de sécurité les plus terrifiants que jai rencontrés car il a la meilleure combinaison de; étant largement répandu, utilisé par des entreprises importantes comme les banques, et impact maximal. SQLmap peut être utilisé pour obtenir SA et réactiver xp_cmdshell … en utilisant uniquement linjection SQL dans une application Web.
Dun ingénieur à lautre, merci Microsoft – Je naurais littéralement pas pu obtenir ces coquilles sans vous.
Commentaires
- Je sais que ‘ est une vieille question, mais je dois vraiment le dire: jai ‘ surpris que 3 personnes ont pris votre pêche à la traîne au sérieux assez pour augmenter votre réponse.
- @spaghettidba Je suis très sérieux, car un pentester
xp_cmdshell()est un don de Dieu. Ce qui le rend si grave, cest que personne chez Microsoft ne pense même à résoudre ce problème. Je ‘ suis très heureux de découvrir les produits et applications Microsoft basés sur la plate-forme Microsoft car ils sont faibles. Fait amusant, mon premier 0 jour était dans un produit de sécurité Microsoft quand javais 16 ans, soit il y a plus dune décennie. - @rook – It ‘ Je nai pas souvent loccasion de parler à un vrai testeur PEN, alors je ‘ dois profiter de cette occasion pour demander (je ne cherche pas de bagarre … Je ‘ m honnêtement et vraiment intéressé par votre bonne expérience), si vous POUVEZ ‘ T entrer dans quelquun ‘ s goodie locker avec SysAdmin privs, avez-vous toujours pu utiliser xp_CmdShell comme attaquant même si ‘ est activé? Si oui, y a-t-il un moyen de sen protéger?
- @Jeff Moden. OUI , donc sqlmap le fait très bien. Même si vous nêtes pas SA – en raison de lempilement de requêtes, vous pouvez vous connecter au compte SA en utilisant une requête SQL – oui, une requête SQL injectée peut être utilisée pour obtenir SA, puis réactiver nimporte quelle commande. Vous devez toujours connaître le mot de passe … mais il peut être forcé brutalement et si cette attaque na pas été ‘ prise en compte, le compte SA pourrait avoir un mot de passe faible … et jai vu cela se produire plusieurs fois, même dans les banques. Pas un expert SQL-Server mais je pense quil y a un durcissement qui peut empêcher cette attaque … mais pas par défaut !!!! SQLMap pour la victoire!
Réponse
Quel type de sécurité est utilisé dans votre environnement SQL Server, mixte ou intégré (Windows)? Combien sont dans le rôle sysadmin SQL Server? Les meilleures pratiques MS appellent à lauthentification intégrée (pas de connexion sa, pas de connexion SQL) et seulement deux dans le rôle sysadmin SQL Server. Je soumets que le fait de suivre ces meilleures pratiques atténue considérablement son exposition. De plus, xp_cmdshell (mode pré-sqlcmd et pré-Powershell) donne la possibilité de copier les fichiers journaux des transactions du serveur de production vers le serveur DR à des centaines de kilomètres de Travail dagent SQL. Pas de mal ici mais comme la dit laffiche, « ça dépend ».
Réponse
Pour souligner jl01 » Réponse de s (à laquelle jai donné un +1) …
Curieusement, une bonne mesure dun SQL Server correctement sécurisé et sûr est davoir en fait xp_CmdShell activé.Ce que je veux dire par là, cest que si votre système est suffisamment sécurisé, vous ne devriez pas avoir à vous soucier de questions triviales telles que xp_CmdShell étant activé ET UTILISÉ.
Surtout à partir de SQL Server 2005, il ny a pratiquement aucune raison pourquoi tous les utilisateurs autres que les DBA devraient avoir des privs supérieurs aux privs PUBLIC et EXECUTE privs sur les procédures stockées dans un système correctement verrouillé. En fait, mis en œuvre correctement, les utilisateurs avec des privilèges PUBLIC devraient être en mesure dexécuter une procédure stockée qui contient des appels à xp_CmdShell sans pouvoir exécuter xp_CmdShell directement eux-mêmes.
Je trouve ironique que MS ait créé le proxy shell de commande pour permettre aux utilisateurs peu privés dexécuter directement xp_CmdShell lorsquils ne devraient même pas voir une table.