Windows PowerShellSignez ici, s'il vous plaît

Don Jones

Dans l'article Windows PowerShell de janvier 2008, j'ai insisté sur l'importance de la signature de vos scripts Windows PowerShell. J'ai également décrit certains scénarios dans lesquels une stratégie d'exécution différente de AllSigned pourrait créer des failles de sécurité significatives dans votre environnement.

Je n'ai par contre pas décrit avec beaucoup de détails comment signer vos scripts. Vous pouvez consulter cette chronique à l'adresse technetmagazine.com/issues/2008/01/PowerShell. Devinez ce que je vais aborder ce mois-ci ?

Plus qu'une simple signature

Le mot signature est le terme technique correct pour ce dont je vais parler, bien qu'il ne constitue pas en soi une bonne description de ce qui se produit ici. Signer un script ne signifie pas que vous l'approuvez ou l'autorisez, comme cela serait le cas avec un contrat ou un bordereau de carte de crédit. Dans le monde de la sécurité numérique, la signature est le processus d'apposition de votre identité à un élément et de vérification que l'état de cet élément n'a en aucun cas été modifié. Tout ceci est basé sur la cryptographie, et la cryptographie (tout du moins dans ce cas précis) commence par une paire de clés de chiffrement.

Ces clés sont appelées clés asymétriques car elles sont différentes l'une de l'autre. Ce couple est composé d'une clé privée, à laquelle vous seul pouvez accéder, et d'une clé publique, à laquelle tout le monde peut accéder. Je simplifie quelque peu ceci mais, fondamentalement, tout ce qui a été chiffré avec la clé privée peut uniquement être déchiffré avec la clé publique correspondante.

Voici comment cela fonctionne. Ici encore, j'utilise une simplification pour poursuivre cette discussion. Je possède un script Windows PowerShell® que je souhaite signer et un certificat contenant la clé privée que je souhaite utiliser pour signer le script. Windows Powershell possède une applet de commande, dont je parlerai dans un instant, pouvant utiliser le script et le certificat pour effectuer la signature. Lors de cette opération, Windows PowerShell prend le script et le chiffre à l'aide de ma clé privée. La copie chiffrée apparaît sous forme de texte brouillé ajouté au bas du script en tant que série de commentaires (voir la figure 1). Mon identité est également codée, mais non chiffrée, dans ces commentaires. Cette identité peut même être lue sans recourir à la cryptographie.

Figure 1** Bloc de signature enregistré au bas de votre script **(Cliquer sur l'image pour l'agrandir)

Plus tard, lorsque Windows PowerShell examine la signature, il décode mon identité et l'utilise pour obtenir ma clé publique. Comme seule ma clé publique peut déchiffrer le reste de la signature, Windows PowerShell sait que s'il est capable de déchiffrer la signature, c'est que c'est moi qui l'ai signée. Si quelqu'un d'autre l'avait signée, ma clé publique ne pourrait pas déchiffrer la signature. Une fois la signature déchiffrée, Windows PowerShell compare le script à la copie qui avait été chiffrée dans la signature. Si elles correspondent, la signature est alors considérée comme intacte. Si les deux scripts diffèrent, la signature est rompue et considérée comme non valide.

Voici comment une signature protège un script en texte brut contre les modifications sans que cela soit visible. N'oubliez pas que bien que le script puisse lui-même être facilement modifié, la signature ne peut pas être modifiée pour correspondre au script modifié sans utiliser ma clé privée, et je suis seul propriétaire de ma clé privée.

Il s'agit définitivement d'une simplification du processus technique sous-jacent. En réalité, les signatures peuvent et doivent contenir davantage d'informations, notamment une copie de ma clé publique, des informations sur l'autorité de certification (CA) qui a émis les clés, etc. Mais ma description illustre certainement les parties importantes du processus et souligne le fait qu'une signature protège en fait votre script des modifications non autorisées.

La protection absolue de votre clé privée est un facteur essentiel de la sécurité de votre clé privée. Il est souhaitable qu'elle ne tombe pas entre les mains de personnes non autorisées. Lorsque vous installez votre clé dans Windows, vous devez immédiatement la protéger par mot de passe afin qu'aucun processus malveillant ne puisse utiliser votre clé à votre insu. Les cartes à puce fournissent une sécurité encore plus grande puisqu'elles contiennent votre clé privée. Avec une carte à puce, votre clé privée ne quitte jamais la carte. Au lieu de cela, les données que vous voulez chiffrer sont transmises à la carte par son matériel de lecture et les circuits de la carte exécutent le chiffrement et renvoient le résultat.

Obtenir un certificat

Applet de commande du mois Export-CSV

Les participants aux forums de PowerShellCommunity.org demandent souvent si Windows PowerShell peut exporter vers Microsoft Excel®. Bien sûr ! L'applet de commande Export-CSV suffit, puisque Excel peut ouvrir, modifier et enregistrer les fichiers CSV en mode natif. Par exemple, si vous voulez exporter une liste de services, exécutez simplement Get-Service | Export-CSV MyServices.csv. En fait, vous pouvez ajouter Export-CSV à la fin de tout pipeline pour que tous les objets de ce pipeline figurent dans le fichier CSV que vous spécifiez. Par défaut, Export-CSV ajoute une ligne d'en-tête au sommet du fichier, qu'il utilise pour spécifier le type d'objet exporté. Cette ligne est mise en commentaire et n'empêchera donc pas Excel d'ouvrir le fichier. Si vous ne voulez pas que ce type d'information soit exporté, vous pouvez ajouter le paramètre -notype à Export-CSV. De plus, vous pouvez ajouter le paramètre -force pour forcer le remplacement d'un fichier CSV existant du même nom sans avertissement (un avertissement est par défaut affiché), ou encore ajouter le paramètre -noClobber pour empêcher le remplacement d'un fichier existant.

Pour signer des scripts, vous aurez besoin d'un type de certificat spécifique, à savoir un certificat de signature de code Authenticode Class III, et il existe trois manières de l'obtenir. La première consiste à utiliser l'infrastructure de clé publique interne (PKI) de votre entreprise, si elle existe. Une PKI bien implémentée aura son autorité de certification racine approuvée par tous les ordinateurs de votre entreprise. Ceci est nécessaire pour que les certificats émis par l'autorité de certification soient utilisables dans l'entreprise.

Windows Server® est livré avec son propre logiciel de serveur de certificat depuis Windows® 2000 et vous pouvez utiliser ce logiciel pour créer votre propre PKI. Une implémentation complète de PKI nécessite beaucoup de planification, mais si vous avez seulement besoin d'une PKI dans le seul but d'émettre des certificats de signature de code, votre travail ne sera pas compliqué. Vous pouvez simplement utiliser la Stratégie de groupe pour pousser le certificat racine de votre autorité de certification vers vos ordinateurs pour qu'ils lui fassent confiance.

La deuxième possibilité consiste à utiliser une autorité de certification commerciale. L'un des avantages de l'utilisation d'une autorité de certification commerciale est que si vous sélectionnez l'une des principales autorités de certification, les ordinateurs de votre entreprise sont probablement déjà configurés pour faire confiance aux certificats de cette autorité de certification. (Notez que Windows XP fait confiance à un grand nombre d'autorités de certification par défaut, alors que Windows Vista® fait confiance à un nombre beaucoup plus réduit par défaut.) Verisign (verisign.com) est l'une autorités de certification commerciales très prisée. Il existe d'autres autorités intéressantes, notamment CyberTrust (cybertrust.com) et Thawte (thawte.com).

La troisième possibilité pour l'obtention d'un certificat de signature de code consiste à créer votre propre certificat auto-signé à l'aide d'un outil tel que Makecert.exe. Celui-ci est livré avec le SDK de la plate-forme Windows, il est installé avec certaines éditions de Microsoft® Office et vous pourrez le trouver à de nombreux autres emplacements. L'avantage d'un certificat auto-signé est qu'il est gratuit et ne nécessite aucune infrastructure. L'inconvénient, cependant, est qu'il n'est véritablement utilisable que sur votre ordinateur. Mais si vous avez seulement besoin de permettre l'exécution de script sur votre ordinateur, pour vos tests ou pour effectuer une expérimentation générale de la signature de code, Makecert.exe constitue une excellente solution. Vous trouverez la documentation de cet outil à l'adresse go.microsoft.com/fwlink/?LinkId=108538. Soyez conscient que de nombreuses versions de cet outil se sont succédé au fil des années, et qu'il est donc possible que votre ordinateur utilise une version antérieure ne fonctionnant pas exactement de la manière décrite par la documentation.

Une fois que vous disposez de Makecert.exe, vous pouvez créer un certificat auto-signé en exécutant une commande similaire à celle-ci depuis la ligne de commande de Windows PowerShell (et que je n'apprenne surtout pas que l'un d'entre vous a utilisé cmd.exe en lisant cette rubrique) :

makecert -n "CN=MyRoot" -a sha1 –eku
1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer 
–ss Root -sr localMachine

Exécutez ceci :

makecert -pe -n "CN=MyCertificate" -ss MY 
–a sh1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk 
–c root.cer

Makecert.exe vous demandera un mot de passe pour protéger la clé et créera le certificat. Vous pouvez vérifier l'installation en exécutant ce code dans Windows PowerShell :

gci cert:\CurrentUser\My -codesigning

Ceci affichera une liste de tous les éléments du lecteur CERT: (il s'agit de votre magasin de certificats Windows) qui correspondent à des certificats de signature de code. À propos, tout ceci est également décrit dans Windows PowerShell. Pour trouver cette documentation, exécutez simplement help About_Signing et lisez les quelques écrans affichés.

Signature d'un script

Maintenant que vous disposez d'un certificat et d'un script (pour vos tests, vous pouvez simplement en créer un rapidement, si nécessaire), vous êtes prêt à signer le script. C'est étonnamment facile avec Windows PowerShell ; entrez simplement :

$cert = @(gci cert:\currentuser\my
-codesigning)[0]
Set-AuthenticodeSignature myscript.ps1 $cert

La première partie récupère le premier certificat de signature de code installé (si plusieurs certificats sont installés et que vous voulez utiliser un certificat différent du premier, modifiez le « 0 » pour utiliser le numéro approprié). La deuxième partie signe le fichier (vous devrez bien entendu modifier le nom de fichier pour qu'il corresponde au vôtre). C'est aussi simple que ça ! Pour être totalement honnête, cependant, je trouve que le nom de l'applet Set-AuthenticodeSignature est un peu trop long et c'est pourquoi j'ai créé l'alias Sign. Maintenant, je peux exécuter simplement :

Sign myscript.ps1 $cert

Ouvrez maintenant ce script et vous verrez le bloc de signature inséré au bas. Essayez d'exécuter le script avec votre stratégie d'exécution définie sur AllSigned (Set-ExecutionPolicy AllSigned) et il devrait fonctionner sans problème. Vous allez maintenant modifier le script et l'enregistrer, mais veillez à ne pas le signer à nouveau. Windows Powershell devrait maintenant simplement refuser d'exécuter la version modifiée car la signature a été rompue.

Des efforts récompensés

Ceci en vaut-il vraiment la peine ? Est-il vraiment nécessaire d'avoir à payer 500 dollars ou plus pour un certificat ou de devoir implémenter un élément d'infrastructure complètement nouveau pour pouvoir écrire quelques lignes de script pour des tâches administratives ? Sachez que je suis également administrateur et que je comprends vos inquiétudes. La réponse la plus simple est que chaque effort nécessaire pour arriver à ceci en vaut la peine.

La sécurité implique en fait presque toujours un certain degré de tracas. Un logiciel antivirus peut être une plaie, mais vous ne pouvez pas vous en passer. Un pare-feu est sans aucun doute pénible mais, comme vous le savez, il n'est pas sûr de travailler sans pare-feu. Le contrôle de compte utilisateur (UAC) de Windows Vista peut également être agaçant, mais il assure la sécurité de votre ordinateur. Et n'est-ce pas cette sécurité améliorée que nous essayons tous d'obtenir ?

Windows Powershell est un outil puissant et, comme tout autre outil, il est toujours possible qu'il soit détourné en faille de sécurité par un utilisateur malveillant. C'est pourquoi il est important que vous preniez des mesures pour faire face à ces utilisateurs malveillants.

La signature de code est la meilleure mesure que vous puissiez prendre et ne nécessite pas un investissement conséquent. Par exemple, j'utilise un éditeur de scripts graphique qui signe automatiquement mes scripts chaque fois que j'appuie sur Enregistrer, et la signature de code est quasiment transparente pour moi.

Vous pouvez rendre ceci transparent, même sans un éditeur extravagant. Par exemple, vous pouvez créer un profil Windows PowerShell pour vous (créez le fichier Microsoft.PowerShell_profile.ps1 dans un dossier nommé WindowsPowerShell, situé dans votre dossier de documents), et lui ajouter cette fonction :

function sign ($filename) {
  $cert = @(gci cert:\currentuser\my 
-codesigning)[0]
Set-AuthenticodeSignature $filename $cert
}

Vous pouvez maintenant signer votre script en entrant simplement :

Sign c:\scripts\myscript.ps1

Bien entendu, ce script de profil devrait être le premier que vous signez ! L'objectif est de prendre quelques mesures pour rendre la signature de script aussi pratique que possible, pour qu'elle ne constitue pas un problème.

Le déploiement d'un PKI à serveur unique dans le seul but d'émettre un certificat de signature de code ne représente pas beaucoup de travail. (Gardez toutefois à l'esprit que vous avez vraiment besoin de préparer et planifier votre PKI, y compris de protéger l'autorité de certification racine et de fournir une récupération après incident, surtout si elle sera utilisée pour quoi que ce soit d'autre). Makecert.exe est toujours disponible si vous êtes seul à avoir besoin d'exécuter des scripts dans votre environnement. Notez que la rubrique d'aide About_Signing de Windows PowerShell inclut également des informations sur la sécurisation du certificat produit par Makecert.exe.

Don Jones est l'auteur de Windows PowerShell : TFM and VBScript, WMI, and ADSI Unleashed. Vous pouvez le contacter par l’intermédiaire du site Web PowerShellCommunity.org.

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