Une faille de sécurité zero-day a été découverte au sein de la console d'administration de la solution GoAnywhere MFT ! En exploitant cette vulnérabilité, un attaquant peut exécuter du code à distance sur le serveur et accéder aux données.
Quelques mots sur GoAnywhere MFT : il s'agit d'une solution permettant l'échange de fichiers sécurisés entre une entreprise et ses partenaires, tout en bénéficiant de journaux précis sur les accès aux fichiers.
D'après les premières informations, cette faille de sécurité affecte aussi bien les instances SaaS que les instances on-premises de GoAnywhere MFT. Pour que cette vulnérabilité puisse être exploitée, la console d'administration doit être accessible depuis Internet, puisqu'elle représente le point d'entrée pour l'attaquant. En temps normal, ce n'est pas le cas : "Le vecteur d'attaque de cet exploit nécessite l'accès à la console d'administration de l'application, qui, dans la plupart des cas, n'est accessible que depuis le réseau privé de l'entreprise, par le biais d'un VPN, ou par des adresses IP autorisées (lorsqu'elle est exécutée dans des environnements Cloud, comme Azure ou AWS)", précise l'éditeur de GoAnywhere MFT.
Toutefois, d'après l'expert Kevin Beaumont, il y aurait plus de 1 000 serveurs GoAnywhere MFT exposés sur Internet, et vulnérable à cette faille de sécurité !
A l'heure où j'écris, ces lignes, il n'existe pas encore de correctif ! Toutefois, Fortra demande aux administrateurs de serveurs GoAnywhere MFT d'effectuer les actions suivantes pour se protéger :
1 - Sur le système de fichiers où GoAnywhere MFT est installé, éditez le fichier "install_dir]/adminroot/WEB_INF/web.xml".
2 - Trouvez et supprimez (ou commentez) la configuration suivante de servlet et de servlet-mapping comme sur l'image ci-dessous.
3 - Redémarrez l'application GoAnywhere MFT.
Preuve que la vulnérabilité est sérieuse et qu'il n'existe pas de patch de sécurité, Fortra a temporairement mis hors ligne sa solution en mode SaaS. Par ailleurs, il est recommandé aux entreprises de vérifier la liste des comptes administrateurs de leur instance, à la recherche d'un éventuel compte suspect.
En exploitant cette faille de sécurité, un attaquant pourrait parvenir à récupérer des documents sensibles partagés au travers d'un serveur GoAnywhere MFT ! Donc, si vous utilisez cette solution, vous devez suivre cette alerte de près...
Le CERT-FR a émis une nouvelle alerte de sécurité au sujet d'une campagne d'attaques par ransomware qui cible les serveurs VMWare ESXi ! Une vulnérabilité déjà connue et déjà corrigée est exploitée par les cybercriminels !
Une nouvelle fois, les hyperviseurs sous VMware ESXi sont dans le viseur des cybercriminels ! Cette fois-ci, les campagnes d'attaques en cours ciblent la vulnérabilité CVE-2021-21974, pour laquelle il existe un patch depuis février 2021.
Il s'agit d'une faille de sécurité qui affecte le service Service Location Protocol (SLP) de VMware ESXi et qui permet à un attaquant d'exécuter du code à distance sur l'hyperviseur. En exploitant cette vulnérabilité, un attaquant peut compromettre le serveur et exécuter un ransomware dans le but de chiffrer les machines virtuelles.
En ce qui concerne les attaques en cours, plusieurs groupes de ransomwares sont évoqués : le groupe de cybercriminels Nevada, qui est relativement nouveau et qui s'attaque aussi aux serveurs Windows, et le groupe Cheers, qui s'en est déjà pris à plusieurs reprises aux serveurs VMware ESXi.
Les serveurs actuellement ciblés tournent sur une version 6.x, antérieure à la version 6.7. Toutefois, le CERT-FR rappelle que cette vulnérabilité s'applique aux versions suivantes de VMware ESXi :
ESXi versions 7.x antérieures à ESXi70U1c-17325551
ESXi versions 6.7.x antérieures à ESXi670-202102401-SG
ESXi versions 6.5.x antérieures à ESXi650-202102101-SG
Comment protéger son hyperviseur VMware ESXi ?
Pour se protéger contre les attaques visant à exploiter la faille CVE-2021-21974, il y a deux options :
Mettre à jour son hyperviseur VMware ESXi vers une version non vulnérable (option à privilégier mais à effectuer avec prudence)
Désactiver le service SLP (OpenSLP) sur un hyperviseur avec une version vulnérable d'ESXi
Pour le second point, vous pouvez lire cette procédure sur le site de VMware puisqu'elle explique comment désactiver ce service. A ce sujet, vous devez tenir compte de cet avertissement mis en ligne par le CERT-FR : "Cette modification empêchera les clients CIM de localiser les serveurs CIM via le service SLP."
Dans ce tutoriel orienté troubleshooting, nous allons apprendre à corriger l'erreur avec le code 0x80040201 qui s'affiche lorsque l'on essaie d'enregistrer la DLL "schmmgmt.dll" sur un serveur Windows Server.
Le message d'erreur complet est le suivant : "Le module "schmmgmt.dll" a été chargé, mais l'appel à DllRegisterServer a échoué avec le code d'erreur 0x80040201". En image cela donne :
Une erreur survenue suite à l'exécution de la commande suivante :
regsvr32 schmmgmt.dll
La commande ci-dessus doit être utilisée pour enregistrée la DLL permettant de bénéficier du composant "Schéma Active Directory" dans la console MMC. Pour rappel, cette console permet de visualiser des informations sur les attributs et classes d'un annuaire Active Directory.
II. Résoudre l'erreur schmmgmt.dll
Cette erreur se produit lorsque l'on exécute cette commande dans une fenêtre "Exécuter" sur un contrôleur de domaine ou un serveur Windows Server. Lors de tests, j'ai eu la mauvaise surprise de constater cette erreur sur un serveur membre.
Dans ce cas, on peut se demander : est-il possible d'avoir la console "Schéma Active Directory" sur un serveur membre ? Comment faire pour utiliser la console "Schéma Active Directory" si l'on utilise des DCs en mode Core ?
La réponse est oui, on peut utiliser cette console sur un serveur membre, aux côtés des autres consoles RSAT liées à l'Active Directory. La subtilité, c'est que cette commande doit être exécutée dans une console, et non dans "Exécuter". Il peut s'agir d'une console PowerShell ou d'une Invite de commandes.
Cette fois-ci, le message "DllRegisterServer dans schmmgmt.dll réussi" apparaît, ce qui est bon signe !
Il ne reste plus qu'à ouvrir une console MMC vierge dans le but d'ajouter le composant "Schéma Active Directory". Ce dernier peut être ajouté en cliquant sur "Fichier" puis "Ajouter/supprimer un composant logiciel enfichable".
Vous voilà soulagé, la console est utilisable dès à présent sur votre serveur. Mais, attention, à utiliser avec précautions compte tenu de l'importance du schéma AD !
Dans ce tutoriel sous Windows Server 2022, nous allons apprendre à configurer DNSSEC de manière à signer les enregistrements de la zone DNS de l'Active Directory.
Pour suivre ce tutoriel, vous avez besoin d'un contrôleur de domaine Active Directory ainsi que d'une machine intégrée au domaine (serveur ou poste de travail) pour effectuer des tests de bon fonctionnement.
II. Qu'est-ce que DNSSEC ?
A. Définition et principes
Directement lié au protocole DNS et aux serveurs DNS, DNSSEC est une extension du DNS orientée sécurité dont l'objectif est de signer les enregistrements DNS d'une zone. De ce fait, cela peut s'appliquer à la zone DNS correspondante au domaine Active Directory.
Grâce à cette couche de sécurité supplémentaire, on peut lutter contre les attaques de type DNS Spoofing (appelée également Cache Poisoning) et Man-in-the-middle. En effet, un attaquant ne pourra pas usurper l'identité de notre serveur DNS car il ne sera pas en mesure de présenter des enregistrements signés. Et s'il le fait, le client DNS comprendra que la réponse n'est pas valide. Sans DNSSEC, il y a toujours un risque que la réponse soit falsifiée (cache DNS avec de mauvaises informations) et que l'on soit redirigé, sans s'en rendre compte, vers un serveur malveillant.
Le serveur DNS de Windows Server supporte DNSSEC et l'implémentation respecte les différentes RFC à ce sujet : RFC 4033, RFC 4034 et RFC 4035.
La signature DNSSEC doit être appliquée sur une zone par un serveur DNS faisant autorité pour le domaine, ce qui est le cas de la zone DNS Active Directory. Ainsi, tous les enregistrements DNS seront signés. Même s'il y a la présence de DNSSEC, le principe du DNS reste le même, à savoir répondre à des requêtes pour de la résolution de noms, mais on ajoute une signature numérique sur les réponses DNS.
B. Terminologie
Lorsque l'on parle de DNSSEC, il y a un ensemble de termes à connaître afin de bien comprendre la configuration qui va suivre et être capable de l'interpréter. Voici les éléments clés.
RRSIG - Resource Record Signature
Enregistrement signé et associé à un enregistrement d'origine (ce que l'on verra dans la console DNS à la fin de la configuration)
NSEC3 - Next Secure 3
Mécanisme pour prouver qu'un enregistrement n'existe pas (on ne retourne pas rien, mais on retourne une réponse négative signée)
DNSKEY - DNS Key
Stocker la clé publique (SHA256) pour permettre la vérification de la signature
DS - Delegation Signer
Créer une délégation sécurisée (chaîne d'authentification sur les zones enfants)
Par ailleurs, il ne faut pas négliger le principe des clés KSK et ZSK :
Clé KSK - Key Signing Key
Clé privée qui sert à signer les clés privées ZSK
Clé ZSK - Zone Signing Key
Clé privée pour signer les données d'une zone
Enfin, point important de la configuration en environnement Active Directory : les points d'approbations (Trust anchors).
Un point d'approbation sert à stocker les enregistrements DNSKEY et DS
Ces informations sont stockées dans l'annuaire Active Directory
À partir de PowerShell, on peut lister cette commande pour lister les serveurs approuvés pour une zone spécifique :
Get-DnsServerTrustAnchor -Name it-connect.local
En complément, vous pouvez lire la documentation Microsoft :
Actuellement, sans la signature DNSSEC, ma zone de recherche directe DNS ressemble à ceci :
Je souhaite vous montrer la zone avant la mise en place de DNSSEC car vous verrez, qu'après avoir effectué la configuration, la zone se présentera différemment.
Désormais, passons à la configuration de DNSSEC sur la zone Active Directory "it-connect.local". Cette configuration s'effectue à partir de la console DNS.
Depuis Windows Server 2016, DNSSEC est activé par défaut, mais les zones ne sont pas signées : une action à réaliser manuellement. Si l'on regarde les propriétés du serveur DNS, dans l'onglet "Avancé", il n'y a pas d'options DNSSEC dans les "Options de serveur". Auparavant il y avait une option ici. Si l'on regarde avec PowerShell, on peut voir que DNSSEC est bien actif.
(Get-DnsServerSetting).EnableDnsSec
Pour configurer DNSSEC sur la zone "it-connect.local", on effectue un clic droit sur la zone puis sous "DNSSEC", on clique sur "Signer la zone".
Un assistant s'exécute. On passe la première étape.
Afin de pouvoir créer les points d'approbations en même temps que la configuration, on choisit l'option "Personnalisez les paramètres de signature de zone".
Il faut commencer par déterminer un serveur qui est maître des clés, un peu sur le même principe qu'il y a un maître pour les rôles FSMO de l'Active Directory. Par défaut, c'est le serveur actuel qui est proposé, mais il est possible de changer.
Ensuite, lisez l'explication au sujet de la clé KSK et poursuivez.
Cliquez sur le bouton "Ajouter" pour créer une nouvelle clé KSK. Nous allons générer une nouvelle clé SHA-256 de longueur 2048 bits (configuration par défaut). Cliquez sur "OK".
La clé est créée, poursuivez.
Désormais, c'est la clé ZSK qui doit être créée. Lisez l'explication et continuez.
Cliquez sur "Ajouter" pour créer une clé puis sur le bouton "OK".
En ce qui concerne les réponses négatives signées, nous allons utiliser NSEC3 qui est plus sécurisé que NSEC. Choisissez bien cette version.
Cochez les deux options, notamment celle nommée "Activer la distribution des ancres d'approbation pour cette zone" puisque nous sommes sur un environnement Active Directory. Sinon, il faudra le faire manuellement par la suite. Poursuivez.
Terminons par les paramètres de signature que l'on peut laisser par défaut également.
C'est presque terminé, il ne reste plus qu'à cliquer sur "Suivant" !
Voilà, la zone a été correctement signée par DNSSEC !
Pour voir le résultat, il faut rafraîchir la console DNS et là on voit que les enregistrements sont désormais de type "RRSIG" car ils sont signés !
À partir de maintenant, on peut tester que la signature fonctionne en utilisant PowerShell pour interroger le serveur DNS. La commande Resolve-DnsName intègre un paramètre nommé "-DnsSecOk" qui permet d'exiger une réponse signée. Voici un exemple pour résoudre le nom "srv-apps.it-connect.local" via DNSSEC :
Bien que la réponse du DNS soit signée par DNSSEC, on parvient à lire la réponse retournée.
Remarque : si vous disposez de plusieurs contrôleurs de domaine avec le rôle de serveurs DNS, les enregistrements signés seront répliqués avec les autres serveurs. La zone apparaitra signée une fois que la réplication sera effectuée, ce qui signifie qu'il ne faut pas signer la zone sur chaque DNS !
IV. GPO DNSSEC pour les machines
Par défaut, Windows accepte les réponses DNS non signées pour l'ensemble des domaines. C'est logique, mais ce n'est pas réellement une bonne nouvelle par rapport à la configuration que l'on vient d'effectuer. Cela signifie que les machines sont en mesure d'accepter une réponse non signée... Pour changer ce comportement et forcer DNSSEC pour le domaine "it-connect.local", une GPO doit être déployée.
On va commencer par ouvrir la console de gestion des stratégies de groupe. Au sein de celle-ci, on va créer une nouvelle GPO. Dans cet exemple, elle se nomme "Sécurité - DNSSEC".
Il faut éditer cette GPO et parcourir les paramètres comme ceci :
Configuration ordinateur > Stratégies > Paramètres Windows > Stratégie de résolution de noms
Vous arrivez sur l'interface suivante :
Au sein de celle-ci, il va falloir créer une nouvelle règle. Sous "À quelle partie de l'espace de noms s'applique cette règle ?", il faut choisir "Suffixe" (1) et indiquer "it-connect.local" qui correspond au domaine Active Directory. Puis, l'option "Activer DNSSEC dans cette règle" doit être cochée ainsi que "Demander aux clients DNS de vérifier que les données de nom et d'adresse ont été validées par le serveur DNS" (2). Cliquez sur le bouton "Créer" (3).
La règle apparaît dans la "Table de stratégie de résolution de noms". Cliquez sur "Appliquer".
La GPO est prête, il ne reste plus qu'à créer une liaison pour l'appliquer aux machines du domaine Active Directory. Ainsi, toutes les machines du domaine chercheront à résoudre les hôtes de la zone "it-connect.local" uniquement via DNSSEC.
Pour tester, il faut exécuter la même commande que l'on a vu précédemment, mais sans le paramètre "-DnsSecOk" puisque Windows doit comprendre (grâce à la GPO, une fois appliquée) qu'il doit obtenir des réponses signées pour cette zone.
Resolve-DnsName -Name srv-apps.it-connect.local
Cela se confirme par le fait que la stratégie est bien appliquée. La commande ci-dessous permet de s'en assurer.
Get-DnsClientNrptPolicy -Effective
V. Conclusion
Nous venons de voir comment activer DNSSEC sur une zone DNS gérée par un serveur Windows ! Toutefois, le DNSSEC est un mécanisme que l'on peut activer sur d'autres types d'environnement, notamment sur les noms de domaine utilisés pour le Web.
Je termine cet article en vous orientant vers un article très détaillé, disponible sur le site Microsoft, pour la mise en œuvre d'un Lab DNSSEC.
En début de semaine, le fabricant QNAP a corrigé une faille de sécurité critique qui affecte ses NAS ! Les utilisateurs sont invités à installer la mise à jour en urgence. Faisons le point !
Associée à la référence CVE-2022-27596, cette faille de sécurité critique hérite d'un score CVSS de 9,8 sur 10 ! De type injection SQL, les pirates peuvent exploiter cette vulnérabilité à distance sur les NAS QNAP exposés sur Internet et non à jour ! D'après les détails techniques mis en ligne, cette faille de sécurité serait assez facile à exploiter et elle ne nécessite ni d'action de la part d'un utilisateur, ni d'être authentifié sur le NAS.
Quels sont les NAS QNAP vulnérables à la CVE-2022-27596 ?
Au sein du bulletin de sécurité de QNAP, on peut lire : "Une vulnérabilité a été signalée sur les appareils QNAP exécutant QTS 5.0.1 et QuTS hero h5.0.1. Si elle est exploitée, cette vulnérabilité permet à des attaquants distants d'injecter du code malveillant." - Ce n'est donc pas une question de modèles, mais de version de système.
Pour se protéger, les utilisateurs doivent installer une version patchée, à savoir à minima :
QTS 5.0.1.2234 build 20221201
QuTS hero h5.0.1.2248 build 20221215
Des dizaines de milliers de NAS QNAP vulnérables
Suite à la découverte de cette vulnérabilité, les chercheurs en sécurité de Censys ont mis en ligne un rapport révélant qu'il y avait plusieurs dizaines de milliers de NAS QNAP vulnérables à la CVE-2022-27596.
Censys a analysé 67 415 NAS QNAP, et sur ce total, il a été possible d'obtenir le numéro de version du système sur 30 520 appareils. Sur ce total de 30 520 appareils, il y en a seulement 557 qui sont protégés contre cette faille de sécurité. Autrement dit, il y a plus de 29 000 NAS QNAP exposés sur Internet et vulnérables à la CVE-2022-27596 !
Les NAS, et en particulier ceux de QNAP, sont régulièrement pris pour cible dans le cadre de campagnes d'attaques par ransomware. Il est clair que cette vulnérabilité représente une nouvelle opportunité pour les cybercriminels, donc si vous avez un NAS QNAP exposé sur Internet, n'attendez pas avant d'effectuer la mise à jour. Même si pour le moment, QNAP estime que cette vulnérabilité n'est pas activement exploitée.
Si vous ne pouvez pas appliquer la mise à jour, faites en sorte que votre NAS ne soit pas accessible depuis Internet (pas d'UPNP, ni de règle de redirection de ports).
