Microsoft avertit les utilisateurs que les mises à jour de Windows 10 publiées depuis le 28 juin peuvent être à l'origine de problèmes d'impression sur les imprimantes connectées en USB. Que se passe-t-il ?
Sur son site, la firme de Redmond précise : "Microsoft a reçu des rapports faisant état de problèmes affectant certains périphériques d'impression après l'installation des mises à jour de Windows publiées le 28 juin (KB5014666) et ultérieurement.". Ces problèmes affectent plusieurs versions de Windows 10, à savoir les versions 20H2, 21H1 et 21H2, mais aussi Windows Server version 20H2 (une version qui sera en fin de support le 9 août 2022, pour rappel).
Les utilisateurs qui ont rencontrés ce problème ont pu constater différents symptômes : Windows qui affiche des imprimantes en double avec le suffixe "Copy1" alors que l'imprimante est installée une seule fois, ou encore l'imprimante qui remonte avec un nom incorrect, ce qui empêche les applications de l'utiliser. A chaque fois, il s'agit d'imprimantes connectées en USB sur les ordinateurs.
Pour le moment, Microsoft n'a pas de correctif à proposer à ses utilisateurs et des travaux sont en cours pour identifier et corriger ce bug : "Nous enquêtons actuellement et nous vous tiendrons au courant dès que nous aurons plus d'informations.".
Néanmoins, Microsoft propose une solution de contournement qui consiste à utiliser l'imprimante avec "Copy1" dans le nom après avoir vérifié qu'elle fonctionnait bien. Si l'utilisateur souhaite utiliser l'imprimante d'origine, sans "copy1" dans le nom, il doit accéder aux propriétés de l'imprimante "Copy1" pour récupérer le nom du port et l'utiliser dans la première imprimante afin que l'impression fonctionne. Ensuite, l'imprimante "Copy1" peut être supprimée.
Si cela ne fonctionne pas, Microsoft recommande de mettre à jour les pilotes de l'imprimante sur votre PC ou de supprimer et réinstaller l'imprimante totalement au niveau de Windows. Cela s'annonce fastidieux pour les personnes concernées.
Avez-vous rencontré ce bug avec les impressions de votre côté ?
Bien que certaines entreprises misent désormais sur Azure Active Directory et se passent d'un Active Directory en local, il reste un système très répandu. Certaines des entreprises qui exploitent un annuaire Active Directory sont exposées à la vulnérabilité "Broken owner" sans le savoir, ce qui rend les comptes à faible privilège sensibles. Ces comptes peuvent devenir la cible d'attaques informatiques.
Dans cet article, nous allons vous montrer comment cela se produit, vous expliquer les risques encourus, et vous expliquer comment détecter ces objets ayant un propriétaire inadapté (broken owner, en anglais) à l'aide d'un script PowerShell afin de protéger l’annuaire des potentielles attaques basées sur ce vecteur de compromission (par exemple, les attaques par délégation Kerberos).
La sécurité informatique est devenue un enjeu majeur pour les entreprises, l’AD suscite une attention particulière dans une infrastructure système Microsoft, ce dernier a pour rôle principal d’autoriser les accès aux différentes ressources, de repérer les services et de gérer les identités et permissions.
Un Active Directory propre, une obligation.
Toute mauvaise configuration ou mauvais usage de l’AD est une porte d’entrée pour une future attaque. C’est pour cette raison qu’il est essentiel de respecter les bonnes pratiques et veiller continuellement sur leurs applications. N’oublions pas qu’un AD maîtrisé et organisé constitue la base de la sécurité.
II. La notion de propriétaire des objets Active Directory
Chaque objet dans l’Active Directory possède un propriétaire qui lui confère tous les droits, notamment les droits de modifier la valeur des attributs et des autorisations. Ces droits sont représentés par des ACL (Access Control List) et sont dupliqués à partir du compte (Self) de l’objet.
Il est donc très dangereux d’accorder ce droit à des utilisateurs ou groupes à non-privilèges, que ce soit d’une façon volontaire ou intentionnelle.
A. Comment cela se produit-il?
Un utilisateur ou groupe autorisé à créer un objet dans l’AD (par délégation, par exemple) deviendra le propriétaire de cet objet à moins que ce dernier fasse partie d’un groupe à privilège, comme par exemple "Admin du domaine"; dans ce cas, le propriétaire de l’objet sera corrigé et remplacé automatiquement par l’Active Directory.
Propriétaire d'un objet créé à partir d’un compte qui fait partie d’un groupe à privilèges
III. La problématique associée aux propriétaires d'objets
Vous devez savoir que si l’utilisateur ou le groupe n’est pas membre du groupe à privilège, il sera le propriétaire de l’objet. Lors de la création de l’objet, ce dernier hérite des droits du compte système par défaut Self présent dans la table ACL.
utilisateur user2 créé par user3 (user3 étant un compte à non-privilège)
Le propriétaire user3 possède les droits de modifications des attributs sur l’objet user2
Si le compte “Self” avait le contrôle total, le propriétaire dans notre cas “User3” aura aussi le contrôle total. Si ce n’est pas le cas, il peut toujours se le procurer et faire des modifications à tout moment sur ces objets (car il a les permissions de modification des attributs), ces utilisateurs ou groupes deviennent ainsi une cible potentielle lors d’attaques donc il faudra les protéger et les surveiller.
A. Exemple avec la délégation pour créer des comptes
Sur l’OU "IT-Connect", nous allons déléguer le droit de création d'utilisateurs à "HelpDesk 1" qui n'aura aucun autre droit dans l’AD ni sur les machines locales.
Sélection du compte Helpdesk1 pour délégation d’administration sur l’OU IT-CONNECT
Pour faire simple, nous allons lui accorder le droit de créer des comptes utilisateurs.
Ajout des droits de création, suppression et gestion de comptes dans la délégation
Nous allons ensuite créer avec l’utilisateur "HelpDesk1", les comptes "Florian" et "Dakhama", à partir d’une machine dans le domaine. Pour cela, l'utilisateur utilisera les outils "RSAT", la commande "DSADD" ou PowerShell.
Création des comptes Florian et Dakhama par Helpdesk1
Les deux objets sont bien présents dans notre Annuaire et ils ont comme propriétaire notre utilisateur "helpdesk1".
Comptes créés par Helpdesk1
Voici les détails de sécurité du compte "Florian" :
Helpdesk1 est propriétaire du compte Florian
B. Retrait des droits
Nous allons maintenant retirer les droits à l’utilisateur "HelpDesk1". Autrement dit, on supprime la délégation créée précédemment.
Dans l’onglet "Sécurité" de l'OU "IT-Connect", nous allons supprimer l’utilisateur "HelpDesk1" de la table ACL pour lui retirer les droits. L'utilisateur, quant à lui, existe toujours.
Retrait délégation de Helpdesk1 sur l’OU IT-Connect
Nous constatons ensuite que l’utilisateur "HelpDesk1" ne peut plus créer de compte. C'est normal.
Helpdesk1 ne peut plus créer de comptes après la suppression de la délégation
Les droits sont grisés :
Helpdesk1 ne peut pas effectuer de modifications sur IT-Connect
C. Risques et menaces
L’utilisateur "HelpDesk1" n’a plus aucun droit sur notre AD, à part sur les objets dont il est le propriétaire.
Nous allons nous procurer le contrôle total sur nos anciens objets créés quand la délégation de contrôle était effective. Pour faire simple, on ouvre la console utilisateur AD (dsa.msc), on effectue un clic droit sur l’utilisateur "Florian" afin d'ajouter "HelpDesk1" (lui-même).
Helpdesk1 modifie les permissions et obtient le contrôle total sur l'objet utilisateur "Florian"
Maintenant que nous avons le contrôle total sur notre objet (pour rappel, l’utilisateur HelpDesk1 n’a plus aucun droit sur l’AD, les délégations ont été supprimées) on pourra tout faire sur ce compte ! Pour être précis, on peut effectuer le changement du MDP, récupérer le Hash, faire des attaques sur des attributs par délégation (ms-ds-allowedhosted), etc…..
Ici nous allons changer la valeur de l’attribut "Description", à titre d'exemple.
Helpdesk1 change l’attribut Description de Florian
Je vous laisse imaginer ce qu’il est possible de faire avec ces objets, vous pouvez trouver plein d'exemples sur le Net... Ci-dessous, un autre exemple d’exploit de cette vulnérabilité. L'attaque Délégation Kerberos peut aussi être utilisée.
Voici un autre exemple de l’exploit de la vulnérabilité "Broken Owner".
Dans ce scénario, si le compte HelpDesk1 est compromis à partir d’un hash présent sur une machine sur laquelle il intervient (support niveau 1), la personne malveillante pourra se procurer ses objets dans l’AD, les rendre indétectables (en refusant la lecture de certains éléments à des groupes à privilèges) et passer en cachette pour extraire des données ou injecter des ransomwares sur des ressources partagées.
D’autres scénarios sont envisageables, A noter que même si HelpDesk1 ne possède plus de droit dans l’AD, son compte reste sensible en raison des objets dont il est le propriétaire.
IV. Comment détecter les comptes avec un propriétaire inadapté ?
Maintenant que nous sommes conscients de ce risque et de ces menaces, nous allons voir comment lister et détecter les mauvais propriétaires des objets afin de les corriger.
A. Le script PowerShell "SCABOO"
Pour cela, nous avons développé un script simple d’utilisation (et open source) pour nous faciliter la tâche.
Ci-dessous, le lien du script PowerShell. Il existe aussi en interface graphique :
Le projet porte le nom de SCABOO (Scan-AD-Broken-Owner-Object). Pour l'utiliser, il vous suffit de le télécharger et de l'ouvrir avec PowerShell ISE ou VSCode.
La bonne nouvelle, c'est que ce script ne nécessite pas de prérequis spécifique pour fonctionner :
Aucun module ni les droits avancés ne sont nécessaires
Une machine et un utilisateur du domaine, tout simplement
Le script pourra être lancé à partir de n’importe quelle machine dans le domaine, avec n’importe quel compte. Il ne nécessite aucun module PowerShell complémentaire, ce qui est un avantage, et ne garde rien dans la mémoire "Variable avec les informations". Le traitement est spontané et sécurisé.
Note : utilisez le GUI si vous avez des restrictions pour exécuter le script PowerShell...
Ce que vous devez savoir sur ce script...
Le script effectue des requêtes LDAP grâce au module ADSI, il ne fait que des requêtes de types GET donc aucune modification n’est faite sur l’annuaire. Le script n’utilise pas de variable en dur comme "admins du domaine", etc…. Mais plutôt des SID, ce qui le rend compatible avec toutes les versions d’AD de toutes langues.
Une fois lancée, nous avons le choix entre un scan de l’AD entier ou de choisir une OU spécifique, nous allons commencer par ce second choix.
Entrez le numéro 2.
Ensuite, entrez le nom de votre OU, dans mon cas IT-Connect. Vous pouvez entrer seulement l’initiale, le script fera une recherche et proposera le choix entre les OU portant une partie du nom.
Sélectionnez votre OU, puis entrez OK.
Le scan est lancé
Une fois que le scan est terminé, une page HTML sera créée au même emplacement que le script. Elle sera lancée automatiquement et affiche un résumé des objets scannés et ceux présentant une anomalie.
Pour scanner tout l’AD, nous allons relancer le script et choisir l’option 1.
Remarque : attention, si votre AD contient plus de 1000 objets, le scan risque d'être un peu long (2 à 3 minutes). Si besoin, vous pouvez stopper le script à tout moment.
Voici le résultat pour un scan sur l'ensemble de notre AD :
Le script nous liste aussi les éléments sans propriétaire Owner qu'il faudra corriger en urgence, car ils peuvent être la cible d’attaques.
B. Personnalisation du script
Selon vos besoins, vous pouvez adapter certaines parties du script.
Nombre d’éléments affiché
Par défaut, le script liste 50 éléments à corriger dans le tableau, ce choix a été fait pour ne pas ralentir le traitement et l’affichage de la page HTML, si vous avez plus de 50 éléments vous pouvez les afficher en changeant cette ligne numéro 222.
Remplacez le 50, par le nombre d’objets par catégorie souhaité.
Affichage dans un autre format
Vous pouvez afficher le résultat dans un fichier Excel ou dans une fenêtre GridView. Pour le faire, commentez les lignes 246 et 248, et décommentez la dernière ligne.
Exemple du résultat :
Exclure un compte
Si vous souhaitez exclure un groupe ou un compte (par exemple, le compte d’intégration MDT ou SCCM, ou un compte quelconque du résultat), ajoutez ce dernier à la variable Skipdefaultgroups. Dans notre exemple, on exclut le groupe "MDT-account".
V. Recommandations
Face à cette potentielle vulnérabilité permanente, Microsoft et ANSSI nous recommandent de changer les propriétaires des objets qui ont un propriétaire à non-privilège ou qui n’ont pas de propriétaire (Broken Owner) par l'un de ces groupes
« Administrateurs du domaine » ;
« Administrateurs de l'entreprise » ;
« Administrateurs » ;
« Système local »
Vous pouvez consulter les liens ci-dessous en complément :
Le propriétaire des objets Active Directory est un élément très important pour la sécurité de l’annuaire. Il convient d’adapter nos usages en tenant compte de cet aspect. Nous reviendrons en détail dans un prochain article sur les méthodes de préventions et de corrections.
Merci à Mehdi Dakhama pour sa collaboration sur cet article.
Les cybercriminels derrière le logiciel malveillant QBot ont utilisé la calculatrice Windows pour exécuter une charge malveillante sur les ordinateurs infectés. Cette version de QBot est distribuée dans le cadre de campagnes de phishing.
Le logiciel malveillant Qbot, appelé aussi Qakbot, s'en prend aux machines sous Windows et il s'agit d'un trojan bancaire qui est également utilisé pour déployer d'autres logiciels malveillants (notamment des ransomwares). Il emploi différentes méthodes et les cybercriminels cherchent toujours de nouvelles combines pour passer entre les mailles du filer et éviter la détection par les systèmes de protection de la machine.
Cette fois-ci, c'est par l'intermédiaire du chercheur en sécurité Pr0xyLife que l'on apprend que Qbot utilise la technique dite de "DLL side-loading" pour charger une bibliothèque malveillante sur la machine locale à partir d'un autre exécutable. Dans le cas présent, l'exécutable n'est autre que celui de la calculatrice version Windows 7, à savoir "calc.exe", qui est utilisée pour charger la DLL malveillante à la place de la DLL légitime.
Pr0xyLife et les chercheurs de chez Cyble ont documentés cette nouvelle chaîne d'infection. L'e-mail envoyé dans le cadre de campagnes de phishing contient un fichier HTML en pièce jointe. Cette page, aux couleurs d'Adobe Acrobat DC, invite l'utilisateur à télécharger le document car l'affichage en ligne échoue. Le téléchargement permet à l'utilisateur d'obtenir une archive ZIP protégée par mot de passe, ce dernier étant visible sur la page HTML et il sert à éviter les analyses antivirus.
Cette archive ZIP contient une image ISO qui contient différents fichiers : un fichier LNK, une copie de la Calculatrice Windows à savoir un fichier "calc.exe" et deux fichiers DLL nommés WindowsCodecs.dll et 7533.dll, ce dernier étant la charge malveillante. Quand l'utilisateur monte l'image ISO, il voit seulement le fichier ".LNK" qui prend l'allure d'un fichier PDF mais qui n'en est pas du tout un puisqu'il sert à exécuter une commande sur le système qui va lancer la calculatrice.
Windows va alors chercher à ouvrir la calculatrice (contenue dans l'image ISO) et il va rechercher les DLL dont il a besoin, en regardant dans le même répertoire que celui où se situe l'exécutable "calc.exe", ce qui va permettre de charger les bibliothèques malveillantes via la calculatrice Windows ! Cette méthode permet de passer outre la détection de certaines solutions de sécurité.
Il est à noter que les pirates utilisent la version Windows 7 de "calc.exe" car cela ne fonctionne plus avec la calculatrice depuis Windows 10. Néanmoins, cette méthode d'infection fonctionne aussi sur les systèmes Windows les plus récents.
Si vous recherchez un micro-casque de bonne qualité à un prix intéressant, alors ce modèle de chez HyperX devrait vous intéresser ! Le casque HyperX Cloud II passe à 61,99 euros sur Amazon au lieu d'un prix habituel de 79,99 euros.
Les avis sont bons pour ce micro-casque qui va vous permettre de bénéficier d'un bon rendu sonore, que ce soit pour jouer, regarder des films ou tout autre usage multimédia, car il est capable de générer un son surround 7.1 virtuel. Il est équipé d'un micro avec des fonctions plutôt sympas comme la suppression de bruit, l'annulation des échos et le contrôle automatique de gain.
Il se connecte en USB à votre machine et dispose d'un boîtier de commande audio positionné directement sur le câble pour faciliter l'utilisation de certaines fonctionnalités : gestion du volume et du microphone. En fait, il n'est pas compatible uniquement avec les PC puisqu'il fonctionne aussi avec les consoles de jeux (PS4 / Xbox One) et les Mac de chez Apple.
HyperX est une marque plutôt bien réputée pour faire des casques solides et confortables, ce qui est un point important quand on est amené à le garder pendant plusieurs heures sur la tête. Même si c'est loin d'être le dernier modèle de la marque, le rapport qualité/prix semble intéressant.
Atlassian a corrigé une nouvelle faille de sécurité critique dans une application pour Confluence Server et Confluence Data Center qui pourrait permettre à un attaquant de s'authentifier à distance sur un serveur non protégé. Faisons le point.
Associée à la référence CVE-2022-26138, cette faille de sécurité est liée à des identifiants codés en dur pour un compte nommé "disabledsystemuser". Ce compte sert à aider les administrateurs pour migrer des données d'une app vers Confluence Cloud. L'app en question qui intègre ces identifiants en dur, c'est "Questions for Confluence" dans plusieurs versions 2.7.34, 2.7.35, et 3.0.2. À ce jour, et d'après les statistiques de la marketplace d'Atlassian, ce sont environ 8 000 serveurs qui utilisent cette application et qui sont donc vulnérables à cette vulnérabilité.
Dans son bulletin de sécurité, Atlassian affirme : "Le compte disabledsystemuser est créé avec un mot de passe codé en dur et est ajouté au groupe confluence-users, qui permet par défaut de visualiser et de modifier toutes les pages non restreintes de Confluence.". Autrement dit, ce compte est présent avec le même nom d'utilisateur et le même mot de passe sur toutes les instances. De ce fait, cela signifie que : "Un attaquant distant et non authentifié connaissant le mot de passe codé en dur pourrait exploiter cette situation pour se connecter à Confluence et accéder à toutes les pages auxquelles le groupe confluence-users a accès.".
Bien qu'il n'y ait aucune évidence que cette vulnérabilité est exploitée dans le cadre d'attaques, d'après l'analyse d'Atlassian, il est recommandé de mettre à jour votre instance dès que possible. Désinstaller l'application "Questions for Confluence" de son serveur Confluence ne suffit pas, et si vous ne pouvez pas patcher pour le moment, Confluence recommande de patcher ou de supprimer (ou désactiver) le compte "disabledsystemuser" (voir cette doc) pour s'en débarrasser et se protéger contre ce vecteur d'attaque.
Enfin, l'éditeur précise que vous pouvez savoir si vous êtes affecté par cette vulnérabilité, en vérifiant si vous avez un compte utilisateur actif avec ces informations :
Utilisateur : disabledsystemuser
Identifiant : disabledsystemuser
Email : dontdeletethisuser@email.com
Pour rappel, le mois dernier Atlassian Confluence était concerné par une faille de sécurité zero-day.
