Catégorie : Non classé

Pas de commentaire

Impossible d’exécuter un script VBS sur 2012

  de

J’ai rencontré sur quelques serveurs des messages d’erreurs suite à des tentatives de traitement de scripts VBS, comme quoi le système était incapable de trouver le moteur VBScript : Can’t find script engine « VBScript » for script … étant donné que VBS est utilisé pour des générer des indicateurs, sans le moteur de script il n’y avait donc aucune remontée d’informations.

Le moteur VBS est une vulgaire librairie située dans le répertoire C:\Windows\System32 :

Ensuite, une clef de registre bien planquée permet de faire le lien entre cette DLL et le système ; c’est celle-ci qui sera appelée par Windows lorsqu’un script VBS sera exécuté. Cette clef de registre est la suivante : HKCR\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32 et c’est sa valeur par défaut qui contient le chemin vers la DLL.

Certains programmes – principalement des antivirus – remplacent la valeur par un chemin vers une autre DLL, qui leur permet d’exécuter des scripts VBS mais qui communiquent avec l’antivirus afin de détecter du code malveillant ; ce qui était exactement mon cas :

Seulement, en allant dans le repértoire de cette DLL, elle n’y était pas, d’où le message d’erreur donné plus haut. Il y avait donc trois solutions ou workarounds possibles :

  1. Réinstaller l’antivirus pour forcer ce dernier à réécrire tous ses fichiers proprement et à recopier la DLL ; ou à défaut copier la DLL d’un serveur qui la possède.
  2. Modifier la clef de registre pour reprendre sa valeur originale.
  3. Copier la DLL d’origine et la renommer pour correspondre au nom donné dans la base de registre.

D’emblée, la solution 2 n’est pas envisageable car cela serait trop facile pour un virus ou code malveillant de modifier la clef de registre afin de bypasser les contrôles de l’AV sur les scripts VBS. Même en tant qu’administrateur local de la machine et en ayant shunté l’AV, il m’a été impossible de modifier la valeur dans la clef, ni même de modifier les autorisations sur celles-ci, que ce soit directement ou via un fichier .reg ; la solution 3 fonctionne mais n’est pas la plus sécurisante car de ce fait, les scripts VBS ne sont pas contrôlés par l’antivirus.

J’ai donc choisi la première solution : la réinstallation. Une simple copie de la DLL d’un autre serveur aurait pu suffire mais après avoir comparé les répertoires des AV entre le serveur posant problème et un autre sain, j’ai constaté de belles différences, preuve que l’AV n’avait pas correctement été déployé et que l’installation a été d’une manière ou d’une autre avortée.

Une fois la réinstallation de l’AV effectuée, la DLL était en effet visible dans le répertoire et il m’a été possible d’appeler des scripts VBS sans message d’erreur.

Pas de commentaire

Powershell : obtention de la station qui déclenche un verrouillage de compte AD

  de

Ayant eu un cas récalcitrant de compte qui se verrouillait a priori tout seul, j’ai créé un petit script PowerShell à lancer en tant qu’administrateur sur un contrôleur de domaine. Ce script parcourt le journal d’événements de sécurité afin d’y trouver une entrée avec un identifiant 4740 correspondant à l’identifiant passé en paramètre.

Le script est disponible dans une version commentée sur mon miroir de téléchargement.

param
([string]$User)

$EventLog = Get-EventLog -LogName « Security » -InstanceID « 4740 » -Message « *$User* » -Newest 1
if ($EventLog -eq $null) {
Write-Host « User doesn’t exist or there is no log entry related to it. »
Break
}
Write-Host $EventLog[0].TimeGenerated
Write-Host $EventLog[0].Message

On appellera donc ensuite le script comme ceci :

PS > win_event4740.ps1 usertest

Par exemple, on peut utiliser LockoutStatus pour déterminer le DC qui procède au verrouillage du compte :

Sur cette capture, le compte n’est pas verrouillé, mais si il l’est, la colonne encadrée donnera le nom du DC ayant procédé au blocage du compte.

Ensuite, en se connectant au domain controller en question, l’exécution du script en passant en paramètre le login du compte verrouillé évitera d’ouvrir le journal d’évenements et d’avoir à filtrer parmi plusieurs évenements de verrouillages de compte.

Pas de commentaire

Erreur 530 lors de la connexion sur un FTP géré par IIS

  de

J’ai installé récemment sous IIS un site FTP de backup qui est une réplication exacte du premier pour un client externe. Avant de procéder à la livraison de celui-ci, je voulais faire un test de connexion avec un utilisateur lambda pour m’assurer que tout était bien configuré proprement. Dans cet exemple, le serveur FTP se base sur ActiveDirectory pour obtenir la liste des comptes habilités ou non à lire ou écrire.

Et voilà que sur FileZilla, je me heurte à une erreur 530.

Un petit tour dans l’ActiveDirectory pour voir si il ne s’agit pas d’une variable mal configurée :

Aucun répertoire de profil n’est configuré, mais pas plus sur tous les autres comptes qui fonctionnent sur le premier environnement. Je décide donc de tester ce compte sur ce dit premier environnement et pas mieux, je me heurte à la même erreur.

Avec accord du client, je duplique donc un compte qui fonctionne et fais le test : pas mieux.

Je vérifie donc ma configuration IIS, et tous les paramètres sont strictement identiques. S’agissant visiblement d’un problème de répertoire, je vais sur la page des paramètres d’isolement des utilisateurs et le désactive (ce qui fait que chaque utilisateur n’est plus cantonné à son propre répertoire) :

Sur cette capture d’écran, le réglage bloque l’utilisateur dans un répertoire donné afin qu’il ne puisse pas browser l’intégralité du serveur FTP.

Une fois l’option Do not isolate users cochée, tout fonctionne avec les deux comptes, le dupliqué et mon compte de test. Le problème provient donc bien d’un répertoire non accessible qui est indiqué quelque part dans les comptes utilisateurs. Je fais un test avec l’original du compte dupliqué, et ça fonctionne !

Je décide donc de regarder au niveau des attributs des comptes. Sur les comptes qui fonctionnent, je vois ceci :

Deux attributs msIIS-FTPDir et msIIS-FTPRoot qui contiennent les informations permettant au serveur FTP d’isoler l’utilisateur. Sans ces attributs, pas de connexion possible. En analysant les attributs du compte dupliqué et de mon compte de test, je ne vois pas ces attributs, rendant alors la connexion impossible :

L’erreur n’a donc côté client jamais existé puisque les comptes utilisés avaient bien ces attributs de renseignés, ce qui n’était pas le cas pour mon compte de test.

Pas de commentaire

Désactivation des ciphers AES 128, AES 256 et 3DES 168 sous Windows Server

  de

Il y a peu, j’ai dû désactiver sur une plateforme TLS 1.0 et 1.1. Aujourd’hui, rebelote, mais avec les ciphers Triple DES, ainsi qu’AES 128 et 256.

J’ai placé un extract de ces clefs de registre dans une archive disponible sur mon miroir de téléchargement.

En ouvrant regedit, on va se placer dans le chemin suivant :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

Puis, il suffira de créer une clef par cipher que l’on souhaite désactiver. Dans notre cas, nous allons créer 3 clefs ayant les noms suivants :

  • Triple DES 168
  • AES 128
  • AES 256

Dans chacune de ces clefs, il faudra créer une valeur DWORD appelée Enabled et ayant pour valeur 0.

On obtient donc quelque chose de similaire à ceci :

Un redémarrage est nécessaire pour appliquer les modifications car la DLL schannel ne lit les paramètres du registre qu’au démarrage du système. Si jamais il y a besoin d’annuler les modifications réalisées, il suffit de supprimer les clefs tout juste créées. A noter que si il y a désactivation d’un cipher utilisé pour encrypter les pages web utilisées par le serveur IIS, ces pages ne seront plus accessbiles, il convient donc de faire un test au préalable et de désactiver avec parcimonie les ciphers.

Si l’on désactive le cipher AES 256 via le registre, cette page ne sera plus accessible

Plus d’informations concernant les ciphers désactivables sous Windows sont disponibles à ce lien.