Utilisation de xp_cmdshell avec SQL Server

Xp_cmdshell comme toutes les procédures en xp_ sont des procédures stockées écrites avec la bibliothèque ODS API en C ou C++, elles sont donc livrées sous la forme de DLL et sont enregistrées au niveau du serveur sous la forme de procédures stockées (connues sous le nom de procédures stockées étendues).

Il est possible de développer ses propres procédures stockées étendues mais cela n'est pas conseillé, d'autant que .net est intégré avec SQL Server 2005 et vous permet beaucoup plus facilement de développer des fonctions équivalentes.

Xp_cmdshell, est une procédure très simple, elle vous permet en effet d'exécuter n'importe quelle script en ligne de commande (type commande DOS) sur votre server. C'est aussi pour cette raison que celle-ci peut se révéler très dangereuse pour votre système si vous n'y prenez pas garde.

Un exemple de syntaxe :

EXEC xp_cmdshell 'DIR c:\*.*'

Remarquez que pour cet exemple j'aurais pu utiliser une autre procédure stockée étendue : xp_dirtree (EXEC master..xp_dirtree 'C:\*.*')

Pour exécuter xp_cmdshell vous devez faire parti du rôle serveur « sysadmin » (dont « sa » fait parti), cette règle est généralement valable pour toutes les procédures stockées étendues du serveur. La ligne de commande passée en argument de xp_cmdshell s'exécute dans le contexte du compte de service su serveur SQL (c'est-à-dire que si le service SQL (MSSQLSVR) est paramétré avec le compte MONDOMAINE\MONUTILISATEUR, c'est cet utilisateur qui exécutera le code passé en argument).

Petit rappel des comptes de services disponibles pour exécuter le service SQL Serveur :

• LocalSystem
  • C'est en général l'option choisie, elle permet d'être « administrateur » local de la machine, en fait le service peut se faire passer pour le système, les droits sont locaux uniquement, ce compte n'a pas de réel contexte utilisateur, en cas d'accès réseau c'est une session null qui est ouverte (en général refusée sur les autres machines)
  • Avec ce genre de droits n'oubliez pas qu'une personne mal intentionnée pourrait carrément rebooter votre serveur si elle avait accès au xp_cmdshell.
• LocalService (nouveauté Windows 2003)
  • Les droits sont ceux d?un utilisateur simple local, les droits sont locaux uniquement, en cas d'accès réseau c'est une session null qui est ouverte (en général refusée sur les autres machines).
  • A noter que c'est le processus d'installation qui accorde des droits supplémentaires nécessaire à SQL Server.
• NetworkService (nouveauté Windows 2003)
  • Identique au précédent sauf que l'accès réseau ce fait avec le compte de la machine, quand vous tentez de vous connecter à une autre machine celle-ci doit autoriser votre serveur à se connecter (par exemple, votre serveur SQLSERV doit être explicitement autorisé à écrire sur le partage \\MESFICHIERS\SAV). Ce mode est assez pratique en cas de machine non reliées à un domaine, mais nécessitant des accès antre elles.
  • Même remarque que ci-dessus. Quand vous êtes sur le même serveur c'est NetworkService à qui il faut accorder les droits, cependant en utilisation réseau c'est le compte du serveur (nom de la machine) qu'il faut autoriser.
• Utilisateur Local (NomServeur\Utilisateur)
  • Presque équivalente à LocalService, cependant votre serveur pourra se connecter à une machine ayant un couple utilisateur/motdepasse similaire à votre compte local.
• Utilisateur du Domaine (NomDomaine\Utilisateur)
  • Option la plus courante lorsque vous êtes relié à un domaine, permet plus de facilité au niveau de la gestion des droits entre les serveurs.
  • Evitez de donner trop de droit à un compte du domaine, un compte de service peut très bien être invité du domaine, sans pour autant compromettre le fonctionnement du service SQL

Lorsque que vous changer le compte de services de l?agent SQL ou du moteur SQL, faites le toujours par « SQL Server configuration Manager », celui-ci accordant les droits nécessaire à l'exécution des services.

Dans le cas de l'utilisation d'un compte de service local ou de domaine et de l'utilisation des connexions TCP/IP pensez au paramétrage du SPN, voir ici : http://support.microsoft.com/kb/319723/ (étape 3)

A ce point il est à noter 2 choses, seul un nombre restreint d'utilisateurs (ou en tout cas c'est à vous de ne pas accorder des droits de sysadmin à chacun) ont accès aux xps (procédures stockées étendues), et les droits accordé pour l'exécution de celles-ci sont fonction des droits données au service SQL (à l?installation, mais peut être changé à tout moment) en général des droits élevés.

Sur SQL Server 2005 quelques points ont changé, vous avez peut être remarqué, que par défaut (pour une installation sans mise à jour de SQL Server 2005) que xp_cmdshell n'est pas/plus accessible.

Msg 15281, Level 16, State 1, Procedure xp_cmdshell, Line 1

SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'xp_cmdshell' by using sp_configure. For more information about enabling 'xp_cmdshell', see "Surface Area Configuration" in SQL Server Books Online.

En fait dans une volonté de sécurité l'équipe de développement de SQL Server a désactivé par défaut cette procédure stockée, qui par la même est source de beaucoup de problèmes de sécurité. Si vous souhaitez réactiver xp_cmdshell procédez comme suit en script SQL ou passez par l'outil « SQL Server Surface Area Configuration » :

-- Autorise les options avancées à être changées

EXEC sp_configure 'show advanced options' , 1

GO

-- Prend en compte la modification faite

RECONFIGURE

GO

-- Active la procedure stockée xp_cmdshell au niveau du serveur

EXEC sp_configure 'xp_cmdshell' , 1

GO

-- Prend en compte la modification faite

RECONFIGURE

GO

A partir d'ici vous êtes conscient que le fait de réactiver cette procédure vous expose à des risques de sécurité important, si vous n'avez pas sécurisé l'ensemble des comptes de connexion au serveur.

Maintenant que vous pouvez utiliser correctement xp_cmdshell nous allons voir comment, l?utiliser sous SQL Server 2005 avec des comptes non sysadmin. SQL Server 2005 introduit en effet la notion de proxy et de credential.

Le credential est en fait, en général, un compte Windows qui ici nous servira de compte de substitution, car seuls les membres du rôle sysadmin du serveur peuvent utiliser le compte du service SQL. Pour créer un credential allez tout d'abord dans votre domaine ou sur votre poste local et créez-y un compte utilisateur (par exemple Employe1 sur le domaine Intranet), notez le mot de passe et indiquez que celui-ci ne changera pas ou ne sera pas modifié lors de la prochaine connexion (Veuillez à nouveau choisir un compte avec un accès très restreint pour des questions de sécurité). L'étape suivante consiste à indiquer à SQL Server quel est le compte à utiliser lorsqu'un utilisateur non membre du rôle sysadmin veut exécuter xp_cmdshell :

-- Création d'un credential rattaché à un compte Windows

EXEC sp_xp_cmdshell_proxy_account 'INTRANET\Employe','monmot de passe'

Le credential suivant est créée : ##xp_cmdshell_proxy_account##.

-- Suppression du credential

EXEC sp_xp_cmdshell_proxy_account NULL

Remarquez que la commande habituelle pour la création d'un credential est celle-ci

-- Création d'un credential rattaché à un compte Windows

CREATE CREDENTIAL mon_cred WITHIDENTITY='INTRANET\Employe1'

, SECRET ='monmot de passe'

Mais la deuxième syntaxe ne sert que pour l?agent SQL ou pour associer à credential à un compte de connexion au serveur. La liste complète de ceux-ci est disponible soit par SQL Server Management Studio dans « Security » / « Credentials » ou via la vue système sys.credentials.

Dernière étape, car si vous avez déjà essayé l?exécution de la procédure vous avez reçu une erreur. Il faut associer votre compte de connexion (login) à un utilisateur (user) dans la base de données master :

USE master

GO

-- Création d'un compte dans la base de données master

CREATE USER monutilisateur FROMLOGIN maconnexion

-- Attribution des droits pour executer xp_cmdshell

GRANT EXEC ON xp_cmdshell TO monutilisateur

Et enfin nous donnons les droits d?exécution, et vous pouvez enfin utiliser xp_cmdshell pour tous vos utilisateurs.

Il existe une autre possibilité avec la clause EXECUTE AS nouvelle aussi dans le moteur SQL Server 2005 pour donner temporairement des droits plus élevés à un utilisateur dans la cadre d?une procédure ou un code SQL.

-- Attribution des droits

USE master;

GRANT IMPERSONATE ONLOGIN::maconnexion to [maconnexioncourant];

GO

-- On désactive ce compte pour que personne ne puisse se connecter avec sur le serveur

-- Ceci est une précaution, mais n'empeche pas de ce servir du compte plus bas.

ALTER LOGIN maconnexion DISABLE

-- Se fait passer temprairement pour maconnexion

-- On suppose que maconnexion a des droits suffisant (tel que sysadmin)

EXECUTE AS LOGIN 'maconnexion'

-- xp_cmdshell

EXEC xp_cmdshell 'dir c:\'

-- Remet tout en état

REVERT

Voilà, le tour est fait sur xp_cmdshell comme vous pouvez le voir SQL Server 2005 apporte pas mal de nouveautés.

Source: http://www.technos-sources.com/tutorial-utilisation-xp_cmdshell-avec-sql-server-13.aspx

Other links:
http://msdn.microsoft.com/fr-fr/library/ms175046.aspx

Enabling xp_cmdshell in SQL Server 2005

http://www.databasejournal.com/features/mssql/article.php/3372131/Using-xpcmdshell.htm

http://msdn.microsoft.com/fr-fr/library/ms190693.aspx