PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Les pirates d’ArcaneDoor ont compromis les firewalls Cisco pour accéder à des réseaux gouvernementaux !

jeudi 25 avril 2024 à 10:50

Depuis novembre 2023, un groupe de pirates exploite 2 failles de sécurité zero-day présentes dans les firewalls Cisco pour compromettre des infrastructures gouvernementales dans le monde entier. Faisons le point sur cette menace.

Si vous utilisez un firewall Cisco ASA (Adaptive Security Appliance ou Cisco FTD (Firepower Threat Defense), vous devriez lire cette alerte de sécurité avec une attention particulière. Un groupe de pirates, traqués sous le nom UAT4356 par Cisco Talos, et STORM-1849 par Microsoft, a compromis des firewalls vulnérables au début du mois de novembre 2023, dans le cadre d'une campagne de cyberespionnage baptisée "ArcaneDoor".

Dans le cadre de ces attaques, le groupe de pirates a exploité deux vulnérabilités en tant que failles de sécurité zero-day :

Ce n'est qu'en janvier 2024 que Cisco a pris connaissance de la campagne ArcaneDoor. Mais, d'après les chercheurs en sécurité de chez Cisco, les attaquants ont développé et testé des exploits pour ces deux failles zero-day en juillet 2023. Le vecteur d'attaque initial reste inconnu à ce jour.

Sur les appareils Cisco compromis et sur lesquels ils avaient la main, les pirates ont déployé des logiciels malveillants inconnus jusqu'ici. Le premier implant se nomme "Line Dancer" et il permet d'exécuter du code en mémoire pour désactiver la journalisation, activer l'accès distant ou encore exfiltrer les paquets capturés.

Le second implant se nomme "Line Runner" et il s'agit d'une porte dérobée persistante permettant l'exécution de code Lua sur les équipements, tout en étant discret et difficilement détectable.

Dans le rapport de Cisco Talos, nous pouvons lire : "UAT4356 a déployé deux portes dérobées dans le cadre de cette campagne, "Line Runner" et "Line Dancer", qui ont été utilisées collectivement pour mener des actions malveillantes sur la cible, notamment la modification de la configuration, la reconnaissance, la capture/exfiltration du trafic réseau et, éventuellement, le déplacement latéral."

Cisco a publié des correctifs de sécurité

Cisco a mis en ligne des correctifs de sécurité pour permettre aux entreprises de se protéger de ces failles de sécurité importantes, déjà exploitées dans le cadre de la campagne de cyberespionnage menée par le groupe UAT4356.

"Cisco recommande vivement à tous ses clients d'effectuer une mise à niveau vers les versions logicielles patchées.", peut-on lire sur le site de Cisco.

En complément de l'installation du correctif de sécurité, Cisco vous recommande de surveiller les journaux de système à la recherche d'une activité suspecte. Il peut s'agir d'un redémarrage non programmé de l'appareil, d'un changement de configuration ou encore de connexions suspectes.

Source

The post Les pirates d’ArcaneDoor ont compromis les firewalls Cisco pour accéder à des réseaux gouvernementaux ! first appeared on IT-Connect.

Pendant 5 ans, la Chine a espionné le groupe Volkswagen : 19 000 documents ont été volés !

mercredi 24 avril 2024 à 17:20

Pendant 5 ans, des hackers sponsorisés par l'État chinois ont espionné le groupe automobile Volkswagen ! Pendant cette période, ils ont dérobé des milliers de documents confidentiels au sujet des futurs véhicules électriques de la marque, mais pas seulement...

19 000, c'est le nombre de documents qu'est parvenu à dérober un groupe de hackers, entre 2010 et 2015. Cette information a été révélée il y a quelques jours grâce à des journalistes allemands parvenus à obtenir des documents internes évoquant cet espionnage important. Pour être plus précis, le 20 avril 2024, les médias allemands ZDF et Der Spiegel ont publié des articles à ce sujet.

Un groupe de hackers lié à la Chine ?

Même si la Chine n'est pas directement accusée de cet acte de cyberespionnage, tout porte à croire qu'elle en est à l'origine. En effet, il y a plusieurs indices qui vont dans ce sens, notamment la méthodologie employée par les hackers et le fait que les adresses IP utilisées par les pirates soient associées à la Chine. Bien qu'il n'y ait pas de preuve réelle, voici ce que l'on peut lire dans l'article du média ZDF : "Nous avons pu remonter l'adresse IP jusqu'à Pékin, et même jusqu'à l'Armée populaire de libération (APL)."

Par ailleurs, les hackers ont utilisé deux logiciels espions habituellement utilisés par les acteurs étatiques chinois : "China Chopper" et "PlugX". Par exemple, China Chopper est un web shell découvert pour la première fois en 2012 et utilisé pour obtenir la persistance sur un système compromis.

À quoi correspondent les documents volés ?

Au total, les pirates auraient volé environ 19 000 documents. Mais, alors, à quoi correspondent-ils ? Au-delà des informations au sujet des véhicules électriques de Volkswagen, les pirates ont mis la main sur d'autres documents, car ce n'était pas leur cible initiale. Parmi les objectifs identifiés des hackers, il y avait :

Par ailleurs, des documents relatifs aux boites de vitesses automatiques, aux travaux effectués sur les piles à combustibles ou encore l'e-Mobilité, ont été dérobés par les hackers.

Cette affaire est clairement de l'espionnage industriel et les documents volés ont pu participer à donner un avantage concurrentiel à la Chine, si elle est bien à l'origine de cette attaque. Ceci est d'autant plus vrai que le groupe Volkswagen comprend également d'autres marques comme Audi, Lamborghini, MAN, Porsche, Skoda et Bentley.

Source

The post Pendant 5 ans, la Chine a espionné le groupe Volkswagen : 19 000 documents ont été volés ! first appeared on IT-Connect.

Hack the box – Sherlocks (forensic) : découverte et solution de Litter

mercredi 24 avril 2024 à 10:00

I. Présentation

Je vous propose dans cet article un writeup du Sherlocks Litter proposé par Hack The Box. Cette investigation nous permettra notamment de manipuler Wireshark pour explorer un cas de protocol tunneling via le DNS : une technique utilisée pour faire communiquer discrètement un système compromis avec le serveur de contrôle distant d'un attaquant.

Les Sherlocks sont des challenges d'investigation numérique/forensic mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Litter, de difficulté "Facile". Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et des analystes en cybersécurité.

Lien du challenge : Hack The Box - Sherlocks - Litter

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

Technologies abordéesWindows, DNS, protocol tunneling
Outils utilisésWireshark, python

Retrouvez tous nos articles Hack The Box via ce lien :

II. Découverte de l'archive

Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :

D'après les éléments de contexte qui nous sont fournis, l'hôte ciblé semble être utilisé pour tout et n'importe quoi et par n'importe qui. Cela ne va certainement pas nous aider à comprendre ce qui est légitime de ce qui ne l'est pas. Également, nous apprenons que des données de l'entreprise y ont été volées.

Nous commençons donc par ouvrir l'archive à sur notre Kali Purple fraîchement installée. À l'intérieur, un fichier Wireshark, un célèbre outil d'analyse réseau :

III. Investigation numérique : le cas Litter

A. Tâche n°1: Identifier le protocole utilisé

La première tâche consiste à identifier le protocole qui semble avoir été utilisé pour la réalisation de l'attaque. Wireshark nous permet d'avoir des statistiques intéressantes concernant la volumétrie des protocoles au sein d'un même fichier ".pcap" :

Si l'on cherche les protocoles les plus utilisés, 4 candidats sont intéressants : les protocoles UDP "QUIC IETF" et "DNS", ainsi que les protocoles TCP "TLS" et "HTTP".

Après quelques recherches, je comprends que QUIC IETF est censé être un "nouveau" protocole de transport (comme UDP ou TCP) : QUIC: A UDP-Based Multiplexed and Secure Transport. Intéressant, mais un peu trop obscure pour un challenge "facile". Il semble également complexe d'investiguer sur des échanges chiffrés TLS. Ce qui nous oriente sur deux candidats : HTTP ou DNS.

Si l'on effectue un filtre sur le protocole HTTP avec la fonctionnalité "Conversations" de Wireshark, nous pouvons très rapidement isoler les hôtes avec lesquels des échanges HTTP ont eu lieu :

On peut noter que l'adresse IP avec laquelle le serveur compromis a le plus discuté est "13.107.4.50". Les autres échanges comportent trop peu de paquets pour nous intéresser. Renseignons-nous sur cette adresse IP à l'aide de la commande "whois" :

Notre hôte compromis à interrogé un point d'entrée "/msdownload/" sur une adresse IP appartenant à Microsoft. De toute évidence, il s'agit d'échanges en rapport avec les mises à jour Windows.

Attention : dans la réalité, les attaquants peuvent héberger ou utiliser des services Microsoft/Cloud pour leurs actions malveillantes, ils profitent alors du crédit et de la confiance accordés à ces services/IP/plateformes par les blues team et les solutions de sécurité. Je pense notamment à l'hébergement de service C&C (Command and Control) par Azure ou l'utilisation de machines Azure compromises comme intermédiaires.

Exemple : T1567.002 - Exfiltration Over Web Service: Exfiltration to Cloud Storage

Il ne nous reste donc plus que le protocole DNS comme candidat !

B. Tâche n°2 : Identifier l'IP suspecte

Maintenant que nous savons quel protocole a principalement été utilisé (DNS), et bien que ce dernier nous paraisse inoffensif au premier abord, tentons d'identifier quelle est l'adresse IP suspecte. Nous pouvons ici à nouveau utiliser la fonctionnalité "Conversations" de Wireshark après avoir effectué un filtre sur le protocole DNS :

Nous pouvons clairement voir que l'une des adresses IP a beaucoup plus discuté que les autres au travers le protocole DNS. Il est d'ailleurs suspect en soi qu'un tel volume de paquet DNS ait été échangé, il s'agit d'un protocole d'ordinaire plutôt "léger" dans la mesure où seuls quelques éléments textes sont échangés.

L'adresse IP "192.168.157.145" est donc celle de notre suspect.

C. Tâche n°3 : une commande via DNS ?

Il est maintenant temps de s'intéresser au contenu de ces échanges DNS. Commençons par isoler les paquets en appliquant un filtre sur ce protocole et l'IP suspecte :

DNS && (ip.addr==192.168.157.144 && ip.addr==192.168.157.145)

Ces échanges paraissent pour le moins inhabituels. Les noms DNS sont la plupart du temps intelligibles, et ils ne sont jamais aussi long. Ici, ils semblent être constitués uniquement des alphabets suivants avec aucun mot intelligible à part "microsofto365.com" :

Voilà qui nous rappelle quelque chose : de l'hexadécimal. Je récupère au hasard une requête TXT et copie le contenu de la requête via la fonction Copy Value de WIreshark (pensez à bien faire un clic droit sur le champ exact à copier dans le paquet ciblé) :

Je tente ensuite de décoder l'hexadécimal à l'aide de l'outil en ligne "CyberChef".

Cyberchef se présente comme "The Cyber Swiss Army Knife", c'est un outil très pratique proposé par le GCHQ (services de renseignement britannique) qui permet d'encoder/décoder ou chiffrer/déchiffrer des données au sein d'une application web intuitive. Cela permet de tenter rapidement tout un tas de format de conversions, d'encodage/decodage ou d'algorithme de chiffrement sur des données sans saisir la moindre ligne de commande : https://gchq.github.io/CyberChef/

Si vous souhaite l'utiliser dans un contexte professionnel, je vous recommande son installation sur un de vos serveurs déconnectés d'internet pour l’investigation : https://github.com/gchq/CyberChef

La conversion "hexadecimal -> ASCII" nous donne donc un bout de texte intelligible !

L'attaquant est parvenu à utiliser le protocole DNS en tant que protocole d’encapsulation en vue d'envoyer des commandes au serveur compromis, puis de recevoir en retour le résultat. Cette technique est connue sous le nom de DNS protocol Tunneling et est référencée sur le site du MITRE : T1071.004 - Application Layer Protocol: DNS

Un C2, C&C, ou centre de commandement et de contrôle (en anglais, Command and Control), est un élément crucial dans le contexte des cyberattaques. C'est une infrastructure utilisée par les cybercriminels pour gérer et contrôler des systèmes compromis à distance. Les attaquants utilisent de nombreuses infrastructures, techniques et protocoles pour que les agents déployés sur les systèmes compromis des entreprises communiquent avec leur C2, le MITRE ATT&CK en référence un certain nombre : TA0011 - Command and Control

Il est à noter que, contrairement à ce que l'on pourrait penser, le nom de domaine microsofto365.com n'appartient pas à Microsoft, dans la réalité, personne ne possède ce nom de domaine :

Pour comprendre l'intégralité de l'échange, il faut donc isoler le nom DNS exact dans les requêtes et les réponses des paquets déjà isolés, supprimer les éléments parasites (les "." et le "microsofto365.com"), concaténer le tout puis effectuer une conversation hexadécimal vers ASCII, je ne pense pas parvenir à faire cela avec Wireshark, je suis donc passé par le script Python suivant :

#!/usr/bin/python3
import argparse
from scapy.all import rdpcap, DNSQR, DNSRR

def main(args) -> None:
  f = ""
  last = ""
  for p in rdpcap(args.file):
      if p.haslayer(DNSQR) and not p.haslayer(DNSRR) :
          if "microsofto365" in p[DNSQR].qname.decode('utf-8'):
              qry = p[DNSQR].qname.decode('utf-8').replace(args.domain,"").strip().split(".")


              qryStr = ''.join(qry)[4:]
              if len(qryStr) > 1:
                decoded_string = bytes.fromhex(qryStr).decode('utf-8', errors='replace')

                if (len(decoded_string) > 20) and last != decoded_string:
                  f += decoded_string
                last = decoded_string
  print(f)

if __name__ == '__main__':
  # create the top-level parser
  parser = argparse.ArgumentParser(prog='PROG')
  parser.add_argument("-f", '--file', help='.pcap filepath', required=True)
  parser.add_argument("-d", '--domain', help='top domain to remove (eg. attacker.com)', required=True)
  args = parser.parse_args()
  main(args)

J'ai notamment utilisé "scapy" pour isoler les échanges DNS concernant le nom de domaine "microsofto365.com". Des recherches sur le décodage des échanges "dnscat2" m'ont également renseigné sur le besoin de retirer les 4 premiers octets de chaque échange DNS (Analysis on Popular DNS Tunneling Tools), qui correspond à un marqueur spécifique permettant le suivi des sessions "DNScat" : inutile dans le cadre d'une conversion en texte donc. Suite à l'exécution du script :

python3 dnscat2text.py -f suspicious_traffic.pcap -d microsofto365.com

J'obtiens le résultat suivant :

Le résultat n'est pas parfait, mais nous pouvons tout de même comprendre les échanges et exécution de commande qui on eut lieu. On obtient notamment la première commande exécutée par l'attaquant suite au déploiement de sa backdoor : whoami.

D. Tâche n°4 : dnscat2

Maintenant que nous sommes parvenus à avoir l'échange client-serveur presque en clair, il nous est plus facile de comprendre les opérations réalisées par l'attaquant. Nous pouvons notamment identifier la version de dnscat utilisée dans le nom du binaire déposé par l'attaquant :

Nous savons donc que l'attaquant à utiliser "dnscat2" en version 0.07.

E. Tâche n°5 : un attaquant presque discret

L'attaquant aurait tenté de renommer son outil une fois déposé sur le système compromis, nous pouvons de nouveau facilement repérer ses tentatives dans les échanges client-serveur "dnscat2" décodés :

L'attaquant a renommé son binaire "dnscat2" en "win_installer.exe".

Le fait de changer le nom d'un outil malveillant avant de le déposer sur un système surveillé par une solution de sécurité (antivirus, EPP, EDR, etc.) correspond au TTP T1036.005 - Masquerading: Match Legitimate Name or Location. Cela vise à contourner les règles de détections basées sur des mots ou des noms caractéristiques d'outils malveillants ou les analyses manuelles. Les attaquants optent souvent pour des noms communs et connus pour tenter de contourner ses règles, par exemple, en renommant leur malware "firefox.exe", "teams.exe", etc. EPP/EDR et humains peuvent facilement se faire berner par ce genre d'opérations.

Il est à noter que changer le nom du binaire après son dépôt sur le système est moins utile en termes de discrétion. En effet, une bonne partie des solutions de sécurité vont analyser celui-ci et lever une alerte dès sa création sur le système et pas seulement lors de son exécution.

Cependant, ce type de renommage peut être utile dans le cadre d'une persistance. En effet, un administrateur effectuant une analyse manuelle des processus en cours d'exécution ne prêtera pas attention à un processus win_installer.exe en cours d'exécution, alors qu'un processus "dns2cat.exe" l'interrogera un peu plus, le poussant à investiguer.

F. Tâche n°6 : Enumeration utilisateur

Il semblerait que l'attaquant ait tenté d'énumérer les fichiers Cloud depuis le système compromis. En effet, nous pouvons voir cette tentative :

Seulement le dossier "OneDrive" parcouru par l'attaquant ne contenait aucun fichier.

G. Tâches n°7 et 8 : fuite d'informations sensibles

Ces deux tâches peuvent être traitées en même temps. Il s'agit de retrouver le nom et le contenu du fichier sensible ayant été dérobé par l'attaquant. Il nous suffit de suivre le flux des échanges clients-serveur décodés jusqu'à trouver ceci :

Nous voyons que l'attaquant a consulté le fichier "C:\users\test\documents\client data optimisation\user details.csv" et que celui-ci contient des informations personnelles :

Ce fichier contient 721 lignes (le premier objet ayant l'identifiant 0), c'est donc le nombre de clients uniques contenu dans le fichier dérobé.

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons découvert que suite une compromission du système "desktop-umncbe7" par un vecteur non connu, l'attaquant a déposé un binaire sur le système, puis a utilisé le protocole DNS pour établir une communication directe entre son C2 et le système compromis. L'attaquant a effectué une brève recherche de fichiers sensibles sur le système et a récupéré les informations personnelles de 721 clients, incluant noms, prénoms, mails, adresses, numéros de téléphone, date de naissance, etc.

Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :

TTP (MITRE ATT&CK)Détails
T1583.001 - Acquire Infrastructure: DomainsAcquisition du nom de domaine microsofto365.com
T1583.002 - Acquire Infrastructure: DNS ServerMise en place d'un serveur DNS via un dnscat2 exposé sur Internet en vue de recevoir et de répondre aux requêtes du système compromis (client)
TA0002 - ExecutionCompromission de l'utilisateur test sur le système desktop-umncbe7 par un vecteur non connu
T1608.002 - Stage Capabilities: Upload ToolDépôt du binaire dnscat2
T1071.004 - Application Layer Protocol: DNSExécution du binaire dnscat2 et établissement d'un canal de communication encapsulé dans le protocole DNS
T1036.005 - Masquerading: Match Legitimate Name or LocationRenommage du binaire dnscat2 en win_installer.exe
T1083 - File and Directory DiscoveryRecherche dans le système de fichier du système compromis
T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 ProtocolAffichage et exfiltration du fichier "user details.csv" contenant les informations personnelles

V. Notions abordées

Nous allons à présent mettre en avant les principales notions et les apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :).

A. Côté analyste

Côté analyste, connaitre les outils et les méthodes des attaquants pour être discret et passer sous les radars est important. Ici, il est facile pour un analyste de passer à côté des flux DNS. La connaissance et le suivi actif des mises à jour des TTP du MITRE ATT&CK permet aux analystes de rester à jour sur les outils et techniques utilisés par les attaquants.

Il est à noter qu'en conditions réelles, le protocole DNS serait totalement noyé (en volume) par les autres protocoles, ce qui rendrait d'autant plus difficile cette investigation. Il serait peut-être intéressant de disposer d'un outil qui oriente les recherches de l'analyste, au moins sur les techniques connues et fréquemment utilisées et lors d'une analyse de formats connus et standardisés comme les fichiers PCAP. Une des fonctions de cet outil pourrait, par exemple, répondre à la question "est-ce qu'il existe des requêtes DNS portant sur des noms très long ?".

Nous avons également vu que la maitrise de Wireshark est importante et permet de gagner du temps sur les analyses de flux réseau. Notamment via les fonctions de statistique et les filtres.

Disposer d'une boite à outils pour se faciliter la vie est également important et c'est ce qu'apporte, entre autres, l'expérience et la formation. L'outil cyberchef est ici un incontournable, comme les outils capables d'identifier et d'extraire des informations concernant les noms de domaine. Il en va de même pour les méthodologies d'analyse. Je suis, par exemple, passé à côté du fait que le domaine microsofto365.com n'est pas un domaine officiel de Microsoft pendant toute l'analyse, car je n'ai pas fait la requête "whois" concernant ce nom de domaine immédiatement. Cela aurait pu m'induire en erreur (miser sur l'utilisation d'instances Cloud par l'attaquant par exemple).

B. Côté défense

Côté défense, il peut déjà être recommandé d'investiguer de façon plus approfondie sur les raisons de la compromission, élément qui est hors du périmètre de cette analyse.

Également, la mise en place de règles de détections basées sur un volume anormalement élevé de requête DNS ou la taille de noms de domaine peut être recommandé. Il faut savoir qu'un nom DNS a une taille maximale de 255 caractères :

Cependant, dans la réalité, il est très rare de croiser des noms de domaine dépassant 50 ou 60 caractères. J'ai d'ailleurs déjà croisé des solutions de sécurité basées sur l'analyse des flux réseau émettant une alerte de sécurité lorsqu'une requête ou réponse DNS concernant un nom de domaine trop long était identifiée.

La mise en place d'une solution de sécurité capable de détecter les outils malveillants que pourrait déposer un attaquant est également à recommander. Il est, par exemple, aisé de trouver des règles de détection SIGMA (utilisées par les EDR et IDS, entre autres) concernant le binaire ou les commandes PowerShell dnscat2 : Detection.fyi - Dnscat Execution

Il est difficile de proposer des améliorations concernant le nom de domaine utilisé par l'attaquant. Impossible de prévoir toutes les permutations DNS non enregistrées concernant Google, Microsoft ou autres Cloud provider. Si l'entreprise souhaite surveiller ses propres noms de domaine et être informé de l'enregistrement d'un nom de domaine ressemblant au sien par un attaquant, différents outils peuvent être utilisés :

C. Côté attaquant

Ici, nous sommes parvenus à décoder les échanges encapsulés dans le protocole DNS, car ceux-ci étaient simplement encodés en hexadécimal. Il faut savoir que dnscat2, l'outil utilisé par l'attaquant, possède une fonction permettant de chiffrer les échanges à l'aide d'une clé fixe avant transmission via le réseau. Il est alors plus complexe pour l'analyste de retrouver le contenu des échanges avec le C2.

Également, il pourrait être intéressant pour l'attaquant de renommer ses binaires malveillants avant dépôt sur le système, cela pour éviter qu'un éventuel antivirus, EPP ou EDR n'émette une alerte basée sur un terme surveillé dans les noms des fichiers ou des commandes.

V. Conclusion

J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis ! 🙂

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 – Sherlocks (forensic) : découverte et solution de Litter first appeared on IT-Connect.

En 2024, combien de temps faut-il pour casser un mot de passe ?

mercredi 24 avril 2024 à 08:51

L'entreprise Hive Systems a mis en ligne la nouvelle version de son étude permettant de connaître le temps nécessaire pour "brute forcer" un mot de passe, c'est-à-dire le casser, le deviner quoi ! Alors vos mots de passe sont-ils en vert ? Réponse dans cet article !

L'algorithme bcrypt et le matériel utilisé pour les tests

Avant d'évoquer les résultats et cette fameuse matrice "Password Table", évoquons la méthodologie utilisée par les équipes de Hive Systems. Jusqu'ici, les tests étaient effectués sur des hashs de mots de passe chiffrés avec l'algorithme MD5 : ce qui n'était pas cohérent et représentatif, car il est obsolète. Mais, si Hive Systems se basait sur cet algorithme, c'est parce qu'il était encore massivement utilisé. Désormais, la "Password Table" indique le temps qu'il faut pour casser un mot de passe chiffré avec bcrypt, et non md5.

"MD5 a régné en maître pendant plusieurs années, mais bcrypt a pris la tête en 2020, 2021, 2023 et, jusqu'à présent, en 2024.", ce qui justifie le fait de basculer de md5 vers bcrypt.

Le matériel utilisé reste le même entre cette édition 2024 et l'édition 2023 : 12 cartes graphiques (GPU) RTX 4090, ce qui représente une puissance très élevée ! Hive Systems estime a fait le choix de ce matériel, car c'est "la meilleure configuration matérielle accessible au grand public." - En complément, des résultats sont donnés pour des configurations beaucoup plus musclées basées sur des GPU A100, notamment utilisées pour l'IA.

Oubliez les mots de passe de 8 caractères

À partir de différentes configurations matérielles, d'une simple RTX 2080 à une configuration monstrueuse de 10 000 GPU A100 (ChatGPT), Hive Systems a essayé de casser des mots de passe de 8 caractères plus ou moins complexes, aussi bien avec le md5 que le bcrypt. Ces résultats prouvent que le bcrypt est plus robuste que le md5, mais il montre aussi les limites des mots de passe de 8 caractères.

Voici le comparatif, avec md5 au-dessus, et bcrypt en dessous :

Source : Hive Systems

La matrice Password Table de 2024

Alors, en 2024, combien de temps faut-il pour casser un mot de passe ? Bien entendu, cela dépend de la longueur de ce mot de passe et du type de caractère.

Pour être "dans le vert", selon la matrice d'Hive Systems, le mot de passe doit être d'au moins 13 caractères et utiliser 4 types de caractère (nombres, majuscules, minuscules et symboles) car il faudra 11 milliards d'années pour le casser. Il faudra surement beaucoup moins de temps avec du matériel encore plus performant.

Au-delà des types de caractère, cette matrice met en avant l'importance de la longueur des mots de passe. Un mot de passe de 14 caractères, avec uniquement des lettres minuscules et majuscules, sera cassé en 766 000 années. Pour utiliser seulement ces deux types de caractère et "être dans le vert", comptez 17 caractères minimum : c'est facilement atteignable avec une passphrase.

Voici la fameuse matrice de 2024 :

Combien de temps pour pirater un mot de passe en 2024

Vous pouvez accéder à l'étude complète et au téléchargement en haute définition de cette Password Table en visitant cette page.

Une nouvelle fois, ce type d'étude m'encourage à vous recommander l'utilisation de passphrases plutôt que de mots de passe.

Que pensez-vous de cette étude ?

The post En 2024, combien de temps faut-il pour casser un mot de passe ? first appeared on IT-Connect.

La mise à jour KB5036980 pour Windows 11 active les publicités dans le menu Démarrer !

mercredi 24 avril 2024 à 08:03

Le menu Démarrer de Windows 11 va accueillir des publicités pour mettre en avant des applications tierces. Ce changement est imminent, car il vient d'être ajouté par la mise à jour optionnelle d'avril 2024 : KB5036980. Faisons le point.

Après l'installation de la mise à jour KB5036980 sur Windows 11 23H2, le système passe sur la Build 22631.3527. Par ailleurs, si vous installez la même mise à jour sur Windows 11 22H2, le système passera sur la Build 22621.3527.

Le menu Démarrer de Windows 11 ne va pas lister uniquement vos documents et vos applications, il va aussi lister des applications tierces mises en avant par Microsoft. Il s'agit de publicités intégrées directement au menu Démarrer pour promouvoir les applications des entreprises ayant payé Microsoft pour cela. Par exemple, il y aura des publicités pour le navigateur Opera et 1Password Manager.

Peut-on éviter ce changement ?

Si vous n'installez pas la mise à jour KB5036980 sur votre PC, vous ne verrez pas de publicités dans le menu Démarrer de Windows 11. Enfin, pour le moment, car cette mise à jour donne un aperçu des changements à venir le mardi 14 mai 2024. Date à laquelle Microsoft va dévoiler son nouveau Patch Tuesday et publier les nouvelles mises à jour cumulatives mensuelles, qui elles sont obligatoires (et recommandées).

Ce changement était attendu, car Microsoft l'a déjà évoqué, mais il semble être déployé plus tôt que prévu. En effet, Microsoft devait activer l'affichage des publicités sur Windows 11 à partir de la fin du mois de mai (avec une mise à jour optionnelle), afin de les activer pour tout le monde avec la mise à jour cumulative de juin 2024. Microsoft a visiblement pris un mois d'avance sur son planning initial.

Néanmoins, bien que cette fonctionnalité soit activée par défaut, elle peut être désactivée dans les paramètres du système. Il conviendra de désactiver l'option nommée "Afficher des recommandations pour les conseils, les raccourcis, les nouvelles applications, etc." présente dans : Paramètres, Personnalisation, Démarrer.

Source

The post La mise à jour KB5036980 pour Windows 11 active les publicités dans le menu Démarrer ! first appeared on IT-Connect.