Windows PowerShellContrer le code malveillant

Don Jones

Rappelez-vous, lorsque Windows Vista était toujours à la version bêta et que tout le monde parlait d'une toute première version d'un nouvel interpréteur de ligne de commande, nom de code « Monad » ?(Ce nouvel interpréteur s'appellerait bien sûr finalement Windows PowerShell).À l'époque, un grand nombre de rapport issus des médias traditionnels faisaient état du « premier virus de Windows Vista ».En

réalité, le « virus » était juste un script de logiciel malveillant de validation technique qui ciblait « Monad ».Afin d'exécuter le script, « Monad » lui-même aurait été dû être spécialement configuré. En effet, le script ne fonctionnait pas sous les paramètres par défaut.De plus, au moment où ces rapports sont apparus, Microsoft avait déjà annoncé que « Monad » ne serait pas fourni avec Windows Vista®.En bref, toute cette situation avait fait beaucoup de bruit pour rien (ou, du moins, pour très peu).

Á mesure que Windows PowerShellTM gagne en popularité (il a été déjà téléchargé plus d'un million de fois), le risque que quelqu'un l'utilise pour créer un script malveillant augmente.La possibilité d'écrire un script potentiellement dangereux dans Windows PowerShell est un fait. Tout outil d’administration, y compris Windows PowerShell, cmd.exe et VBScript, peut être utilisé de façon malveillante.Vous ne pouvez par conséquent pas simplement supposer qu'un fichier PS1 donné est inoffensif.

Heureusement, Windows PowerShell est configuré par défaut pour n'exécuter aucun script, si bien qu'un script malveillant nécessite votre aide pour s'exécuter.Ce mois-ci, j'aimerais prédire comment cela arrivera probablement.Je ne cherche surtout pas à présenter Windows PowerShell sous un mauvais jour ; en réalité je pense que Microsoft a conçu un interpréteur de script qui évite de nombreux risques.Mais cette discussion mérite d'avoir lieu, simplement pour vous aider à vous préparer à contrer cette attaque potentielle.

Sécurisation par défaut

Il est important de noter que Windows PowerShell a été le premier langage conçu par Microsoft après la célèbre initiative Trustworthy Computing.Le grand manitou de la sécurité Michael Howard (l'auteur du livre Écrire du code sécurisé) était « le spécialiste de la sécurité » de l'équipe de Windows PowerShell.Il a aidé à s'assurer que le code était écrit pour être aussi sécurisé que possible et, plus important encore, que l'interpréteur était configuré de façon aussi sécurisée que possible dès l'installation.

Tout d'abord, examinons rapidement les paramètres de sécurité initiaux de Windows PowerShell.Par défaut, l'interpréteur n'exécutera pas les fichiers avec une extension de nom de fichier PS1 si vous double-cliquez sur ceux-ci.Cette extension est associée au Bloc-notes.Par défaut, l'interpréteur n'exécutera aucun script grâce à une fonctionnalité intégrée appelée stratégie d'exécution, qui décrit les conditions dans lesquelles un script s'exécutera.Il est défini sur Restricted dès l'installation, ce qui interdit l'exécution de tous les scripts et active l'interpréteur uniquement pour un usage interactif.La stratégie d'exécution peut être modifiée à l'aide de l'applet de commande Set-ExecutionPolicy, ou via un modèle d'administration de stratégie de groupe (fichier ADM) fourni par Microsoft.(Vous pouvez obtenir le fichier ADM à l'adresse go.microsoft.com/fwlink/?LinkId=102940.)La figure 1 illustre les stratégies d'exécution que vous pouvez définir.

Figure 1** Choix d'une stratégie d'exécution sécurisée **(Cliquer sur l'image pour l'agrandir)

La stratégie d'exécution comporte seulement quelques exceptions.En particulier, même lorsqu'elle est définie sur Restricted, la stratégie autorisera l'interpréteur à importer quelques fichiers de configuration XML particuliers fournis par Microsoft et installés avec l'interpréteur.Ces fichiers sont utilisés pour fournir des fonctionnalités spécifiques, telles que les extensions des types Microsoft® .NET Framework et les dispositions de format par défaut pour la plupart des types d'objet .NET.Il est par conséquent nécessaire que l'interpréteur charge ces fichiers au démarrage.

Bien que ces fichiers puissent contenir du code exécutable, et c'est d'ailleurs le cas, ils ont été signés numériquement par Microsoft.Une altération quelconque de ceux-ci rend la signature inutilisable et, si cela se produit, l'interpréteur n'importera pas les fichiers au démarrage.Cette conception améliore la sécurité des fichiers contre les logiciels malveillants qui pourraient essayer d'y insérer du code malveillant.

Bien sûr, si elle est définie sur Restricted, la stratégie d'exécution empêchera également vos propres scripts de profil de Windows PowerShell de s'exécuter au démarrage.Windows PowerShell ne crée pas un script de profil par défaut, mais il recherche quatre emplacements spécifiques pour les noms de fichier spécifiques et, s'il les trouve, tente de les exécuter chaque fois que l'interpréteur démarre.(La documentation installée avec Windows PowerShell fournit des détails sur les noms de dossier et de fichier utilisés pour les scripts de profil).Le profil est la clé de la faille que je vais m'attacher à décrire.

Modification de la stratégie d'exécution

Applet de commande du mois

Le compagnon de Set-AuthenticodeSignature est Get-AuthenticodeSignature.Cette applet de commande est conçue pour examiner un script signé numériquement et vous donne des informations sur la signature.Il suffit de le pointer sur le fichier en question pour voir non seulement si un fichier a été signé mais si la signature est intacte, quel certificat a été utilisé pour signer le fichier, et ainsi de suite.En plus de fonctionner avec les scripts Windows PowerShell, cette applet de commande fonctionne également avec des exécutables signés, comme ceci :

PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *

En exécutant cette commande, je constate que l'exécutable a été signé par Microsoft Corp. à l'aide d'un certificat émis par l'autorité de certification pour la signature de code de Microsoft.

Résultats de la commande  (Cliquer sur l'image pour l'agrandir)

Je dois souligner que dans les conditions par défaut, il est très difficile, voire impossible, d'obtenir que Windows PowerShell exécute du code, sans parler de code malveillant.Les scripts malveillants ne deviennent possibles que si vous modifiez la stratégie d'exécution.Je tiens à préciser que cet article n'est pas une sonnette d'alarme sur les failles de sécurité dans Windows PowerShell, mais est destiné à partager certaines pratiques recommandées pour renforcer vos systèmes.

La stratégie d'exécution la plus basse est Unrestricted, qui permet d'exécuter tous les scripts sans restriction, en offrant essentiellement le même scénario indésirable que vous avez eu avec VBScript et les fichiers de commandes pendant des années.Si vous définissez l'interpréteur sur Unrestricted, vous invitez tout simplement les scripts malveillants à pénétrer dans votre système et à l'endommager.Si vous choisissez le paramètre Unrestricted et qu'un script apparaît et s'impose, assurez-vous que vous pouvez justifier votre choix du paramètre Unrestricted, et soyez prêt à assumer votre décision lorsque vous expliquerez comment un virus a effacé votre environnement !

Pour être honnête, Windows PowerShell essaiera toujours de détecter les scripts téléchargés à partir d'Internet et vous avertira avant de les exécuter, même lorsqu'il est défini sur Unrestricted.Mais le fait est qu'il est fortement déconseillé de définir la stratégie d'exécution sur Unrestricted.

Signature des scripts

La stratégie d'exécution la plus sécurisée pour exécuter les scripts est Allsigned.Ce paramètre, comme son nom le suggère, exécute uniquement des scripts qui portent une signature numérique intacte créée à l'aide d'un certificat approuvé (pas n'importe quelle vieille signature).La signature des scripts nécessite d'acquérir un certificat numérique de Classe III, plus précisément, un certificat de signature de code Authenticode de Microsoft.Ces certificats peuvent être obtenus auprès de l'infrastructure de clé publique (PKI) interne de votre entreprise, si vous en possédez une, ou si vous en avez acheté une auprès des autorités de certification commerciales (CA), telles que CyberTrust, Thawte et VeriSign.

Si vous souhaitez savoir si des certificats sont installés sur votre machine et peuvent être utilisés pour signer des scripts, l'applet de commande suivante vous l'indiquera :

Get-ChildItem CERT: -recurse –codeSigningCert

Après avoir installé le certificat sur votre ordinateur Windows® vous devez utiliser l'applet de commande Set-AuthenticodeSignature pour créer et appliquer une signature numérique, qui s'affiche sous la forme d'une série de lignes de commentaire ressemblant à du charabia à la fin du script.Certains éditeurs de scripts peuvent offrir la possibilité d'appliquer une signature à un fichier de script, notamment la possibilité de signer automatiquement les scripts lorsque vous les enregistrez, ce qui peut être commode.

AllSigned est la meilleure stratégie d'exécution à utiliser dans un environnement de production.Bien qu'il n'empêche pas de scripts malveillants, il s'assure qu'un script malveillant est signé et, donc, vous pourriez dépister l'auteur du script (en supposant que vos ordinateurs Windows sont configurés pour approuver uniquement les autorités de certification dignes de confiance, mais ce sujet n'entre pas dans le cadre de cet article).Il est intéressant de noter que Windows Script Host (WSH) 5.6 et versions ultérieures peut être configuré avec un paramètre TrustPolicy similaire qui nécessite également des signatures numériques, mais j'ai rencontré peu d'administrateurs qui utilisent ce paramètre.

Voici donc un récapitulatif rapide jusqu'à présent.Avec une stratégie d'exécution définie sur Restricted, vous êtes protégé contre les scripts malveillants, mais vous ne pouvez pas non plus exécuter les scripts utiles.Lorsque votre stratégie d'exécution est configurée sur AllSigned, l'interpréteur autorise les scripts signés, ce qui est assez fiable puisque peu d'auteurs de scripts malveillants veulent qu'une identité vérifiée et traçable soit appliquée à leur travail.Le paramètre Unrestricted, en revanche, est extrêmement dangereux et si vous l'utilisez, vous pouvez vous attendre à recevoir des scripts malveillants.(Notez que je ne considère pas le paramètre Unrestricted comme une vulnérabilité particulière parce qu'il ne prétend pas être autre chose qu'un paramètre non fiable et si vous l'utilisez, vous savez vraisemblablement pourquoi vous l'avez choisi).

Entrée furtive par une porte dérobée

Il existe un autre paramètre de stratégie d'exécution :RemoteSigned.Je pense que c'est celui que la plupart des administrateurs utilisent actuellement, simplement parce qu'il est perçu comme plus fiable que Unrestricted et moins embêtant que AllSigned.RemoteSigned ne nécessite pas de signature pour les scripts locaux.Les fichiers PS résidant sur vos lecteurs locaux s'exécuteront sans signature.Les scripts distants, principalement ceux qui sont téléchargés à partir d'Internet à l'aide d'Internet Explorer® ou d'Outlook® (ces applications marquent les fichiers téléchargés avec un indicateur spécial), ne s'exécuteront pas sans signature.

Le paramètre RemoteSigned peut cependant vous donner un faux sentiment de sécurité.Pour commencer, il est facile de télécharger des scripts distants sans qu'un indicateur spécial soit appliqué.Les navigateurs non-Microsoft, par exemple, ainsi que la plupart des clients de messagerie électronique non-Microsoft ne définissent généralement pas cet indicateur.Il est important de noter que sans cet indicateur, Windows PowerShell traite les scripts téléchargés comme des scripts locaux, ce qui signifie qu'une signature ne sera pas requise.Pourtant, je ne considère pas cela comme une vulnérabilité importante.Vous devez télécharger le script, ouvrir Windows PowerShell et exécuter le script manuellement pour qu'il s'exécute.C'est un peu difficile de persuader quelqu'un d'exécuter toutes ces étapes, et les administrateurs, généralement les seuls utilisateurs sur un réseau qui disposent de Windows PowerShell, doivent le savoir.

Cependant, RemoteSigned, offre une « porte dérobée » par laquelle les logiciels malveillants peuvent s'introduire.Vous souvenez-vous de ces scripts de profil Windows PowerShell ?S'ils existent, qu'ils aient été créés par vous ou par un logiciel malveillant, ils s'exécuteront à chaque fois que Windows PowerShell s'exécutera.Sous la stratégie d'exécution RemoteSigned, vos scripts de profil, qui sont locaux, n'ont pas besoin d'être signés.

Voici le scénario :

1. Un logiciel malveillant s'introduit dans votre système et crée un script de profil d'interpréteur ou insère un code malveillant dans un script de profil existant.Les logiciels malveillants s'exécutent généralement sous votre compte d'utilisateur connecté, qui a généralement l'autorisation de modifier votre script de profil.
2. Vous ouvrez Windows PowerShell, sans vous rendre compte que votre script de profil a été créé ou modifié pour inclure un code malveillant.Le code s'exécute et le mal est fait.Les dommages sont pires si vous avez l'habitude d'ouvrir Windows PowerShell avec les informations d'identification de l'administrateur, une pratique courante dans la mesure où lorsque vous utilisez l'interpréteur, vous avez besoin des privilèges d'administrateur pour exécuter toutes les tâches pour lesquelles vous utilisez l'interpréteur.

Le profil offre alors un moyen d'exécuter du code arbitraire et malveillant, à votre insu, et la stratégie d'exécution RemoteSigned permet cela.

Protection du profil

Il existe une seule manière correcte de protéger votre profil :utiliser la stratégie d'exécution AllSigned.Sous AllSigned, même vos scripts de profil doivent être signés numériquement, sinon Windows PowerShell ne les exécutera pas au démarrage.Et si vous avez signé vos scripts de profil, les modifications malveillantes de ceux-ci altéreront leurs signatures numériques, en les rendant incapables de s'exécuter. En effet, Windows PowerShell vous alertera du problème au démarrage.AllSigned est vraiment le seul paramètre de stratégie d'exécution fiable pour les environnements de production qui doivent autoriser des scripts pour s'exécuter.

Il existe une autre approche, mais elle est plus compliquée et moins fiable.Vous pouvez créer des fichiers de script de profil vierges pour chacun des quatre fichiers recherchés par Windows PowerShell.Utilisez un nouveau compte utilisateur (je l'appellerai « Éditeur de profils ») pour créer ces fichiers et définir les autorisations NTFS des fichiers afin que seul le compte d'Éditeur de profil puisse les modifier.Les autres comptes peuvent disposer de l'accès en lecture seule.

Maintenant, ne vous connectez jamais à votre ordinateur en utilisant le compte Éditeur de profils sauf pour modifier votre profil.Avec cette approche, votre compte utilisateur normal (ou vos comptes) ne pourra pas modifier vos scripts de profil.Et tout logiciel malveillant qui s'exécute lorsque vous êtes connecté avec un compte normal ne pourra pas non plus modifier les scripts.Que se passe-t-il si le logiciel malveillant arrive à s'exécuter pendant que vous êtes connecté en tant qu'Éditeur de profils ?A priori, dans la mesure où vous êtes connecté en tant qu'Éditeur de profils pour modifier vos scripts de profil, vous devriez remarquer les modifications.

Vous pouvez aussi créer votre propre filet de sécurité, en créant un script de profil unique pour tous utilisateurs qui est contrôlé avec des autorisations de fichier strictes, comme je viens de décrire.Dans ce script, écrivez un code qui utilise l'applet de commande Get-AuthenticodeSignature pour examiner les signatures numériques sur les autre profils recherchés par l'interpréteur.Cela vous permet essentiellement de demander des signatures pour les scripts de profil, sans en demander pour les autres scripts.

La stratégie d'exécution AllSigned est toutefois une façon beaucoup plus efficace de protéger votre profil.Ma recommandation est que tout ordinateur connecté à votre réseau doit avoir la stratégie d'exécution Restricted, de préférence appliquée par la stratégie de groupe.Cela remplace tous les paramètres locaux et garantit que les nouveaux ordinateurs du domaine sont automatiquement configurés pour rejeter les scripts.Les ordinateurs sur lesquels les scripts sont autorisés doivent avoir une autre stratégie de groupe qui détermine la stratégie d'exécution AllSigned.Vous devez signer numériquement tous les scripts, mais vous pouvez dormir sur vos deux oreilles sachant que seuls les scripts de confiance des auteurs identifiables s'exécutent dans votre environnement.

Don Jones est le gourou des scripts chez SAPIEN Technologies et co-auteur de Windows PowerShell:TFM (SAPIEN Press, 2007).Vous pouvez le contacter sur le site www.ScriptingAnswers.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.