Sécurité des scripts : stratégie d'exécution, secrets et signature

Sécuriser un script, c'est empêcher qu'il devienne une porte d'entrée : qu'un attaquant le modifie pour exécuter ses propres commandes, y lise un mot de passe, ou détourne les droits avec lesquels il tourne. Ce chapitre explique la stratégie d'exécution de PowerShell (et ce qu'elle ne protège pas), la signature des scripts, le rangement des secrets, la journalisation de PowerShell, les droits des scripts Linux et l'analyse automatique du code.

La stratégie d'exécution de PowerShell

La stratégie d'exécution (execution policy) dit quels scripts PowerShell accepte de lancer sous Windows.

PowerShell 7 installé sous Windows démarre en RemoteSigned : son fichier powershell.config.json, dans le dossier d'installation, fixe cette valeur.

Elle se règle à plusieurs portées, de la plus forte à la plus faible : MachinePolicy et UserPolicy (fixées par GPO), Process (la session en cours), CurrentUser, LocalMachine. La première portée définie l'emporte.

Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser    RemoteSigned
 LocalMachine       Undefined

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned   # pour ton compte, sans droits d'administrateur

En entreprise, la stratégie se fixe par GPO : Configuration ordinateur > Stratégies > Modèles d'administration > Composants Windows > Windows PowerShell > Activer l'exécution des scripts. Une valeur fixée par GPO ne peut pas être changée par Set-ExecutionPolicy.

« Venu d'Internet » se reconnaît à la marque du Web : quand un navigateur ou un client de messagerie enregistre un fichier, Windows lui ajoute un flux de données Zone.Identifier qui indique sa provenance. Après avoir lu et vérifié un script téléchargé, Unblock-File .\script.ps1 retire cette marque.

Signer un script

Une signature Authenticode garantit qu'un script vient bien de son auteur et qu'il n'a pas été modifié depuis : le moindre caractère changé invalide la signature. Avec la stratégie AllSigned, un script modifié par un attaquant ne s'exécute plus.

Il faut un certificat de signature de code, délivré par l'autorité de certification de l'entreprise (modèle de certificat « Signature de code » d'AD CS) ; le fonctionnement des certificats et de la signature numérique est expliqué dans le cours Cryptographie.

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\New-ComptesArrivees.ps1 -Certificate $cert `
    -TimestampServer 'http://timestamp.digicert.com'
Get-AuthenticodeSignature -FilePath .\New-ComptesArrivees.ps1 | Select-Object Status, StatusMessage

La signature s'ajoute en bas du fichier, dans un bloc de commentaires # SIG # Begin signature block. L'horodatage prouve que le script a été signé pendant la validité du certificat : la signature reste valable après l'expiration de celui-ci. Get-AuthenticodeSignature renvoie un Status :

Pour que les postes et serveurs fassent confiance aux scripts signés, le certificat de l'autorité racine doit être dans le magasin des autorités racines de confiance, et celui du signataire dans les éditeurs approuvés : une GPO les déploie.

Ranger les secrets

Un mot de passe ou un jeton écrit dans un script est lu par tous ceux qui lisent le script : les collègues, la sauvegarde, le dépôt Git, l'attaquant qui a pris pied sur le serveur. Les solutions, de la meilleure à la moins bonne :

1. Pas de secret du tout. Une tâche planifiée qui tourne sous un gMSA s'authentifie sur le réseau sans que personne ne connaisse de mot de passe ; un script lancé par un administrateur utilise ses propres droits (Kerberos).
2. Un coffre de secrets. Le module Microsoft.PowerShell.SecretManagement donne des commandes uniques (Get-Secret, Set-Secret) au-dessus de différents coffres : le coffre local SecretStore, ou un coffre d'entreprise (Azure Key Vault, HashiCorp Vault, KeePass, par des extensions).
3. Un fichier chiffré pour un seul compte. Export-Clixml enregistre un objet PSCredential dont le mot de passe est chiffré par la DPAPI de Windows : seul le même compte, sur la même machine, peut le relire.
4. Une variable d'environnement ou un fichier protégé, lisible par le seul compte qui lance le script : la solution courante sous Linux.

# Le coffre SecretStore, une fois pour toutes (PowerShell 7.4+ inclut Install-PSResource)
Install-PSResource -Name Microsoft.PowerShell.SecretManagement, Microsoft.PowerShell.SecretStore
Register-SecretVault -Name Coffre -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
Set-Secret -Name ZabbixLecture -Secret (Read-Host -AsSecureString 'Jeton Zabbix')

# Dans le script
$jeton = Get-Secret -Name ZabbixLecture -AsPlainText

# Un identifiant chiffré pour le compte qui lance la tâche : à créer EN TANT QUE ce compte, sur ce serveur
Get-Credential | Export-Clixml -Path C:\Scripts\Secrets\copie-compta.xml
$cred = Import-Clixml -Path C:\Scripts\Secrets\copie-compta.xml

Le coffre SecretStore demande par défaut un mot de passe pour s'ouvrir, ce qui ne convient pas à une tâche sans surveillance ; Set-SecretStoreConfiguration permet de régler ce comportement, au prix d'une protection qui repose alors sur le compte Windows. Dans Windows PowerShell 5.1, les modules s'installent avec Install-Module au lieu d'Install-PSResource.

Sous Linux, un secret se range dans un fichier qui n'appartient qu'au compte du script, et se lit au lancement :

sudo install -o rapports -g rapports -m 0600 /dev/null /etc/sorbier/zabbix.token   # fichier vide, droits 600
sudoedit /etc/sorbier/zabbix.token                                                  # y coller le jeton

ZABBIX_TOKEN=$(< /etc/sorbier/zabbix.token)

Pour un script lancé par systemd, la directive LoadCredential=zabbix-token:/etc/sorbier/zabbix.token dans la section [Service] met le secret à disposition du seul service, dans le fichier $CREDENTIALS_DIRECTORY/zabbix-token, sans qu'il soit lisible par les autres processus.

Enfin, un secret qui a été commité dans Git, même supprimé ensuite, reste dans l'historique : on le considère comme compromis et on le change. Le cours Git et GitHub explique comment l'éviter avec .gitignore et que faire si c'est arrivé.

Journaliser ce que fait PowerShell

PowerShell est un outil d'administration puissant, présent sur toutes les machines Windows : c'est aussi l'un des outils préférés des attaquants, qui l'utilisent pour agir sans déposer de programme (on parle de living off the land). La défense consiste à tout journaliser pour pouvoir détecter et enquêter :

• la journalisation des blocs de script (Script Block Logging), activée par GPO (Modèles d'administration > Composants Windows > Windows PowerShell > Activer la journalisation de blocs de scripts PowerShell), enregistre le code réellement exécuté dans l'événement 4104 du journal Microsoft-Windows-PowerShell/Operational, même s'il avait été masqué ou encodé ;
• la transcription garde un fichier texte de chaque session, dans un dossier protégé ;
• les événements sont envoyés au serveur de journaux et analysés par le SIEM, qui alerte sur les signes classiques : un powershell.exe lancé avec -EncodedCommand ou -WindowStyle Hidden par un traitement de texte, un téléchargement suivi d'une exécution, une tâche planifiée créée hors des heures habituelles (événement 4698 du journal de sécurité).

La mise en place de ces journaux et de leur transfert est décrite dans le cours Windows Server.

Les droits des scripts Linux et sudo

Sur un serveur Linux, la sécurité d'un script tient à trois règles :

• un script lancé par root n'est modifiable que par root, de même que le dossier qui le contient : install -o root -g root -m 0750 (chapitre 13) ;
• un compte de service n'a que les droits utiles. Si le compte rapports doit lancer un seul script avec les droits de root, une règle sudo l'autorise pour ce script et rien d'autre, écrite avec sudo visudo -f /etc/sudoers.d/rapports :

rapports ALL=(root) NOPASSWD: /usr/local/sbin/sauvegarde-config.sh

• une valeur venue de l'extérieur n'est jamais exécutée. Pas d'eval en Bash ni d'Invoke-Expression en PowerShell sur une donnée lue dans un fichier, une API ou un argument : un nom de fichier comme x; rm -rf / deviendrait une commande. Les guillemets autour des variables, -- avant les noms de fichiers et les filtres avec variables de l'annuaire jouent le même rôle que les requêtes préparées contre l'injection SQL.

Analyser le code automatiquement

Deux outils relisent tes scripts et signalent les erreurs classiques avant qu'elles ne se produisent :

Install-PSResource -Name PSScriptAnalyzer
Invoke-ScriptAnalyzer -Path C:\Scripts -Recurse        # alias inutilisés, variables jamais lues, mots de passe en clair…

sudo apt install shellcheck
shellcheck /usr/local/sbin/sauvegarde-config.sh       # guillemets oubliés, tests mal écrits, pièges de set -e…

PSScriptAnalyzer signale par exemple un paramètre nommé Password de type [string] (règle PSAvoidUsingPlainTextForPassword) ou un Invoke-Expression. ShellCheck signale chaque variable non protégée (SC2086), chaque cd non vérifié (SC2164). Les deux s'intègrent à l'éditeur et à un pipeline d'intégration continue, qui refuse un script défectueux avant son déploiement (cours Intégration continue).

Exercices

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy        AllSigned
   UserPolicy        Undefined
      Process        Undefined
  CurrentUser     Unrestricted
 LocalMachine     RemoteSigned

rapports ALL=(root) NOPASSWD: /usr/local/sbin/sauvegarde-config.sh