Dans ce tutoriel, nous allons apprendre à changer l'adresse MAC d'une machine virtuelle VirtualBox. Par défaut, VirtualBox génère une adresse MAC pour chacune des VM enregistrées sur votre ordinateur. Dans certains cas, il peut s'avérer utile de changer l'adresse MAC, soit par une autre adresse générée aléatoirement ou par une adresse MAC définie manuellement. J'ai le souvenir de certains applications ou services qui apportent une réelle importance à l'adresse MAC.
Pour rappel, l'adresse MAC correspond à l'adresse physique de l'interface réseau Ethernet d'un ordinateur. Chaque interface réseau (filaire ou sans-fil) dispose de sa propre adresse MAC et elle est très importante pour l'acheminement des paquets sur le réseau.
Puisque chaque VM dispose de sa propre adresse MAC, la modification de l'adresse MAC s'effectue dans les paramètres de chaque VM. Prenons l'exemple d'une VM nommée "Windows 11 22H2".
A partir de l'interface VirtualBox, il faut sélectionner la VM et cliquer sur "Configuration" afin d'accéder aux paramètres de cette VM. Ensuite, il faut cliquer sur "Réseau" à gauche puis sur la flèche à côté de "Avancé" pour afficher des paramètres supplémentaires. Ici, il y a le champ "Adresse MAC" qui apparaît : en cliquant sur le flèche à droite, on peut immédiatement générer une nouvelle adresse MAC pour sa machine virtuelle.
Que ce soit en mode NAT, accès par pont, réseau interne, etc... Il est possible de personnaliser l'adresse MAC. Toutefois, attention aux restrictions qu'il pourrait y avoir sur le réseau auquel vous êtes connecté (filtrage MAC, par exemple).
Au-delà de générer une adresse MAC aléatoirement, nous pouvons aussi définir notre propre adresse MAC, au format hexadécimale (16 symboles : de 0 à 9 et de A à F). Il est impératif de respecter ce format. Attention également à ne pas définir sur la machine virtuelle la même adresse MAC que votre hôte physique !
Voici un exemple avec une adresse MAC où j'ai modifié les 5 derniers caractères :
Il ne reste plus qu'à valider et à démarrer la machine virtuelle. Ensuite, en exécutant la commande "ipconfig /all", on peut s'apercevoir que l'adresse physique (soit l'adresse MAC) correspond bien à la valeur définie dans les paramètres de la VM VirtualBox ! Voici un exemple :
III. Conclusion
Ce paramètre très simple disponible dans les options de chaque machine virtuelle VirtualBox offre la possibilité de gérer l'adresse MAC utilisée par le système invité installé dans la VM !
Suite à la divulgation des deux failles de sécurité zero-day dans Microsoft Exchange, la firme de Redmond a mis en ligne 2 mesures d'atténuation pour que les entreprises puissent se protéger en attendant un correctif de sécurité. Problème, des chercheurs en sécurité sont parvenus à bypasser ces mesures préventives. Faisons le point.
Depuis vendredi 30 septembre 2022, les failles de sécurité CVE-2022-41040 et CVE-2022-41082 font beaucoup parler d'elles, et visiblement, cela n'est pas prêt de s'arrêter avec ce nouveau rebondissement. Pour rappel, c'est l'entreprise GTSC qui est à l'origine de la découverte de ces vulnérabilités signalées à Microsoft par l'intermédiaire de la Zero Day Initiative. Toutes les versions d'Exchange 2013, Exchange 2016 et Exchange 2019 sont affectées, que ce soit les instances on-premise ou en mode hybride connecté à Exchange Online (dans le cas où le serveur Exchange on-premise est exposé sur Internet).
Suite à la publication d'un rapport au sujet de ces failles de sécurité, Microsoft a réagi en confirmant qu'elles étaient utilisées dans quelques attaques. Ensuite, l'entreprise américaine a partagé des solutions temporaires à appliquer pour limiter le risque d'exploitation de ces vulnérabilités.
Premièrement, il convient de bloquer les accès sur les ports 5985 et 5986 associés à la gestion à distance via PowerShell (connexion WinRM). Deuxièmement, il y a une règle à créer dans la configuration de IIS pour bloquer certaines requêtes malveillantes (plus de détails ici). Ceci peut être déployé à l'aide du script officiel EOMTv2.
IIS : une règle insuffisante
Le chercheur en sécurité Jang affirme que cette règle dans IIS est trop limitée et après quelques efforts, il est parvenu à bypasser la règle afin d'exploiter ces vulnérabilités. De son côté, Will Dormann, analyste chez ANALYGENCE, est d'accord avec Jang et il affirme que le "@" dans l'URL fournie par Microsoft "semble inutilement précis, et donc insuffisant.". Pour valider les travaux de Jang, ce sont les chercheurs en sécurité de chez GTSC, à l'origine de la découverte de ces vulnérabilités qui ont validé que la protection n'était pas suffisante.
Pour que la règle soit en mesure de bloquer un plus grand nombre de requêtes malveillantes, elle doit être un peu moins précise. Jang suggère d'utiliser plutôt cette valeur d'URL dans la règle IIS :
.*autodiscover\.json.*Powershell.*
Si vous avez mis en place la règle dans IIS, vous n'avez plus qu'à adapter votre configuration. Microsoft n'a pas confirmé pour le moment qu'il fallait ajuster la règle dans IIS, et un correctif se fait toujours attendre.
Pour les administrateurs de parcs informatiques sous Windows avec des machines intégrées à un domaine Active Directory, le message d'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" est un grand classique. Le type d'erreur que l'on rencontre tous au moins une fois, même si l'on aimerait bien s'en passer ! Il existe diverses pistes et solutions pour se sortir de se pétrin... Notamment, manuellement via l'interface graphique, mais aussi en ligne de commande.
Dans ce tutoriel, je vais répondre à une question simple : comment corriger l'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" ? Sur une machine en anglais, le message d'erreur correspondant est "The trust relationship between this workstation and the primary domain failed".
II. Le principe des mots de passe "ordinateurs"
Lorsqu'une machine Windows est intégrée à un domaine Active Directory, un objet appartenant à la classe "computer" est créé dans l'annuaire. Cet objet est alors un compte d'ordinateur pour la machine en question. Au-delà du nom, il y a un mot de passe qui est associé à ce compte : ce mot de passe est connu de la machine Windows et de l'annuaire Active Directory. Par défaut, ce mot de passe est valide pour une durée de 30 jours. Au bout de 30 jours, il est renouvelé automatiquement, sans aucune action de votre part.
En modifiant une stratégie de groupe sur votre environnement, par exemple la GPO "Default Domain Policy" qui est native, vous pourrez retrouver le paramètre "Membre de domaine : ancienneté maximale du mot de passe du compte ordinateur" qui montre que la valeur par défaut est de 30 jours.
Quand ce message d'erreur se produit, c'est comme si la confiance entre les deux parties avait soudainement disparu. Dans de nombreux cas, cela s'explique par le fait que le mot de passe de l'ordinateur local (la machine Windows intégrée dans l'AD) ne correspond pas au mot de passe stocké dans l'Active Directory. Autrement dit, le renouvellement du mot de passe ne s'est pas passé comme prévu...
Le renouvellement du mot de passe est initié par la machine Windows, à partir du service Netlogon. Cette opération s'effectue au démarrage, ou au moment de s'authentifier auprès du contrôleur de domaine. Le mot de passe est alors stocké dans le Registre Windows sous "HKLM\SECURITY\Policy\Secrets". De son côté, l'Active Directory stocke également ce nouveau secret. Dans une très grande majorité des cas, ce processus s'effectue correctement : heureusement, sinon tous les 30 jours ce serait infernal.
Parfois, cette opération échoue et l'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" se produit ! Il arrive même que sur une même machine, cette erreur revienne assez régulièrement. Je pense qu'il y a plusieurs erreurs qui peuvent se produire, plusieurs cas différents, pour en arriver à ce message. Par exemple, si le mot de passe est bien actualisé dans l'Active Directory mais pas dans la base locale : on se retrouve avec un secret différent. Cela peut se produire aussi si l'objet correspondant à cet ordinateur est supprimé de l'Active Directory.
Voilà, le décor est posé, maintenant nous allons voir quelques méthodes basées sur PowerShell pour corriger cette erreur. Je préfère donner plusieurs pistes, au cas où une méthode ne s'applique pas, vous pouvez en essayer une autre.
III. Dépannage - "La relation d’approbation entre cette station de travail et le domaine principal a échoué"
A. La méthode manuelle
La méthode manuelle est connue de beaucoup d'administrateur système. Elle fonctionne, mais elle n'est pas pratique, car elle nécessite de déconnecter la machine du réseau. Elle consiste à réaliser les actions suivantes sachant que l'objectif est de retirer la machine du domaine et de la réintégrer :
Le principal inconvénient de cette méthode, c'est qu'elle implique une présence physique puisqu'il faut déconnecter la machine du réseau. Pour sortir la machine du domaine et l'ajouter de nouveau, on peut utiliser l'interface graphique de Windows ou les commandes PowerShell "Remove-Computer" et "Add-Computer".
B. La méthode PowerShell : Test-ComputerSecureChannel
Depuis plusieurs années, il est possible de corriger cette erreur avec PowerShell ! Une très bonne nouvelle, car ça veut dire qu'on peut le faire à distance, donc c'est beaucoup plus pratique. La commande Test-ComputerSecureChannel exsite depuis Windows 10, elle est toujours disponible sur Windows 11. Personnellement, je vous recommande cette méthode.
Sur une machine où la relation d'approbation est cassée, il faut se connecter et exécuter simplement cette commande dans une console PowerShell :
Test-ComputerSecureChannel
Il est également possible de cibler un contrôleur de domaine spécifique, comme on le fait avec les commandes du module Active Directory. Par exemple :
Cette commande retourne simplement true (vrai) ou false (faux) pour indiquer l'état de la relation d'approbation entre l'ordinateur et l'annuaire (avec le paramètre -Verbose). Dans le cas où vous avez l'erreur de relation d'approbation, la commande retournera "false". De ce fait, il faudra ajouter le paramètre -Repair qui permet de réparer la relation d'approbation ainsi que les identifiants.
En ce qui concerne le compte utilisateur, il peut s'agir d'un compte Administrateur ou tout simplement d'un compte qui a le droit d'ajouter des machines au domaine Active Directory.
Puisque c'est du PowerShell, on peut aussi agir à distance sur une ou plusieurs machines avec Invoke-Command. Voici un exemple :
Note : que ce soit avec cette méthode ou la méthode qui va suivre, si l'objet ordinateur n'existe pas dans l'Active Directory, il vaut mieux le créer avant. Avec la console "Utilisateurs et ordinateurs Active Directory" (ou une autre méthode), effectuez un clic droit "Nouveau" puis "Ordinateur". Attribuez le même nom.
C. La méthode PowerShell bis : Reset-ComputerMachinePassword
Lorsque l'erreur se produit, il y a une seconde commande PowerShell qui peut rendre service pour se sortir d'affaire : Reset-ComputerMachinePassword, disponible avec Windows PowerShell 5.1. Cette commande permet de réinitialiser le mot de passe du compte ordinateur de la machine locale.
Là encore, cette commande s'exécute depuis l'ordinateur où se situe l'erreur.
Netdom est un outil qui existe depuis très longtemps sur Windows, avant même que PowerShell pointe le bout de son nez. Il permet aussi de réinitialiser le mot de passe du compte ordinateur à partir de la ligne de commande.
Voici un exemple où je contacte le contrôleur de domaine "SRV-ADDS", en utilisant le compte "florian" et sans préciser le mot de passe en clair (d'où le "*").
netdom resetpwd /s:SRV-ADDS /ud:florian /pd:*
IV. Conclusion
Voilà, nous venons voir différentes manières de corriger l'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" sur vos machines Windows ! Avec PowerShell pour les machines récentes, et avec netdom (ou la méthode manuelle) pour les machines avec des systèmes plus anciens, car on le sait tous qu'il y en a encore en circulation !
Si vous connaissez une autre méthode, n'hésitez pas à nous en faire part avec un commentaire !
En 2021, le groupe de cybercriminels Lazarus a utilisé une tactique d'attaque qui s'appuyait sur une vulnérabilité dans un firmware Dell pour déployer un rootkit sur Windows. Pour rappel, il s'agit d'un groupe sponsorisé par la Corée du Nord.
Les chercheurs en sécurité de chez ESET ont découvert et analysé des outils malveillants utilisés par le groupe de pirates Lazarus pendant l'automne 2021. Basée sur des e-mails aux couleurs d'Amazon, cette campagne du groupe Lazarus a ciblé un employé d'une entreprise néerlandaise spécialisée dans l'aérospatial, ainsi qu'un journaliste politique belge. Cette campagne est associée au nom "Bring Your Own Vulnerable Driver".
En exploitant cette faille de sécurité avec leur outil FudModule, les cybercriminels du groupe Lazarus sont en mesure de désactiver toutes les fonctionnalités de protection de la machine Windows compromise. Les chercheurs d'ESET précisent : "Il utilise des techniques contre les mécanismes du noyau de Windows qui n'ont jamais été observées dans un logiciel malveillant auparavant." - Un rootkit particulièrement redoutable, même si l'exploitation de vulnérabilités dans les pilotes et les firmwares n'est pas nouvelle en soi.
Dans le cadre de cette campagne, le groupe Lazarus a utilisé d'autres outils malveillants, notamment leur porte dérobée "HTTPS" surnommée "BLINDINGCAN" (connue aussi sous les noms AIRDRY et ZetaNile). Grâce à elle, le pirate peut contrôler un système précédemment compromis, car elle lui sert de point de connexion.
Les différents outils et techniques utilisées par le groupe Lazarus montrent une nouvelle fois qu'ils sont bien organisés, et qu'ils sont agissent dans trois domaines de la cybersécurité : la recherche du gain financier, le cyber-espionnage et le cyber-sabotage.
Microsoft a publié des informations supplémentaires au sujet des failles zero-day dans Microsoft Exchange. Faisons le point.
Désormais, ces deux failles de sécurité zero-day Exchange ont une référence CVE associée et nous savons quelles sont les versions de Microsoft Exchange affectées : Microsoft Exchange 2013, Microsoft Exchange 2016, et Microsoft Exchange 2019. À chaque fois, toutes les versions sont affectées, c'est-à-dire peu importe le "CU" qui est installé.
Sur son site, Microsoft précise : "La première vulnérabilité, identifiée comme CVE-2022-41040, est une vulnérabilité de type SSRF (Server-Side Request Forgery), tandis que la seconde, identifiée comme CVE-2022-41082, permet l'exécution de code à distance (RCE) lorsque PowerShell est accessible à l'attaquant". En résumé, nous avons donc :
CVE-2022-41040 : faille de type injection de requêtes forgées côté serveur exploitable par un attaquant authentifié
CVE-2022-41082 : faille permettant l'exécution de code arbitraire à distance pour un attaquant authentifié
D'après Microsoft, et c'est une précision importante, il convient d'être authentifié pour compromettre le serveur de messagerie Microsoft Exchange en exploitant ces deux vulnérabilités. Une attaque passe par l'exploitation des deux vulnérabilités, car la faille CVE-2022-41040 peut permettre à un attaquant d'exploiter la faille CVE-2022-41082 à distance, grâce à une requête malveillante.
L'entreprise américaine a confirmé que ces vulnérabilités étaient utilisées dans le cadre d'attaques.
Comment protéger son serveur Exchange ?
Au sein de son article lié à ces failles de sécurité, Microsoft a mis en ligne des indications pour permettre aux entreprises de se protéger. Tout d'abord, la firme de Redmond a repris la solution proposée par la société GTSC, à savoir bloquer certaines requêtes sur le serveur IIS.
Même si tout cela est détaillé sur le site de Microsoft (avec des images plus ou moins visibles), voici en résumé :
1 - Sur le serveur Autodiscover frontend, ouvrez la console IIS, accédez au module URL Rewrite et Request Blocking (blocage de requêtes).
2 - Ajoutez la chaîne ".*autodiscover\.json.*\@.*Powershell.*" pour le chemin de l'URL
3 - Choisissez la condition d'entrée (input) suivante : {REQUEST_URI}
Si vous utilisez Microsoft Exchange, il est recommandé de mettre en place cette mesure protectrice dès que possible. Pour vous aider, Microsoft a mis en ligne son script "EOMTv2" sur GitHub.
Pour les administrateurs qui souhaitent vérifier si leur serveur Exchange a déjà été compromis, voici la commande PowerShell à exécuter (en précisant le chemin vers les journaux IIS, qui est par défaut "%SystemDrive%\inetpub\logs\LogFiles") :
Ceci permet d'analyser les logs de IIS à la recherche d'une requête malveillante qui serait le signe d'une tentative d'exploitation.
En complément, et ça c'est nouveau par rapport aux informations publiées en fin de semaine dernière, Microsoft recommande de bloquer les ports associées à WinRM et à la gestion à distance via PowerShell, à savoir :
HTTP : 5985
HTTPS : 5986
L'objectif étant d'éviter que l'attaquant puisse accéder au serveur à distance via PowerShell, car ceci est possible en exploitant ces deux vulnérabilités.
Bientôt un correctif officiel ?
Le prochain Patch Tuesday sera mis en ligne par Microsoft le mardi 11 octobre 2022. Mais, il y a des chances pour qu'un correctif soit mis en ligne avant cette date afin de permettre aux entreprises de sécuriser leur serveur de messagerie dès que possible.
