PrintNightmare – CVE-2021-34528

Microsoft a publié une vulnérabilité dans le service spouleur d’impression, dont tous les détails peuvent se retrouver à ce lien. Il est important de prendre cette faille au sérieux car elle permet notamment d’exécuter du code en tant qu’utilisateur SYSTEM ce qui peut être désastreux en fonction de la machine sur laquelle l’exécution est réalisée.

Plusieurs workarounds sont proposés par Microsoft, et ayant mis en place les corrections nécessaires, je vais partager les quelques scripts (Powershell 5.1) que j’ai conçu afin de me faciliter la tâche.

Tout d’abord, à partir d’un fichier CSV d’inventaire, ce script va interroger le système distant pour récupérer l’état complet du service Spooler (état actuel, type de démarrage, etc.). Ainsi, il est possible d’avoir un état des lieux sur l’exécution de ce service.

$inv = Import-Csv inventaire.csv
$output = @()
foreach($srv in $inv){
    Write-Output $srv.hostname
    $output+=Get-Service -Name Spooler -Computer $srv.hostname
}
$output | Export-Csv spooler_status.csv -Delimiter ";" -Encoding UTF8

Ce deuxième script va appliquer le workaround conseillé par Microsoft ; il s’agit de l’extinction du service Spooler et la désactivation du démarrage automatique de celui-ci. Le script interroge ensuite de nouveau le service pour obtenir son état et génère un fichier CSV de retour.

$inv = Import-Csv spooler_off.csv -Delimiter ";"
$output = @()
foreach($srv in $inv){
    Write-Host $srv.MachineName
    Stop-Service -InputObject $(Get-Service -Name Spooler -ComputerName $srv.MachineName)
    Set-Service -Name Spooler -StartupType Disabled -ComputerName $srv.MachineName
    $srvstat = New-Object PSCustomObject
    $srvstat | Add-Member -Name "Hostname" -Value $srv.MachineName -MemberType NoteProperty
    $srvstat | Add-Member -Name "SpoolerStatus" -Value (Get-Service -Name Spooler -ComputerName $srv.MachineName).Status -MemberType NoteProperty
    $output+=$srvstat
}
$output | Export-Csv spooler_processed.csv -Encoding UTF8 -Delimiter ";"

Et enfin, puisque Microsoft a mis à jour aujourd’hui la vulnérabilité en incluant un contrôle de clefs de registre qui n’était pas présent hier, ce troisième script va interroger les serveurs d’une liste au format CSV afin de récupérer l’état des clefs de registre mettant à risque le système.

$output = @()
$inv = Import-Csv inventaire_hostname.csv -Delimiter ";"
foreach($srv in $inv){
    Write-Host $srv.Hostname
    $pnp = New-Object PSCustomObject
    if(Invoke-Command -ComputerName $srv.Hostname { Test-Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\" }){
        $pnp | Add-Member -Name "Hostname" -Value $srv.Hostname -MemberType NoteProperty
        $pnp | Add-Member -Name "PointAndPrintKeyExists" -Value "Yes" -MemberType NoteProperty  
        if((Invoke-Command -ComputerName $srv.Hostname { Get-ItemPropertyValue "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\" -Name NoWarningNoElevationOnInstall }) -eq 1) {
            $pnp | Add-Member -Name "NoWarningNoElevationOnInstall" -Value "1" -MemberType NoteProperty
        }
        else { $pnp | Add-Member -Name "NoWarningNoElevationOnInstall" -Value "0" -MemberType NoteProperty }
        if((Invoke-Command -ComputerName $srv.Hostname {Get-ItemPropertyValue "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\" -Name NoWarningNoElevationOnUpdate }) -eq 1) {
            $pnp | Add-Member -Name "NoWarningNoElevationOnUpdate" -Value "1" -MemberType NoteProperty
        }
        else { $pnp | Add-Member -Name "NoWarningNoElevationOnUpdate" -Value "0" -MemberType NoteProperty }
    }
    else {$pnp | Add-Member -Name "Hostname" -Value $srv.Hostname -MemberType NoteProperty ; $pnp | Add-Member -Name "PointAndPrintKeyExists" -Value "No or Server Unreacheable" -MemberType NoteProperty }
    $output+=$pnp
}
$output | Export-Csv pointnprint.csv -Delimiter ";" -Encoding UTF8 

En fonction du nombre de serveurs à interroger, l’exécution du script peut être relativement longue. Par souci de rapidité de développement, je n’ai pas inclus de contrôle de réponse du serveur avant d’utiliser Invoke-Command. Il est donc possible que Powershell retourne une erreur si le serveur ne répond pas à la requête ou si il la rejette, cela n’impacte pas le bon déroulement du script.

Naturellement, une étude d’impact et de faisabilité est à faire avant toute intervention et extinction d’un service, même pour le spouleur qui n’est pas d’une importance capitale sur une grande majorité de machines. Il ne reste donc plus qu’à attendre l’application des correctifs de sécurité publiés par Microsoft.

Impossible d’imprimer un PDF depuis Firefox ESR 52 sur Windows 10 version 2004

Problématique de départ : le plugin Acrobat Reader pour Firefox ne permet pas d’imprimer un PDF ouvert dans le navigateur. L’impression d’un PDF depuis le poste de travail est possible, et l’impression d’un PDF sous Edge ne pose pas de problème non plus, mais Edge (à moteur Chromium sous ce build de Windows) ouvre nativement les PDF à la différence de cette version de Firefox qui a besoin d’un plugin externe.

Microsoft a visiblement changé quelque chose dans la manière dont les appels à la partie impression sont traités par Windows dans cette version 2004. En effet, sur les versions précédentes (c’est-à-dire 1909 et avant), l’impression d’un PDF depuis Firefox ne posait pas de soucis.

Grâce aux forums d’Adobe, j’ai pu trouver la solution à ce dysfonctionnement qui se situait selon moi sur l’interface Firefox / Acrobat Reader.

Dans les préférences d’Acrobat, se rendre dans Security (Enhanced), puis décocher Enable Protected Mode at Startup et Enable Enhanced Security. En français, il s’agit de Protection (renforcée) puis de Activer le mode protégé au démarrage et Activer la protection renforcée. Il est nécessaire de relancer Firefox et Acrobat Reader pour que les modifications soient prises en compte.

Dysfonctionnements sur des partages DFS

Ces derniers jours, j’ai été confronté à un incident qui arrivait de manière complètement aléatoire lors de l’accès à des partages réseaux via DFS. Dans l’explorateur, un comportement erratique de celui-ci en naviguant dans les partages DFS, l’impossibilité de créer des répertoires (« une erreur réseau inattendue s’est produite« ), la nécessité d’appuyer sur F5 pour voir le contenu d’un dossier ou encore l’impossibilité pour une application comme Excel d’écrire dans le chemin étaient des symptômes du dysfonctionnement.

Voici quelques caractéristiques :

  • Toutes les versions sur parc de Windows 10 sont concernées (1703, 1809, 1903)
  • De multiples serveurs de fichiers hébergeant les partages réseaux sont concernés
  • Les utilisateurs sont situés sur des emplacements géographiques différents et le dysfonctionnement est présent par connexion filaire, en WiFi ou via le VPN.

La recherche était d’autant plus compliquée pour isoler le dysfonctionnement que :

  • Aucun log n’était parlant ou utile sur les clients ou les serveurs de fichiers, pas plus que côté équipements réseau ou couche de virtualisation
  • Je n’avais aucun dysfonctionnement côté baie de stockage
  • Aucune modification n’a été faite côté infrastructure Windows / ActiveDirectory
  • Aucune campagne de patch n’a été réalisée avant l’apparition du bug.

Le travail n’a pas été facile car le problème étant complètement aléatoire et parfois résolu d’un simple F5 où d’un redémarrage, l’incident ne m’arrivait pas de suite et était généralement traité par les équipes support. Tous les serveurs étant sur le même hyperviseur, j’ai déplacé un ou deux serveurs sur un autre hôte : sans effet. Par chance, j’ai été très rapidement victime du dysfonctionnement, ce qui m’a permis de dégrossir l’incident et d’éliminer quelques pistes.

L’accès aux partages réseau DFS fonctionnait mal, que le lecteur soit monté sur un disque réseau ou un emplacement réseau ; à la main ou par GPO, aucune différence. Cependant, en accès direct en appelant le partage par le nom du serveur, aucun problème. Je n’ai rien relevé de particulier concernant la connectivité au serveur de fichiers en lui-même et les écoutes du réseau n’ont rien révélé de ce point de vue : j’étais donc quasiment certain qu’il s’agissait d’un problème au niveau de la couche DFS et non du partage de fichiers en lui-même.

J’axe donc mes recherches sur le DFS. Sur un poste qui rencontre le problème, une capture Wireshark est effectuée et je récupère les trames TCP qui vont enfin me permettre d’avancer. En effet, je vois régulièrement ces messages dans les trames TCP :

Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \dundermifflin.inc\SHARES\MSCOTT
Ioctl Response, Error: STATUS_NOT_FOUND

En cherchant un peu sur le web, je suis tombé sur des cas où un référent DFS a été créé et supprimé rapidement, entraînant un souci lors de la redescente des informations sur le poste de travail. Le poste de travail tentait alors d’interroger un référent DFS qui n’existait plus. Ce n’était pas mon cas, en utilisant l’outil dfsutil comme ceci, je n’avais aucune trace du mauvais référent :

dfsutil /pktinfo

Cette commande permet de sonder les référents DFS qui répondent aux requêtes DFS soumises par les postes clients. Je n’avais aucun référent caduc ni aucun code d’erreur particulier. En continuant de creuser avec mon tractopelle, je suis tombé sur l’outil dfsdiag qui allait me mettre sur la bonne voie.

dfsdiag permet d’effectuer des tests sur le bon fonctionnement de l’infrastructure DFS. Voici l’instruction que j’ai utilisé :

dfsdiag /testdfsintegrity /DfsRoot:\\dundermifflin.inc\SHARES /Recurse

J’ai donc bien une erreur concernant ce namespace :

Je teste sur un autre namespace pour lequel je n’ai eu aucun cas de remonté et qui est porté par des serveurs différents, et je n’ai pas ce message d’erreur.

Je recherche donc sur le net à propos de cette erreur et je tombe sur ce lien salvateur. Les namespaces DFS portés par un serveur doivent être enregistrés dans le registre ; il s’agit des clefs présentes dans l’arborescence Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\domainV2\. Dans le cas du serveur indiqué dans le message d’erreur, je n’ai rien, par contre sur un autre serveur du pool DFS, j’ai bien des clefs qui correspondent aux namespaces, avec pour chacune d’entre elles, deux valeurs de type REG_SZ (chaîne de caractères) LogicalShare et RootShare qui contiennent le nom du namespace en question (cachés sur la capture) :

J’ai donc procédé à la création des clefs et valeurs correspondantes sur le serveur incriminé, puis relancé le service DFS Namespace. En exécutant de nouveau dfsdiag, l’erreur a disparu et je n’ai plus eu de cas de dysfonctionnements d’accès aux partages DFS.

Fermeture de force d’une session RDP avec rwinsta

J’ai eu le cas d’une session utilisateur sévèrement plantée sur un serveur Windows : tellement plantée que le login n’était même plus visible dans le gestionnaire de tâches et qu’il était impossible de fermer via le menu contextuel. L’utilisateur était incapable de se reconnecter en RDP sur la machine.

Afin de clôturer la session de force, je vais avoir recours à deux outils en ligne de commande : qwinsta et rwinsta ; qwinsta va me permettre de faire la requête afin de récupérer l’identifiant de la session plantée et rwinsta va me permettre de tuer cette session.

Sur la capture d’écran, ma session vrillée correspond à l’ID 63. Les deux autres sont actives et la mienne est indiquée par le signe > devant le nom. Il suffit d’appeler la commande suivante pour forcer la fermeture de cette session.

rwinsta 63