Les développeurs de KeePass ont mis en ligne une nouvelle version du gestionnaire de mots de passe : KeePass 2.53.1. Cette version corrige la vulnérabilité CVE-2023-24055, qui a fait couler beaucoup d'encre ces dernières semaines...

Pour rappel, la CVE-2023-24055 est associée à un bug de sécurité permettant à un attaquant de récupérer en clair les mots de passe d'une base KeePass en abusant de la fonction d'exportation des mots de passe. Un problème présent dans toutes les versions 2.5X de KeePass, y compris la version 2.53 qui était la plus récente jusqu'à la sortie de cette nouvelle mouture.

Rapidement, cette faille de sécurité a été associée au statut "Disputed" sur le site du NIST car l'éditeur KeePass estime que la base de données de mots de passe n'est pas censée être protégée contre un attaquant disposant déjà d'un accès local sur un PC. Mais bon, je ne vais pas relancer le débat...

Au final, les développeurs ont tenu compte du mécontentement de nombreux utilisateurs et ils ont fait le nécessaire dans cette nouvelle version. C'est probablement la meilleure solution pour rassurer tout le monde, mais aussi avoir un meilleur niveau de sécurité par défaut.

Dans le changelog de KeePass 2.53.1, on peut lire : "Removed the 'Export - No Key Repeat' application policy flag; KeePass now always asks for the current master key when trying to export data." - Cela implique qu'avec KeePass 2.53.1, il est obligatoire de disposer du mot de passe maître de la base KeePass afin de pouvoir exporter les données. Même si ce n'est pas le seul changement apporté à cette version, c'est clairement le changement majeur (voir en bas de cette page) !

Pour télécharger cette nouvelle version, suivez le lien suivant qui donne un accès direct à l'exécutable :

• KeePass 2.53.1

Bien sûr, je vous recommande d'appliquer cette mise à jour si vous êtes utilisateur de l'excellent KeePass !

Source

L'article KeePass 2.53.1, une nouvelle version qui corrige « la vulnérabilité » CVE-2023-24055 est disponible sur IT-Connect : IT-Connect.

Il fallait s'y attendre : les cybercriminels ont mis au point une nouvelle version du ransomware ESXiArgs pour qu'il soit impossible de récupérer les fichiers des machines virtuelles ! Faisons le point.

Hier, j'ai mis en ligne un article intitulé "Victime du ransomware ESXiArgs ? La CISA a mis en ligne un script de récupération !" : preuve que les cybercriminels sont réactifs, la méthode évoquée dans cet article est déjà obsolète.

Pour rappel, le ransomware ESXiArgs est impliqué dans une campagne d'attaques à grande échelle dans l'objectif de chiffrer les machines virtuelles d'hyperviseurs VMware ESXi. Même s'il a déjà fait plusieurs milliers de victimes, une méthode de récupération de données a rapidement vu le jour grâce au fait que le ransomware ne parvenait pas à chiffrer certains fichiers.

Ransomware ESXiArgs : une nouvelle version plus efficace

Sur un hôte infecté, le script "encrypt.sh" est présent et il recherche la présence de fichiers associés aux machines virtuelles, notamment avec les extensions suivantes : vmdk, vmx, vmxf, vmsd, nvram, etc.... Dans le but de chiffrer les VMs de l'hyperviseur.

Les pirates ont mis au point une nouvelle version du ransomware ESXiArgs dans le but d'améliorer le processus de chiffrement, notamment pour chiffrer correctement les fichiers volumineux (ce qui était le défaut de la première version).

Plus précisément, c'est la fonction "size_step" qui a été mise à jour de manière à chiffrer 50% des fichiers dont la taille est supérieure à 128 Mo, ce qui rend la récupération impossible. Ainsi les fichiers "-flat" utilisés pour récupérer les données jusqu'ici ne sont plus utilisables ! Autrement dit, la méthode de récupération qui a inspirée le script de la CISA devient inopérante.

Toutefois, gardez à l'esprit que le script de récupération peut fonctionner sur un serveur compromis à l'aide de la première version du ransomware ESXiArgs.

Des serveurs compromis même avec le service SLP désactivé ?

Au sein de cette nouvelle version, il y a un détail inquiétant : un administrateur affirme que son serveur a été compromis alors que le service SLP était bien désactivé sur son hôte VMware. Il affirme également que la backdoor "vmtool.py", vu lors de précédentes attaques, n'était pas présente sur l'hôte.

De ce fait, puisque le service SLP était désactivé, il est difficile de comprendre comment ce serveur a été compromis.... À moins que les cybercriminels exploitent une autre vulnérabilité.

A suivre...

Source

L'article Ransomware ESXiArgs : une nouvelle version empêche la récupération de VMs ! est disponible sur IT-Connect : IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à configurer un serveur Windows Server pour que les utilisateurs lambda ne puissent pas ouvrir de sessions en local sur le serveur.

Même s'il faut des autorisations spécifiques pour se connecter en RDP sur un serveur via le client Bureau à distance, ce n'est pas le cas avec les ouvertures de session en local. Ainsi, un utilisateur devant la console d'un serveur peut ouvrir sa session, y compris s'il n'est pas administrateur du serveur : même s'il y a peu de chance que l'occasion se présente, mieux vaut anticiper et retirer cette autorisation !

Par défaut, Microsoft précise que les autorisations sont les suivantes :

• Sur les stations de travail et les serveurs : Administrateurs, Opérateurs de sauvegarde, Utilisateurs avec pouvoir, Utilisateurs et Invité.
• Sur les contrôleurs de domaine : Opérateurs de compte, Administrateurs, Opérateurs de sauvegarde et Opérateurs d’impression.

Grâce à une GPO, nous allons remédier à cette problématique en retirant ce privilège aux utilisateurs authentifiés du domaine Active Directory.

II. Restreindre la connexion sur les serveurs

Tout d'abord, avant de mettre en place la restriction, constatons que l'utilisateur "Guy Mauve" parvient à se connecter à un serveur en local. Pourtant, il n'est pas administrateur du serveur, ni même administrateur du domaine. Dans cet exemple, la connexion est initialisée à partir de la console de gestion de l'hyperviseur.

Pour modifier cette autorisation, nous allons créer une GPO. Pour ma part, elle se nomme "Sécurité - Restreindre ouverture de sessions" et elle s'applique sur l'OU "Serveurs" de mon Active Directory. Au sein de cette GPO, il faut éditer le paramètre "Permettre l'ouverture d'une session locale" qui se situe à cet emplacement :

Configuration ordinateur > Stratégies > Paramètres Windows > Stratégies locales > Attributions des droits utilisateur

Nous allons définir ce paramètre en cochant l'option "Définir ces paramètres de stratégie". Puis, il faut ajouter les différents groupes que vous souhaitez autoriser à se connecter. A minima, il convient d'ajouter "Administrateurs", ainsi que les autres groupes de votre choix.

Voilà, la GPO est prête !

Après avoir appliqué cette GPO sur le serveur grâce à un "gpupdate /force", nous pouvons essayer d'ouvrir une session avec un utilisateur "lambda" tel que "Guy Mauve". Cette fois-ci, la session ne s'ouvre pas et le message suivant s'affiche : "La méthode de connexion que vous tentez d'utiliser n'est pas autorisée. Pour plus d'informations, contactez votre administrateur réseau". Bonne nouvelle !

Ici, c'est l'exemple d'un serveur membre. Sur les contrôleurs de domaine, cette autorisation est retirée par défaut. Désormais, grâce à la GPO, vous pouvez généraliser cette configuration et protéger vos serveurs ! Enfin, sachez que cette règle n'empêche pas l'ouverture d'une session en RDP via le Bureau à distance si l'utilisateur dispose des autorisations nécessaires (sur un serveur RDS, par exemple).

À vous de jouer !

L'article Comment empêcher les utilisateurs d’ouvrir une session locale sur les serveurs Windows ? est disponible sur IT-Connect : IT-Connect.

C'est officiel, Microsoft souhaite se débarrasser de l'outil Microsoft Support Diagnostic Tool (MSDT), surement dans le but de rendre Windows 11 et Windows 12 plus sécurisé. Voici les plans de l'entreprise américaine.

En 2022, l'outil MSDT a été évoqué à plusieurs reprises dans certains de mes articles faisant référence à la vulnérabilité Follina (CVE-2022-30190) exploitée par les cybercriminels pour exécuter du code malveillant sur Windows grâce à des documents Word malveillants. Microsoft ayant pris la décision de bloquer les macros dans les documents Office, cette faille de sécurité était une aubaine pour les pirates.

Désormais, c'est officiel, Microsoft veut supprimer l'outil MSDT de Windows et il sera retiré en 2025 ! Cette information avait déjà fuitée grâce à une bannière diffusée dans une build de Windows 11 présente dans le canal Dev.

Microsoft a mis en ligne un nouveau document qui détaille plus précisément la feuille de route à ce sujet. Ainsi, Microsoft souhaite procéder étape par étape pour supprimer cet outil de diagnostic, en commençant cette année jusqu'en 2025 :

• 2023 - Début de la redirection de certains outils de dépannage vers la nouvelle plateforme de dépannage "Obtenir de l'aide"
• 2024 - Terminer la transition des outils de dépannage et supprimer ceux restants.
• 2025 - Suppression complète de l'outil de diagnostic MSDT

La firme de Redmond précise aussi que tous les systèmes existants, à savoir aussi bien Windows 7, Windows 8.1, Windows 10 que Windows 11 22H2, pourront continuer à bénéficier de MSDT. Autrement dit, ils ne sont pas concernés par cette suppression, ce qui est tout de même étonnant pour les systèmes les plus récents.

Ce changement sera donc effectué dans les futures versions de Windows 11, et probablement dans Windows 12 par la suite. La fin de la feuille de route, en 2025, correspond à la fin de vie de Windows 10, ce qui n'est surement pas un hasard.

Un article est accessible à cette adresse sur le site de Microsoft, où vous pourrez obtenir plus de précisions si vous le souhaitez.

Source

L'article Microsoft va supprimer MSDT dans les futures versions de Windows est disponible sur IT-Connect : IT-Connect.

Microsoft a conclu un nouveau partenariat avec l'éditeur Adobe dans l'objectif d'intégrer le lecteur de PDF Adobe directement dans le navigateur Edge, à la place du lecteur de PDF actuel.

À partir de mars 2023, les nouvelles versions de Microsoft Edge à destination de Windows 10 et Windows 11 vont intégrer un nouveau lecteur de PDF, correspondant au moteur de rendu Adobe Acrobat PDF.

Pour l'utilisateur, cette intégration est totalement gratuite (dans la limite de certaines fonctionnalités) et elle devrait améliorer la gestion des PDFs dans le navigateur : "Les utilisateurs bénéficieront ainsi d'une expérience PDF unique, avec un rendu plus riche pour des couleurs et des graphiques plus précis, des performances améliorées, une sécurité renforcée pour la manipulation des PDF et une plus grande accessibilité - notamment une meilleure sélection du texte et une narration à voix haute", précise Adobe dans son communiqué officiel.

Pour les utilisateurs qui ont des besoins plus spécifiques, il sera possible de le faire via le navigateur Edge, mais à condition de payer un abonnement Adobe. J'entends par là : combiner plusieurs fichiers PDF en un seul PDF, éditer le texte ou les images d'un PDF, etc... Comme on peut le faire avec les produits actuels de chez Adobe.

Les entreprises auront le temps d'effectuer des tests

Pour les entreprises, ce changement peut ne pas être anodin et peut être la source de problèmes au sein de certaines applications. Mais, ce changement va être effectué progressivement.

À partir de mars 2023, le lecteur de PDF Adobe sera disponible, mais le lecteur de PDF actuel restera disponible jusqu'en mars 2024. C'est à ce moment-là que Microsoft retirera complètement son lecteur PDF actuel pour laisser place à celui d'Adobe par défaut.

Autrement dit, les entreprises pourront activer le lecteur Adobe pour effectuer des tests, tout en continuant d'utiliser le lecteur actuel jusqu'en mars 2024. Cela va laisser 1 an aux entreprises pour faire d'éventuel ajustement au niveau des applications.

Source

L'article A partir de mars 2023, Microsoft Edge va intégrer le lecteur de PDF d’Adobe est disponible sur IT-Connect : IT-Connect.