Microsoft a découvert deux nouvelles vulnérabilités qui permettent une élévation de privilèges sur de nombreuses distributions Linux avec un environnement desktop. Cet ensemble de vulnérabilité a déjà son petit nom : Nimbuspwn.
D'après Jonathan Bar Or de l'équipe de recherche Microsoft 365 Defender, les vulnérabilités Nimbuspwn, associées aux références CVE-2022-29799 et CVE-2022-29800, "peuvent être enchaînées pour obtenir les privilèges root sur les systèmes Linux, ce qui permet aux attaquants de déployer des charges malveillantes, comme une backdoor root, et d'effectuer d'autres actions malveillantes via une exécution arbitraire de code en tant que root". Au final, l'exploitation de ces vulnérabilités peut permettre à un attaquant de déployer un ransomware sur la machine compromise.
Ces deux vulnérabilités sont situées dans un composant de Systemd nommé "Networkd-dispatcher", directement lié à la gestion du réseau sur une machine Linux afin de gérer les changements d'état d'une connexion réseau. Par exemple, il est capable d'exécuter un script sur un changement d'état du réseau. Le fait que ces vulnérabilités permettent de devenir "root", c'est probablement lié au fait que ce processus (daemon) démarre en tant que "root" au démarrage du système.
Ces deux vulnérabilités (CVE-2022-29799 et CVE-2022-29800) sont une combinaison de plusieurs techniques : directory transversal, symlink race, et time-of-check to time-of-use (TOCTOU) utilisables dans un scénario, où un attaquant contrôle un service D-Bus malveillant. Dans son rapport, Microsoft précise que sur les environnements de bureau Linux, il y a de nombreux composants D-Bus intégrés nativement.
Les utilisateurs de "Networkd-dispatcher" doivent mettre à jour leurs machines Linux dès que possible afin d'être protégés contre ces deux vulnérabilités. À en croire l'article de Microsoft, ces vulnérabilités touchent les environnements Linux avec une interface graphique. Les environnements "Serveur" en mode console, ne sont pas évoqués, et Microsoft ne donne pas d'exemple de distribution ou configuration vulnérable.
Le rapport complet publié sur le site de Microsoft est disponible ici, et il intègre notamment des informations sur les possibilités d'exploitation via un composant D-Bus.
Dans ce tutoriel, nous allons voir qu'il est possible d'activer le SSO (authentification unique) pour OneDrive sur Windows, afin que OneDrive se configure automatiquement et qu'il soit prêt à être utilisé sans aucune intervention de la part de l'utilisateur final ! Grâce à cette configuration et au SSO, on simplifie la vie des utilisateurs. Autrement dit, l'utilisateur ouvre sa session Windows, via son compte Active Directory, et OneDrive est automatiquement connecté et configuré !
Précédemment, et c'est un prérequis pour suivre ce tutoriel, nous avons vu comment mettre en place le SSO dans un environnement où il y a un Active Directory, Azure AD Connect et Office 365.
Pour suivre ce tutoriel, vous avez également besoin d'intégrer les modèles d'administration (ADMX) de OneDrive au sein de votre Active Directory. Pour cela, suivez ce tutoriel :
II. Activer l'authentification unique OneDrive par GPO
Contrairement à la GPO configurée dans le cadre du tutoriel sur la mise en place du SSO, ici nous allons configurer des paramètres qui s'appliquent au niveau de l'ordinateur. Pour ma part, je crée une nouvelle GPO "O365 - SSO - OneDrive" sur mon environnement Active Directory et je crée une liaison avec l'OU "PC".
Une fois que la GPO est créée, nous devons parcourir les paramètres de cette façon :
Ici, il y a un paramètre nommé "Connecter silencieusement les utilisateurs à l'application de synchronisation OneDrive avec leurs informations d'identification Windows".
Nous devons l'activer, comme ceci :
Aussi surprenant que cela puisse paramètre, c'est tout ! Avec ce simple paramètre, on active le SSO (authentification unique) avec OneDrive ! Néanmoins, nous allons voir dans la suite de ce tutoriel que c'est préférable d'aller un peu plus loin dans la configuration de OneDrive.
III. Affiner la configuration de OneDrive par GPO
La GPO OneDrive mérite d'être affinée, car actuellement, un utilisateur sera authentifié sur OneDrive automatiquement et donc OneDrive va être actif. Ce qui signifie que OneDrive sera en place avec une configuration par défaut, et que l'utilisateur peut bricoler la configuration du client OneDrive. Personnellement, je pense que c'est mieux d'aller un peu plus loin pour garder la maîtrise de OneDrive. Par exemple pour :
Activer la fonctionnalité de "Fichiers à la demande" pour éviter de tout synchroniser en local et surcharger l'espace disque local
Contrôler la bande passante que peut utiliser le client OneDrive
Activer / désactiver la redirection de Bureau, Documents et Images dans OneDrive
Autoriser uniquement la synchronisation du compte de votre entreprise
Etc...
Regardons quelques paramètres à titre d'exemple... Toujours au même endroit que précédemment.
A. Autoriser uniquement la synchronisation sur certains tenants
Le paramètre "Autoriser la synchronisation des comptes OneDrive uniquement pour des organisations spécifiques" vous permettre d'être sûr que vos utilisateurs ne vont pas synchroniser d'autres OneDrive sur leur machine. Par exemple, le OneDrive d'un compte personnel ou d'un autre tenant. Pour cela, il faut cliquer sur "Activé" (1), puis sur le bouton "Afficher" (2), afin d'ajouter l'ID de votre tenant (3) avant de valider (4). Vous pouvez ajouter plusieurs ID de tenant, ce qui est plutôt bien.
Vous allez me dire : "où est-ce que je récupère l'ID du tenant ?". Bonne question. En fait, il faut se connecter sur le portail Azure Active Directory et regarder dans la vue d'ensemble afin de récupérer la valeur "ID du client". Voici un exemple :
En activant ce paramètre, si un utilisateur essaie d'ajouter un compte qui n'appartient pas à un tenant autorisé, le message suivant apparaît :
B. Gérer les dossiers connus OneDrive
Dans le même esprit, on peut empêcher les utilisateurs de déplacer les dossiers Bureau, Documents et Images vers OneDrive. À ce niveau, tout dépend de la politique de votre entreprise, et disons que pour une école, cela peut être pertinent pour les étudiants. Si vous désirez bloquer cette fonctionnalité, activez le paramètre "Empêcher les utilisateurs de déplacer leurs dossiers connus de Windows vers OneDrive". Ensuite, vous devez choisir si vous souhaitez garder la redirection sur OneDrive ou non pour les utilisateurs qui ont déjà appliqué cette configuration.
Par défaut, la redirection des dossiers connus vers OneDrive n'est pas activée, mais l'utilisateur peut l'activer si vous ne gérez pas cette fonctionnalité, alors méfiance !
Lorsque ce paramètre est appliqué, on peut voir que l'utilisateur ne peut plus gérer cette fonctionnalité, et un message d'avertissement s'affiche.
Voilà pour les exemples pour affiner la configuration de OneDrive par GPO. Pour finir, nous allons tester le SSO afin de voir si notre configuration fonctionne !
IV. Tester le SSO OneDrive
Pour tester le SSO, c'est tout simple puisqu'il suffit de se connecter sur un ordinateur du domaine sur lequel s'applique la GPO. Pour ma part, la configuration fonctionne parfaitement : à peine la session ouverte, le OneDrive de mon utilisateur s'est connecté et initialisé sans aucune action de ma part, donnant lieu à la notification suivante :
Si j'accède au OneDrive de cet utilisateur via l'Explorateur de fichiers, je peux visualiser les données ! - Ainsi, il est possible d'accéder aux données existantes ou de charger facilement de nouvelles données sur son espace de stockage OneDrive.
Nous venons de voir comment configurer le SSO OneDrive par GPO, mais n'oubliez pas de configurer correctement le SSO au niveau d'Azure AD Connect.
Le géant Coca-Cola serait-il victime d'une attaque informatique ? Voilà, une question à laquelle l'entreprise américaine souhaite apporter une réponse, puisque des pirates informatiques affirment qu'ils ont compromis l'infrastructure Coca-Cola et qu'ils ont pu exfiltrer 161 Go de données.
Les pirates informatiques du gang Stormous ont mis en ligne un message au sein duquel ils affirment qu'ils ont compromis les serveurs de Coca-Cola, et qu'ils ont pu mettre la main sur 161 Go de données informatiques. Pour acheter ces données, il faut débourser la somme de 1,65 bitcoin, ce qui correspond à environ 36 000 euros.
Au sein de cet ensemble de données, il y aurait des documents administratifs, des fichiers textes avec des identifiants et mots de passe, ainsi que des informations sur les comptes bancaires et les paiements de l'entreprise Coca-Cola.
Serait-on sur le point de connaître la recette magique de cette fameuse boisson ? Et bien, certainement que non, elle doit être beaucoup mieux gardée que dans un simple fichier Excel !
Qui se cache derrière le gang Stormous ?
Pour le moment, dans le cadre de l'attaque de l'infrastructure de Coca-Cola, les pirates ne parlent pas de l'utilisation d'un ransomware, alors que pourtant ils sont plutôt habitués à réaliser des attaques de ce type. En fait, c'est la première fois que le gang Stormous met en vente des données sur le Dark Web.
La semaine dernière, ils ont demandé à leur follower de voter pour déterminer quelle serait la prochaine victime. Suite à ce sondage, c'est Coca-Cola qui est arrivé en tête avec 72% des voix. Ensuite, ils affirment que, en quelques jours, ils ont pu compromettre l'infrastructure de Coca-Cola, même si l'on peut considérer que cela reste à vérifier pour le moment car on ne connait pas l'origine exacte des données publiées.
Le gang Stormous est à l'origine d'autres cyberattaques et dans la liste des victimes, il y a Epic Games, où ils ont mis la main sur 200 Go de données et les informations sur 33 millions d'utilisateurs.
Dans ce tutoriel, nous allons voir comment ajouter un certificat Let's Encrypt sur un NAS Synology sous DSM 7 en utilisant le service Synology DDNS ("synology.me"). Dans le cas où votre NAS Synology est accessible de l'extérieur par différents utilisateurs et que vous souhaitez éviter d'avoir l'avertissement de sécurité à cause du certificat Synology par défaut qui n'est pas reconnu, alors Let's Encrypt représente une solution gratuite à cette problématique.
Pour passer au HTTPS avec un certificat SSL sur un NAS Synology, il y a plusieurs possibilités :
Autorité de certification d'entreprise (type ADCS) : généré directement par vos soins (un CSR peut-être généré sur DSM)
Pour cette démo, je vais utiliser un Synology DS220+ sous DSM 7, et le certificat Let's Encrypt sera positionné sur un domaine "synology.me" via le système DDNS Synology, et non sur un nom de domaine personnalisé, même si cela reste possible.
Note : je vous rappelle que le système DDNS correspond au "DNS Dynamique", c'est-à-dire que l'enregistrement DNS est mis à jour automatiquement si l'adresse IP associée à l'enregistrement venait à changer. Par exemple, si vous utilisez un DDNS sur votre box ou sur un NAS, et que votre box change d'adresse IP publique, l'enregistrement DDNS se mettra à jour automatiquement pour prendre la nouvelle adresse IP publique. Ainsi, le nom de domaine DDNS continue de fonctionner, car il résout toujours vers la bonne adresse IP publique, même si elle change.
II. Dans quels cas utiliser Let's Encrypt sur un NAS Synology ?
À mon avis, l'installation d'un certificat SSL Let's Encrypt sur un NAS Synology ne doit pas être systématique, d'autant plus si vous envisagez d'utiliser un domaine personnalisé. Vous allez me dire : pourquoi ?
En fait, le certificat SSL Let's Encrypt est valide uniquement 90 jours, donc il doit être renouvelé assez fréquemment en comparaison d'un certificat SSL "classique" qui peut être valide 1 an (ou plus). Donc, même si ce renouvellement est automatique, il n'est pas sans contrainte ! En effet, pour le renouvellement du certificat, le NAS Synology doit être joignable depuis Internet (sur le port 80) par les serveurs correspondants à l'autorité de certification Let's Encrypt sinon l'opération échouera.
Dans le cas où le NAS n'a pas d'intérêt à être joignable sur Internet, je trouve que c'est dommage de l'exposer uniquement pour une histoire de renouvellement de certificat via Let's Encrypt. Cependant, cette contrainte s'applique uniquement dans le cas où vous utilisez un domaine personnalisé (mon-domaine.fr, par exemple) et non avec le DDNS Synology, c'est-à-dire avec une adresse telle que "mon-nas.synology.me" (d'autres extensions sont possibles).
Note - Dans sa documentation, Synology précise : "Pour renouveler un certificat Let's Encrypt d'un domaine personnalisé, veuillez vous assurer que le port 80 a été transmis à votre Synology NAS. Synology DDNS n'a pas cette limitation." Avec "synology.me", pas besoin de mettre en place une ouverture de ports pour renouveler le certificat, ce qui est appréciable !
Prenons deux cas concrets :
Un NAS Synology connecté au réseau d'une entreprise dont l'objectif est de stocker les sauvegardes des serveurs : il n'y a pas d'intérêt à mettre en place un certificat SSL Let's Encrypt, d'autant plus que ce NAS n'aura peut-être pas un accès constant à Internet
Un NAS Synology utilisé à la maison pour stocker les données de la famille, et qui doit être accessible depuis des ordinateurs, des smartphones, etc... : il peut y avoir un intérêt pour éviter les erreurs de certificat lors de la connexion à DSM et d'autres applications, notamment s'il y a des accès nécessaires en dehors de la maison (sans passer par un VPN)
Pour conclure, on pourrait dire que pour un NAS lié à l'infrastructure IT d'une entreprise, ce n'est pas nécessaire (ou alors un autre type de certificat), mais pour un NAS utilisé par des utilisateurs finaux (ou la famille), cela à tout son sens d'utiliser un certificat SSL (Let's Encrypt ou autre). En fait, cela peut perturber les utilisateurs d'avoir un avertissement lié au certificat, d'autant plus qu'on essaie de les éduquer à faire attention et se méfier de ce type d'alertes donc il vaut mieux rester cohérent.
III. Configuration de Let's Encrypt avec Synology DDNS
A. Choisir le nom Synology DDNS
Le service DDNS de Synology est gratuit et permet de choisir un sous-domaine de "synology.me" (ou d'un autre sous-domaine, car Synology en propose plusieurs), par exemple "fb-caen.synology.me" que je vais utiliser dans ce tutoriel. Tout d'abord, il faut se connecter à l'interface de DSM, ouvrir le "Panneau de configuration", cliquer sur "Accès externe" à gauche (1), puis sur l'onglet "DDNS" (2). Ensuite, il faut cliquer sur le bouton "Ajouter" (3) pour ajouter un nom de domaine DDNS sur son NAS.
Pour remplir ce formulaire, suivez les instructions suivantes :
1 - Fournisseur de service : choisissez le service "Synology" pour utiliser "synology.me" ou un autre domaine (choix dans la liste déroulante en dessous).
2 - Nom d'hôte : indiquez le sous-domaine que vous souhaitez utiliser, en précisant "fb-caen" avec le domaine "synology.me", mon NAS sera accessible via l'adresse "fb-caen.synology.me".
3 - Obtenez un certificat auprès de Let's Encrypt et définissez-le comme certificat par défaut : cochez cette option pour obtenir un certificat SSL Let's Encrypt pour ce nom de domaine.
4 - Activer Hearbeat : cochez cette option pour recevoir une notification en cas de perte de connexion sur votre NAS
Avant de continuer, vous pouvez cliquer sur le bouton "Test de connexion" pour tester la connectivité et vérifier que le test retourne bien "Normal" comme statut. Enfin, cliquez sur "OK".
Ici, un avertissement s'affiche pour vous indiquer que le certificat sera utilisé par défaut sur le NAS. En fait, si vous utilisez le FTPS, c'est-à-dire le FTP sécurisé par un certificat, ce sera ce nouveau certificat qui sera utilisé donc l'accès peut-être perturbé temporairement. Par la suite, nous verrons que l'on peut choisir un certificat différent pour chaque service du DSM afin d'éliminer cette contrainte. Pour continuer, cliquez sur "OK".
Pendant la configuration (enregistrement du nom de domaine et obtention du certificat), patientez... De mon côté, cette opération a duré environ 1 minute, mais cela peut être un peu plus long. Sachez également que le serveur Web va redémarrer à la fin du processus, donc une petite interruption de service est à prévoir.
B. Vérifier l'état DDNS et le certificat SSL
Puisque la configuration est terminée, nous devrions avoir notre certificat SSL Let's Encrypt sur notre NAS ! Afin de le vérifier, ouvrez le "Panneau de configuration", cliquez sur "Sécurité" puis sur l'onglet "Certificat". Comme le montre l'exemple ci-dessous, le certificat pour "fb-caen.synology.me" est bien là et valide pour une durée de trois mois (jusqu'au 12/07/2022). En complément, nous pouvons voir que le certificat est utilisé pour "FTPS, Synology Storage Console Server, VPN Server, etc...", mais c'est personnalisable.
Afin de déterminer quel est le certificat que vous souhaitez utiliser pour chaque service, il suffit de cliquer sur le bouton "Paramètres" de l'onglet "Certificat" pour ensuite choisir le certificat. Pour rappel, le certificat par défaut est "Synology".
Remarque : Si vous utilisez Synology Drive Server, et que vous changez le certificat associé, alors il faudra revalider la connexion sur les clients Synology Drive.
Enfin, avant de passer à la suite, si vous accédez au "Panneau de configuration", puis "Accès externe" et ensuite à "DDNS", vous devez voir votre nom de domaine DDNS avec le statut "Normal". Désormais, nous allons regarder ce qu'il se passe dans le navigateur : le certificat est-il reconnu ?
La réponse est oui ! Donc, pour le vérifier il suffit d'ouvrir un navigateur puis de se connecter à l'adresse "https://fb-caen.synology.me:<port DSM>" et de constater qu'il n'y a plus d'erreur liée au certificat. En complément, on peut voir le cadenas, et si l'on regarde les détails on voit la date de validité du certificat et qui l'a délivré, en l'occurrence ici "Let's Encrypt".
Voilà, félicitations ! Le certificat SSL Let's Encrypt est en place sur le NAS ! Avant de se quitter, j'ai encore quelques informations à partager avec vous...
IV. Synology DDNS : résolution locale et ouverture de ports
Certains d'entre vous ont probablement constaté que je n'ai pas parlé de la nécessité d'effectuer une ouverture de ports sur la Box (routeur) pour que le NAS Synology soit joignable depuis l'extérieur. Même si j'en ai déjà parlé, j'insiste sur le fait qu'avec le DDNS Synology, il n'est pas nécessaire d'exposer son NAS sur Internet pour obtenir un certificat, ce qui est un gros avantage ! En fait, Synology doit jouer le rôle d'intermédiaire avec Let's Encrypt afin de permettre l'obtention du certificat malgré tout.
Néanmoins, si vous mettez en place le DDNS c'est probablement pour vous connecter à distance à votre NAS. Donc, il sera indispensable de créer une règle de redirection de port sur votre box/routeur afin de rediriger les flux vers le NAS. Dans l'exemple ci-dessous, j'utilise le port "14000", car mon DSM est accessible en HTTPS sur le port 14000, et l'adresse IP du NAS est "192.168.1.149". Grâce à cette règle, je peux accéder à mon NAS même sans être à la maison.
Cette ouverture de port sera également une réponse à une problématique : la résolution locale de l'adresse "synology.me" ! Bien que dans ce cas, il n'y ait pas de réponse magique, car cela dépend de votre routeur/box... En effet, dans certains cas l'accès à votre NAS via l'adresse "synology.me" ne fonctionnera pas depuis une machine connectée sur le même réseau que votre NAS.
Ce blocage est lié à un problème de NAT loopback qui ne fonctionne pas sur certaines box ou routeur ! Pour contourner cette limitation, il y a plusieurs solutions :
Créer une règle de NAT comme celle ci-dessus pour ouvrir le flux (fonctionne pour l'accès local et l'accès distant) sur votre routeur : la solution dans mon cas
Créer une entrée dans votre serveur DNS que vous utilisez sur cette connexion pour associer "fb-caen.synology.me" à l'adresse IP "192.168.1.149"
En entreprise, cela s'annonce particulièrement facile s'il y a un serveur DNS local, lié à un Active Directory, par exemple
À la maison, vous pouvez monter un serveur DNS local sur le NAS Synology
Autoriser le NAT loopback sur votre routeur/box, car certains modèles permettent d'activer la fonctionnalité
Si vraiment vous ne parvenez pas à trouver une solution, postez un commentaire sur cet article
Si vous êtes amateur de matériel Synology, il faut savoir que le NAT loopback fonctionne très bien avec les routeurs Synology. Voilà, j'en ai fini avec mes fameuses informations supplémentaires à partager avec vous ! Pour en savoir plus sur les certificats sur un NAS Synology, et en attendant d'éventuels articles supplémentaires sur le sujet, voici un lien vers la documentation Synology.
Des chercheurs en sécurité ont découvert une faille de sécurité au sein du site VirusTotal, permettant à un attaquant d'exécuter du code à distance et d'interagir avec plusieurs dizaines de serveurs.
Pour rappel, VirusTotal est un service en ligne qui permet d'analyser des fichiers ou des URL à la recherche de logiciels malveillants, en s'appuyant sur plus de 70 moteurs antivirus différents. VirusTotal appartient à Google.
Les chercheurs en sécurité Shai Alfasi et Marlon Fabiano da Silva de l'entreprise Cysource ont fait la découverte de cette vulnérabilité qui est désormais corrigée depuis le 13 avril 2022. Elle est associée à la référence CVE-2021-22204 et bénéficie d'un score CVSS de 7,8 sur 10.
L'attaque consiste à charger un fichier DjVu sur l'interface VirusTotal, dans le but de cibler un exploit présent au sein de l'outil ExifTool sur lequel s'appuie la plateforme. En fait, ExifTool est un outil open source qui permet de lire et d'éditer les métadonnées des fichiers, notamment les images et les PDF.
D'après les chercheurs, en exploitant cette vulnérabilité, il est possible d'obtenir un accès sur un environnement contrôlé par Google, mais aussi à plus de 50 hôtes internes avec des privilèges élevés !
Voici ce qu'ils précisent : "La partie intéressante, c'est que chaque fois que nous avons téléchargé un fichier avec un nouveau hachage contenant une nouvelle charge malveillante, VirusTotal a transmis la charge utile à d'autres hôtes. [...] Donc, non seulement nous avions une faille RCE, mais elle était également transférée par les serveurs de Google vers le réseau interne de Google, ses clients et ses partenaires.". Le rapport complet est disponible sur le site de Cysource.
Ce n'est pas la première fois qu'une faille de sécurité dans ExifTool impacte une plateforme importante. En effet, l'année dernière c'est la plateforme GitLab qui a fait les frais d'une vulnérabilité dans ExifTool avec la CVE-2021-22205, associée à un score CVSS de 10.
