Il se passe quelque chose entre la solution VMware Carbon Black et les serveurs Windows Server ainsi que les postes de travail Windows : plusieurs dizaines d'entreprises se plaignent que les machines plantent, en affichant un écran bleu de la mort (BSoD). Que se passe-t-il ?

VMware Carbon Black est une solution de sécurité (EDR) qui s'installe sur les postes de travail et les serveurs (endpoint).

Depuis hier vers 16h00, à savoir mardi 23 août 2022, de nombreuses entreprises reportent des problèmes avec ce logiciel et les machines sous Windows. Plus de 50 entreprises semblent touchées par ce problème qui a des conséquences importantes : il fait littéralement planter Windows, en générant un écran bleu de la mort avec le message "PFN_LIST_CORRUPT.". Un administrateur système, dont l'entreprise est impactée, affirme qu'il a plus de 500 terminaux qui plantent à répétition avec des écrans BSoD !

D'après les remontées, plusieurs versions de Windows sont impactées par ce problème : Windows Server 2012 R2 (x64), Windows Server 2016 (x64), et Windows Server 2019 (x64), sans oublier Windows 10 (x64) pour la partie desktop. Il s'avère que c'est la version 3.7.0.1253 de VMware Carbon Black qui est à l'origine de ces bugs à répétition.

De son côté, VMware a mené des investigations suite à ces différentes alertes émises par les clients. L'entreprise américaine a procédé à la suppression des règles défectueuses et à l'origine ces erreurs. Comme solution de contournement temporaire, VMware recommande de mettre les endpoints en mode Bypass via la console Carbon Black Cloud afin que les appareils impactés démarrent et prennent en compte la suppression de la règle.

De son côté, VMware a fait la déclaration suivante au site BleepingComputer : "VMware Carbon Black est au courant d'un problème affectant un nombre limité de terminaux de clients, où certaines anciennes versions de capteurs ont été affectées par une mise à jour de nos capacités de prévention comportementale. Le problème a été identifié et corrigé, et VMware Carbon Black travaille avec les clients concernés." - Désormais, tout semble rentrer dans l'ordre petit à petit pour les entreprises impactées, mais on peut imaginer à quel point ce problème peut être impactant (et mettre une pression de dingue aux équipes IT).

Source

The post VMware Carbon Black à l’origine d’écran bleus de la mort sur Windows Server et Windows 10 first appeared on IT-Connect.

Amazon propose une offre très intéressante sur un kit Ring Alarm de 2ème génération comprenant 6 appareils différents, au prix de 179,99 euros au lieu de 249,99 euros. Soit une remise de près de 30% sur ce pack.

Ce kit Ring Alarm V2 intègre les éléments suivants : une base (alarme), un pavé numérique, un capteur de contact, un détecteur de mouvements, un amplificateur de portée qui sert à étendre le réseau Z-Wave et une caméra Ring Indoor Cam offerte en supplément. Pour un kit de démarrage et sécuriser son logement, c'est particulièrement intéressant. Il y a également des offres sur des kits Ring Alarm avec un plus grand nombre d'appareils. Quoi qu'il en soit, c'est une solution évolutive donc vous pouvez acquérir de nouveaux capteurs, de nouvelles caméras, voire même une sirène extérieure par la suite.

La marque Ring (d'Amazon) est présente sur le marché depuis plusieurs années et les appareils sont aboutis. Sans surprise, ils sont compatibles avec l'assistant vocal Amazon Alexa, et pilotables à distance à partir de son smartphone. Pour bénéficier de certaines fonctionnalités (voir le site de Ring), il faut savoir qu'il est nécessaire de souscrire à un abonnement à partir de 10 euros par mois (peu importe le nombre d'appareils), même si ce n'est pas une obligation.

Pour en savoir plus ou acheter ce kit, voici le lien vers l'offre :

• Amazon - Kit Ring Alarm

The post Bon plan : sécurisez votre logement avec ce kit Ring Alarm (6 pièces) à 180 euros ! first appeared on IT-Connect.

I. Présentation

Dans un tutoriel précédent, nous avons découvert la vulnérabilité "Broken owner" de l'Active Directory liée aux délégations d’administration et de manipulations que nous effectuons au quotidien sur les objets de l'annuaire Active Directory.

Nous allons poursuivre l'aventure et voir dans cet article comment corriger cette vulnérabilité en ajustant les propriétaires des objets, puis nous verrons dans un troisième article, qui clôturera cette série, comment éviter que cela se produise.

• Premier article : Sécurité de l'Active Directory : attention aux objets avec un propriétaire inadapté

II. Retour sur la vulnérabilité "Broken owner"

A. Rappel

D'après l'article précédent, cette vulnérabilité se produit lorsqu’un objet est créé dans l’AD par un compte à non-privilège (à l’issue d’une délégation) ou créé par un compte à privilège qui ne l’est plus (après le retrait de ce dernier des groupes à privilèges).

B. Recommandations

D'après l’ANSSI et Microsoft, il est recommandé de mettre en place un groupe à privilèges comme propriétaire des objets, parmi ceux-ci: Administrateurs du domaine, Administrateur  de l’entreprise, Administrateurs. Il s'agit d'éléments natifs, que vous connaissez probablement.

C. Pourquoi faut-il corriger le propriétaire ?

Il est indispensable de corriger l’objet afin d'ajuster le propriétaire dans l'objectif d'atténuer la surface d’attaque et les chemins d'accès. Pour rappel, une personne malveillante ne cherche pas absolument à être admin du domaine, mais plutôt à compromettre les données ou les extraire. De ce fait, garder les objets sans propriétaire (owner) ou avec un owner sensible expose votre entreprise à des risques de sécurité permanent, en plus d'alourdir la tâche de l’équipe SOC.

Dans le schéma ci-dessous, après la correction, la personne malveillante ne pourra plus se procurer les objets dont le HelpDesk est propriétaire, ce qui l'empêchera de s'octroyer les droits et d'accéder aux ressources de l’objet (Utilisateur RSI ou Secrétaire dans notre cas).

D. Comment corriger le propriétaire de l'objet ? 

Deux méthodes s’offrent à nous : faire le changement manuellement à partir de l’onglet "Sécurité" et choisir un groupe à privilège par défaut (par exemple "Admin du domaine"), ou utiliser un script. Cette seconde option sera traitée dans un second temps, dans cet article.

Voici un exemple de modification sur le compte "Florian". Actuellement le propriétaire est "helpdesk1".

On le change pour définir le groupe "Admins du domaine" à la place.

Note : Si vous choisissez un groupe étant membre d’un groupe à privilèges, mais qu’il n’est pas natif (exemple "GG_admins" membre de admins du domaine), la correction sur les objets Owner ne se fera pas automatiquement, et c’est ce groupe qui résidera comme Owner. Dans le cas où il ne fera plus partie du groupe à privilèges ("Admin du domaine"), les objets seront une nouvelle fois vulnérables.

Après correction, nous constatons qu’il n’est plus possible à l’utilisateur "HelpDesk1" de faire des modifications sur l'objet "Florian". Les ACLs sont grisées :

E. Les Exceptions

Avant de faire tout changement, prenez le temps d’analyser le résultat du premier script, dont on a déjà parlé dans l'article précédent. En effet, certaines applications manipulent des objets AD au cours de leur cycle de vie, devenant ainsi propriétaire de certains. Le changement de propriétaire sur les objets dont elles sont propriétaires pourrait les empêcher de réaliser totalement leurs tâches.

Pour cette raison, il convient d'auditer votre configuration avant de réaliser la correction.

F. Persistance

Bien que la correction constitue un premier remède, cela n’est pas suffisant. Si le propriétaire s'est déjà procuré les droits "Contrôle total" (CT) ou de modification des permissions sur un objet, la correction n’apportera pas grande chose au niveau de la sécurité. Cette subtilité sera abordée dans le prochain article.

III. Corriger les propriétaires avec un script PowerShell

Pour automatiser la correction des propriétaires des objets, nous avons développé un script simple d’utilisation (et open source) pour nous faciliter la tâche ! Voici le lien du script PowerShell : Script CABOO (Correct Broken Owner)

Le projet porte le nom de CABOO (Correct-AD-Broken-Owner-Object). Pour l'utiliser, il vous suffit de le télécharger et de l'ouvrir avec PowerShell ISE ou VSCode.

L'exécution de ce script nécessite les prérequis ci-dessous :

• Une machine membre du domaine
• Un compte utilisateur membre du groupe "Administrateur du domaine"

Pourquoi faut-il l'exécuter en mode administrateur ? Cela se justifie par le fait que les deux commandes pour remplacer le propriétaire ne passent pas avec les droits standards.

$ownerinfo.PsBase.ObjectSecurity.SetOwner($NewOwner)
$ownerinfo.PsBase.CommitChanges()

Le script utilise le même principe que le script d’audit SCABOO.

A. Corriger les propriétaires sur une OU

Lancez le script et choisissez l’option "2". Ensuite indiquez votre OU et valider par OK.

1 - Sélectionnez l’OU

2 - Choisissez le nouveau propriétaire (pour suivre les recommandations, cochez "Admins du domaine")

3 - Vérifiez que le bon groupe est sélectionné, puis appuyez sur OK

Le traitement est alors lancé ! En cas d’erreur, cela sera affiché sur le résultat final ou en cours du scan. De toute façon, il est possible d'arrêter le script à tout moment.

Une fois l'exécution terminée, une page HTML s'affiche en guise de rapport pour indiquer indiquer les objets changés, ainsi que l’ancien propriétaire. Le nouveau, vous le connaissez.

B. Exclure un utilisateur ou un groupe

Si vous voulez exclure un compte ou un groupe du processus de correction, il suffit d’ajouter ce dernier à la variable "$skipdefaultgroups" présente à la ligne 50 du script. Indiquez bien le nom du groupe, sans le nom du domaine.

Exemple : pour ne pas corriger les objets ayant "SCCM$" ou "Exchange" comme propriétaire, faites ceci :

C. Scanner sur un type d’objet

Si votre OU contient des utilisateurs, groupes et machines, et que vous ne souhaitez faire la correction que sur les utilisateurs, il suffit de commenter la ligne "$newowner" sur le type que vous souhaitez ignorer. Dans notre cas, nous allons ignorer le traitement sur les types "OU" et "groupes".

Si vous obtenez une erreur lors du traitement, c’est que le script n’est pas lancé en mode admin. Sinon, lisez le code d’erreur afficher sur la console PowerShell ISE (ou VSCode) lors du traitement. Dans notre cas "error" signifie que le traitement n’est pas abouti, et aucune modification n’a été faite. Vous pouvez contribuer à ce script ou le modifier à votre convenance !

Rendez-vous prochainement pour la suite de cet article, où nous verrons comment éviter de se retrouver avec des propriétaires inadaptés sur les objets de l'Active Directory.

The post Active Directory : comment corriger les propriétaires inadaptés sur les objets ? first appeared on IT-Connect.

Le chercheur israélien Mordechai Guri a fait la découverte d'une nouvelle méthode pour exfiltrer des données en utilisant les voyants lumineux des cartes réseau. Baptisée ETHERLED, cette trouvaille est à la fois étonnante et ingénieuse !

Grâce à la méthode ETHERLED, les voyants clignotants présents sur les cartes réseau sont transformés en signaux morse qui peuvent être décodés par un attaquant ! Pour capturer ces signaux, il faut être tout de même équipé, car il faut une caméra qui visualise en direct les voyants lumineux de la carte réseau de l'ordinateur cible. Ensuite, ces signaux sont traduits en binaire pour reconstituer les informations.

Cette méthode pour voler les informations s'applique sur les réseaux air-gapped, c'est-à-dire lorsque l'ordinateur est sur un réseau totalement isolé (car il est très sensible, par exemple). Puisqu'il est isolé et qu'il n'a pas d'accès à Internet, il est plus difficile pour les attaquants de l'atteindre à moins d'utiliser des méthodes adaptées, comme celle-ci. Le schéma ci-dessous illustre un exemple, où l'on se croirait presque dans James Bond avec le drone qui est là pour capturer les signaux morse de la carte réseau !

Même si le système est isolé dans un réseau air-gapped, Mordechai Guri affirme que si un attaquant parvient à infecter l'ordinateur cible avec un logiciel malveillant, il peut faire en sorte de remplacer le pilote de la carte réseau par une version malveillante qui modifie la couleur de la LED et la fréquence de clignotement : comme il l'a fait avec la méthode ETHERLED. Même s'il prend l'exemple d'un ordinateur, cette méthode peut fonctionner avec d'autres périphériques équipés de cartes réseau Ethernet : imprimantes, NAS, routeurs, etc. Il faut garder à l'esprit que sans l'infection initiale, c'est-à-dire le logiciel malveillant sur l'ordinateur cible qui va permettre de modifier le pilote de la carte réseau, cette méthode ne peut pas être utilisée.

Selon les voyants allumés sur la carte réseau et la couleur des voyants allumés, cela permet d'obtenir l'information en binaire : 00, 01 ou 10. En s'appuyant sur la méthode du morse, il faut inclure également des temps de pause entre les signaux. Même si cela peut sembler une éternité pour traduire une information, d'après le chercheur en sécurité, le temps nécessaire pour divulguer des mots de passe grâce à ETHERLED varie entre 1 seconde et 1,5 minute, selon la méthode d'attaque utilisée. Autre exemple, le temps nécessaire varie entre 2,5 secondes et 4,2 minutes pour les clés privées Bitcoin, et entre 42 secondes et une heure pour les clés RSA de 4096 bits.

Après avoir lu cet article, vous ne regarderez plus les LEDs des cartes réseau de la même façon !

Source

The post ETHERLED : une méthode pour voler des données grâce aux LED des cartes réseau ! first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à établir une connexion SSH à un dépôt GitLab, en générant une paire de clés SSH en amont. Grâce à cette connexion, il sera possible de travailler en local sur les fichiers de notre projet hébergé sur GitLab, en utilisant Git.

Grâce à SSH, notre machine locale va pouvoir établir une connexion sécurisée à GitLab pour télécharger et pousser les données de notre projet Git. Ainsi, pour se connecter à GitLab depuis Git, l'authentification s'effectuera par un échange de clés plutôt qu'un couple "identifiant / mot de passe". GitLab accepte différents types de clés SSH, notamment les clés ED25519 (à prioriser vis-à-vis de RSA !).

Avant de commencer, et si vous débutez avec GitLab, vous devez créer un compte sur GitLab et créer un nouveau projet. Ceci est totalement gratuit. En ce qui me concerne, pour cette démonstration je vais utiliser le projet nommé "demo-git" au sein du GitLab IT-Connect.

• S'inscrire sur GitLab

Vous devez également avoir Git sur votre ordinateur afin de pouvoir utiliser les différentes commandes, que ce soit sous Windows (comme moi) ou Linux. Avant de mettre en ligne ce tutoriel, j'ai publié un premier article d'introduction à Git que je vous invite à lire : Débuter avec Git.

II. Générer les clés SSH

Le client SSH est préinstallé sur plusieurs versions de Windows, notamment Windows 10 et Windows 11, ainsi que Linux et macOS. À partir d'une console ouverte sur ma machine Windows, je peux voir facilement quelle est la version d'OpenSSH installée sur ma machine :

ssh -V

• Comment utiliser le client SSH sous Windows ?

Un résultat semblable à celui ci-dessous sera retourné. Il n'est pas nécessaire d'effectuer une modification, car la version installée par défaut est suffisante.

Qui dit authentification par clés, dis que nous devons disposer d'une paire de clés, à savoir une clé privée qui restera sur notre machine locale, et une clé publique que l'on va déclarer par la suite côté GitLab. Si vous avez déjà utilisé l'authentification par clé SSH sur votre machine, ce n'est pas nécessaire de régénérer une nouvelle paire de clés (même s'il est possible d'avoir plusieurs paires de clés avec des noms différents). Sinon, il faut le faire dès maintenant avec l'utilitaire ssh-keygen.exe, inclus avec le client SSH.

Comment savoir si vous avez déjà des clés SSH ? Pour cela, accédez au répertoire ".ssh" situé dans votre profil utilisateur. Sous Windows, et pour l'utilisateur "Florian", cela donne :

C:\Users\Florian\.ssh

Sous Linux, il faudra regarder le répertoire ".ssh" du home de l'utilisateur. Pour générer une paire de clés, on exécute cette commande :

ssh-keygen -t ed25519

Appuyez sur Entrée pour conserver le nom par défaut, à savoir "id_ed25519". Ensuite, la passphrase est demandée pour sécuriser la clé privée ; elle fait office de mot de passe (que vous devez stocker dans votre gestionnaire de mots de passe favori). Validez.

Dans le répertoire ".ssh" de mon utilisateur, j'ai bien ma paire de clés :

• Fichier id_ed25519 correspondant à la clé privée
• Fichier id_ed25519.pub correspondant à la clé publique (associée à ma clé privée)

Note : la paire de clés est enregistrée dans SSH, car elle est stockée dans le répertoire par défaut dans lequel regarde SSH. Si vous utilisez un autre répertoire, il sera nécessaire d'utiliser la commande "ssh-add" suivi du chemin vers le répertoire où se situe la clé privée afin que SSH le prenne en compte.

Désormais, on va copier dans le presse-papier de Windows le contenu de la clé publique :

cat C:\Users\Florian\.ssh\id_ed25519.pub | clip

Vous pouvez aussi ouvrir le fichier (ou afficher le contenu avec "cat") et copier vous-même le contenu. L'étape suivante se passe sur GitLab.

III. Ajouter une nouvelle clé SSH sur GitLab

Ouvrez un navigateur et connectez-vous sur votre espace GitLab. Ensuite, cliquez sur votre avatar en haut à droite pour ouvrir le menu puis cliquez sur "Preferences".

Sur la gauche, cliquez sur "SSH Keys".

Puis à droite, renseignez la section "Add an SSH key" pour ajouter la clé SSH. Ici, dans la zone "Key", il faut coller le contenu de la clé publique générée précédemment. Vous pouvez également donner un nom (Title). Cliquez sur "Add key" quand c'est fait. Voici un exemple :

Notre clé SSH est déclarée sur notre compte GitLab ! Désormais, il va être possible de s'authentifier sur GitLab avec cette paire de clés SSH.

IV. Se connecter à GitLab via SSH

Retournez dans la console afin d'établir une connexion SSH à GitLab. Exécutez la commande suivante :

ssh -T git@gitlab.com

Lorsque la question "Are you sure you want to continue connecting ?" apparaît, répondez "yes" et appuyez sur Entrée. Au final, le message suivant s'affiche avec votre nom d'utilisateur :

V. Cloner un projet GitLab avec Git

Maintenant, l'objectif va être de cloner le projet "demo-git" de mon espace GitLab pour avoir les données du projet en local. Ensuite, je vais pouvoir travailler en local sur mon projet, et quand j'aurais apporté des modifications, je pourrais les pousser (push) vers GitLab. Le tout via la connexion SSH.

Mon projet est accessible à l'adresse suivante :

https://gitlab.com/it-connect/demo-git/

Avec la commande "git clone", cela va me donner cette syntaxe :

git clone git@gitlab.com:it-connect/demo-git.git

Bien entendu, vous devez adapter le chemin par rapport à votre compte et votre projet. Afin de pouvoir récupérer les données, la passphrase de la clé SSH doit être saisie. Dans l'exemple ci-dessous, on peut voir que j'ai pu récupérer trois éléments.

Sachez également que le projet sera cloné dans un sous-répertoire du répertoire courant, pour ma part dans "C:\Git\GitLab", ce qui donnera "C:\Git\GitLab\demo-git".

En fait, mon projet "demo-git" est vide pour le moment, si ce n'est qu'il y a le fichier "README.md".

Sur l'ordinateur local, j'ai copié-collé le script "Windows-Install-FSRM.ps1" dans le répertoire "demo-git" correspondant à mon projet cloné depuis GitLab. Je vais ajouter ce fichier à mon projet :

git add .\Windows-Install-FSRM.ps1

Puis, regarder le statut :

git status

Git m'indique qu'il y a un changement à commit, en l'occurrence l'ajout de ce fichier (événement "new file"). J'en profite pour réaliser un commit qui sera ma version initiale :

git commit -m "Version initiale"

À partir de ce moment-là, le commit est fait en local. Côté GitLab, il n'y a pas de changement : le nouveau fichier n'est pas présent sur le dépôt GitLab. Pour pousser les modifications vers le dépôt GitLab, dans la branche principale, voici la commande à utiliser :

git push origin main

À partir de là, mon fichier est présent sur le dépôt GitLab. Pour le vérifier, je peux simplement rafraîchir la page dans mon navigateur. Le fichier "Windows-Install-FSRM.ps1" est bien présent et le commentaire de mon commit également, à savoir "Version initiale".

Nous venons de voir comment établir une connexion SSH entre Git et GitLab afin de manipuler les données d'un projet hébergé sur GitLab. Pour approfondir ce sujet, je vous recommande la lecture de cette page de la documentation officielle de GitLab.

The post Comment générer une paire de clés SSH et l’utiliser avec GitLab ? first appeared on IT-Connect.