Sécurité de PsExec

accès à aucune des ressources du réseau, même celles auxquelles votre compte pourrait en principe accéder. Si le compte dans lequel on travaille n’a pas de privilèges administratifs locaux sur le système distant, le processus que l’on veut exécuter a besoin d’un accès aux ressources du réseau ou, si l’on veut exécuter un processus dans un compte différent, il faut utiliser le commutateur -u de PsExec pour fournir un nom de compte alternatif. Par exemple, on pourrait entrer la commande

psexec \\remote
-u remote\administrator
-p adminpass ipconfig

pour exécuter Ipconfig sous le compte Administrator sur la machine lointaine. Utilisez le commutateur -p pour entrer le mot de passe pour le compte que vous avez spécifié avec le commutateur –u. Si vous omettez le commutateur –p, PsExec vous invite à entrer le mot de passe (pour des raisons de sécurité, PsExec ne pratique pas l’écho du mot de passe que vous entrez à l’écran).

Si vous indiquez des références alternatives, le processus à distance s’exécute avec ces références et aura accès aux ressources réseau qui sont accessibles au compte alternatif. Pour s’exécuter dans un compte différent, PsExec doit utiliser ce compte pour se connecter au système distant. PsExec a par conséquent besoin du mot de passe sur le système distant et il envoie ce mot de passe en texte clair à partir du système local. Cette réalité a son importance s’il y a un risque d’interception du trafic entre le système local et le système distant.

On peut aussi exécuter le processus distant dans le compte System, sous lequel sont exécutés les services Windows et les processus Windows centraux, comme Winlogon et le LSASS (Local Security Authority Subsystem Service).
Le compte système possède de puissants privilèges.
Certaines ressources du système de fichiers et de registres ont des paramètres de sécurité par défaut qui ne permettent l’accès que depuis le compte système. C’est le cas, par exemple, de la sous-clé de registre HKEY_LOCAL_MACHINE\ SAM et du répertoire \SystemVolume Information, qui est présent sur chaque volume de tous les systèmes Windows 2000 ou ultérieurs.

Ainsi, s’il vous intéresse de connaître le contenu de la sous-clé SAM, qui apparaît vide dans regedit parce que regedit peut faire naviguer la sous-clé uniquement sous le compte système, vous pouvez utiliser PsExec de la même manière que vous utilisez la commande Runas (qui est disponible sur Win2K et ultérieures) pour exécuter regedit sous le compte système. La commande est celle-ci :

psexec –s –i
c:\windows\regedit.exe

A noter que la commande n’inclut pas un nom d’ordinateur distant et inclut le commutateur -i (interactif). Quand vous entrerez la commande, regedit apparaîtra sur votre poste s’exécutant dans le compte système, et vous pourrez examiner le contenu des sous-clés HKEY_LOCAL_MACHINE\ SAM et HKEY_LOCAL_MACHINE\SYSTEM. Le commutateur -i est ce qui fait apparaître regedit sur le poste de console, et il n’est vraiment utile que quand on veut exécuter une application GUI sur le système local pour pouvoir interagir avec elle.

Un dernier commentaire sur la sécurité concerne les virus. En effet, plusieurs virus utilisent PsExec pour se propager dans un réseau. En conséquence, plusieurs antivirus de premier plan étiquètent PsExec comme un programme cheval de Troie ou comme un ver. Rappelons à cet égard que PsExec ne fonctionne sur les systèmes distants que s’il opère dans un compte appartenant au groupe administrateur sur le système distant. Autrement dit, à moins que le compte à partir duquel vous l’exécutez n’ait l’accès administratif sur un système distant, PsExec ne pourra pas exécuter un processus sur celui-ci. En outre, la fonctionnalité de PsExec peut être obtenue par d’autres moyens. Ainsi, PsExec est seulement une commodité pour les auteurs de virus, qui pourraient parfaitement mettre en oeuvre sa fonctionnalité.