AccueilFacktualitéCette semaine en sécurité : Lastpass Takeaway, Bitcoin Loss et PyTorch

Cette semaine en sécurité : Lastpass Takeaway, Bitcoin Loss et PyTorch

Nous avons mentionné l’histoire de LastPass en terminant il y a quelques semaines, mais les détails étaient encore un peu rares. L’espoir était que LastPass publierait des informations plus transparentes sur ce qui s’était passé et sur le nombre de comptes consultés. Malheureusement, il semble que le communiqué de presse du 22 décembre soit tout ce que nous aurons. Pour les utilisateurs de LastPass, il est temps de prendre des décisions.

Pour récapituler, un attaquant a utilisé les informations de la violation d’août 2022 pour cibler un employé de LastPass avec un stratagème d’ingénierie sociale. Cela a réussi et l’attaquant a réussi à accéder aux sauvegardes LastPass, en particulier à une base de données de comptes clients et à des coffres-forts clients. Il n’y a pas eu de mot officiel sur le nombre de données d’utilisateurs incluses, mais l’indication est qu’il s’agissait de l’ensemble de données complet. Et pour aggraver les choses, le coffre-fort crypté n’est que partiellement crypté. Les URL enregistrées ont été exposées en texte brut à l’attaquant, bien que les noms d’utilisateur et les mots de passe soient toujours cryptés à l’aide de votre mot de passe principal.

Alors, que doit faire un utilisateur LastPass maintenant ? Ça dépend. Nous pouvons supposer que quiconque possède les données du coffre-fort LastPass y jette actuellement toutes les listes de mots de passe disponibles. Si vous avez utilisé un mot de passe faible – dérivé de mots dans n’importe quelle langue ou précédemment compromis – il est temps de changer tous vos mots de passe qui se trouvaient dans le coffre-fort. Ils sont brûlés.

Que vous vous en teniez à LastPass ou que vous passiez à une autre solution, ce n’est qu’une question de temps jusqu’à ce que votre coffre-fort soit fissuré. Pire encore, certains anciens comptes Lastpass n’utilisent que 5 000 tours de hachage PBKDF2 (Password-Based Key Derivation Function). Les nouveaux comptes sont configurés pour utiliser plus de 100 000 itérations, mais certains comptes plus anciens peuvent toujours utiliser l’ancien paramètre. Le résultat est qu’une attaque contre le coffre-fort chiffré s’exécute beaucoup plus rapidement. Le nombre d’itérations est presque certainement dans les données volées, donc ces comptes seront probablement testés en premier. Si vous êtes un utilisateur de longue date, modifiez tous les mots de passe stockés dans le coffre-fort.

Il y a quelques bonnes nouvelles. Les coffres utilisent un sel pour accompagner les mots de passe – des données supplémentaires qui sont intégrées à la fonction PBKDF2. Cela signifie que la procédure de craquage du mot de passe doit être effectuée individuellement par utilisateur. Si vous n’êtes qu’un autre utilisateur inintéressant, vous ne serez peut-être jamais ciblé pour le crack. Mais si vous êtes susceptible d’être intéressant ou si vous avez des URL qui semblent intéressantes, il y a probablement plus de chances d’être ciblé. Et malheureusement, il s’agissait de texte brut.

Alors, comment les maths s’empilent-elles? Heureusement pour nous, [Wladimir Palant] couru les chiffres pour nous. Un mot de passe de complexité minimale, utilisant les règles 2018 pour un mot de passe LastPass, donne 4,8 × 10 ^ 18 combinaisons de mots de passe possibles. Un RTX 4090 peut supporter environ 1,7 million de suppositions par seconde sur un compte utilisant seulement 5 000 itérations de PBKDF2, ou 88 000 suppositions par seconde sur un compte correctement sécurisé. Cela fait 44 800 ans et 860 000 ans pour ouvrir un coffre-fort, en supposant qu’un RTX4090 y travaille. Des calculs très approximatifs sur la taille d’un centre de données d’agence à trois lettres suggéreraient que consacrer l’intégralité de l’un de ces centres de données à la tâche fissurerait le coffre-fort le moins sécurisé en moins de 4 mois. Avec un compte utilisant les paramètres de sécurité complets, cela passe à près de six ans. Gardez à l’esprit que cette approche est le meilleur scénario pour un attaquant et représente le fait de consacrer un centre de données de 1,5 milliard de dollars à la tâche pendant une période prolongée. Mais cela suppose également que vous avez choisi votre mot de passe au hasard.

Mais voici le hic : si le risque est suffisant pour vous pousser à l’action, il ne suffit pas de changer votre mot de passe LastPass. Que vous restiez avec LastPass ou que vous passiez à une autre solution, vous devrez d’abord changer le mot de passe principal, puis passer par le processus exténuant de changement de chaque mot de passe dans votre coffre-fort LastPass. Tout ce gâchis était certainement un échec de la part de LastPass, et leur rapport post-incident laisse certainement une certaine transparence à désirer. Les URL non cryptées associées à chaque mot de passe enregistré sont regrettables. Mais le principe central, à savoir que même LastPass ne peut accéder à vos mots de passe enregistrés, semble avoir résisté.

Bitcoin Hacker piraté

Luke Dashjr est un développeur Bitcoin Core, le principal signataire du logiciel Bitcoin Knots, et a subi une faille de sécurité majeure. Il peut s’agir d’un incident consécutif à une attaque physique de novembre, où quelqu’un a réussi à redémarrer son serveur colocalisé à partir d’un lecteur flash et à installer une porte dérobée. Celui-ci a été capturé et le logiciel malveillant a apparemment été supprimé. Luke a perdu un total d’environ 200 bitcoins, sur ses portefeuilles actifs (chauds) et hors ligne (froids). Il traite cela comme un compromis total et a averti que sa clé PGP devrait également être suspecte. Cela signifie que les versions récentes de Bitcoin Knots devraient également être suspectes.

Plusieurs théories ont été avancées, allant d’un « accident de bateau » pour éviter l’impôt à payer, à un problème connu de génération de nombres aléatoires sur le système Talos qu’il utilise (CVE-2019-15847). Rien de tout cela ne semble aussi probable que l’idée qu’il s’agissait d’un rootkit manqué sur le serveur compromis et d’un retour latéral dans [Luke]réseau domestique. Quoi qu’il en soit, c’est un terrible gâchis, et nous espérons une résolution positive.

Compromis nocturne PyTorch

Le package PyTorch-nightly a été touché par une attaque de confusion de dépendance, active entre le 25 et le 30 décembre. Le problème ici est que PyTorch héberge un torchtriton package dans le cadre de son dépôt nocturne, et ce nom de package n’a pas été réclamé sur PyPi. Donc, tout ce que quelqu’un avait à faire était de télécharger un paquet sous ce nom, et hop, toute nouvelle installation pip de PyTorch-nightly a saisi la version PyPi. Le package malveillant aspire les données système, telles que les serveurs de noms actuels, le nom d’hôte, le nom d’utilisateur, le répertoire de travail et les variables d’environnement, et les envoie à h4ck[dot]cfd (lien d’archive). Ce bit n’est pas si mal, même si les variables d’environnement sont sûres d’inclure des jetons d’authentification. Le kicker est cette histoire bash, /etc/hosts, /etc/passwd, ~/.gitconfig, ~/.ssh, et les 1 000 premiers fichiers du répertoire personnel sont également tous empaquetés et téléchargés. Sur un système moderne, le passwd le fichier ne contient en fait aucun hachage de mot de passe, mais le .ssh dossier peut très bien contenir des clés SSH privées. Ouais.

Maintenant, le développeur derrière ce faux paquet a été trouvé et affirme qu’il s’agissait d’une recherche de sécurité et promet que toutes les données seront supprimées. Les données volées étaient censées servir à identifier positivement la victime, vraisemblablement dans le but de collecter des primes de bogues. Cela a un certain élément de crédibilité, mais n’a vraiment pas d’importance, car tout secret divulgué dans cet incident doit être révoqué malgré tout. La doublure argentée est qu’aucun code malveillant n’est exécuté simplement en installant le package, mais un script Python devrait faire un explicite import triton afin de déclencher la charge utile. Le projet PyTorch a renommé le package en pytorch-tritonet réservé ce nom de projet sur PyPi pour éviter un incident répété.

Mappage des installations Citrix vulnérables

Quelques vulnérabilités critiques ont été corrigées récemment dans Citrix ADC et Citrix Gateway, dont l’une a provoqué un avis de la NSA indiquant qu’un APT (Advanced Persistent Threat) compromettait activement les systèmes avec le bogue. Les numéros de version fixes sont connus, ce qui a incité les chercheurs de Fox It, qui fait partie du groupe NCC, à s’interroger. Existe-t-il un moyen de déterminer la version d’un appareil Citrix à partir de la réponse HTTP de pré-authentification ? Spoiler : Il y en a. Le /vpn/index.html le point de terminaison contient un hachage qui semble varier d’une version à l’autre. La seule astuce qui restait était de trouver un moyen rapide de mapper le hachage vers la version.

Entrez dans le Cloud Marketplace de Google, qui propose une option en un clic pour lancer une nouvelle machine virtuelle Citrix. Une session SSH a ensuite confirmé la version et le hachage correspondant. C’est un de moins. Le service de Google comprend également un fichier zip contenant des informations sur les anciennes versions, y compris les noms d’images pouvant être utilisés pour télécharger les versions précédentes en tant que qcow2 image de disque virtuel – assez facile pour récupérer le hachage et le numéro de version à partir de là. Entre ces images et la page de téléchargement de Citrix, un certain nombre de hachages connus ont été identifiés, mais étrangement, certains hachages observés dans la nature ne semblaient pas correspondre à une version connue. En trouvant un fichier spécifique en lecture seule qui est également accessible à distance, il est possible d’obtenir un horodatage précis sur le moment où un micrologiciel donné a été créé. Cela comble les lacunes des numéros de version connus et leur permet de déterminer exactement quelles versions apparaissaient dans la nature.

Étant donné que le hachage faisait partie des données collectées par des services d’analyse tels que Shodan, il est possible de consulter l’historique des versions installées, ainsi que l’état actuel. Il y a un changement très notable dans les versions déployées, correspondant bien à l’avertissement de la NSA. Même dans ce cas, de nombreux serveurs Citrix déployés semblent toujours exécuter un micrologiciel vulnérable, bien que les détails du déploiement puissent signifier qu’ils ne sont pas en danger imminent. C’est un regard très intéressant sur la façon dont nous nous retrouvons avec des statistiques comme celles-ci.

Bits et octets

Le serveur VPN de Synology présente une vulnérabilité critique, CVE-2022-43931, qui obtient un score CVSS de 10 et permet à un attaquant non authentifié d’exécuter des commandes arbitraires. Des versions corrigées sont disponibles. La faille elle-même est une écriture hors limites dans le service Bureau à distance, il y a donc un espoir que ce service vulnérable ne soit pas largement exposé à l’Internet ouvert.

Voici l’exploit dont vous ne saviez pas avoir besoin, sortir de l’interpréteur Lua pour obtenir l’exécution du shellcode. L’astuce ici est d’encoder le shellcode sous forme de nombres, puis de tromper le runtime en un accès non aligné, ce qui saute l’exécution du programme dans les données. Une autre astuce amusante est que l’interpréteur Lua cible vous permettra d’exécuter le bytecode Lua et de lui faire confiance comme le code Lua normal. Quel est donc le but de tout cela ? Parfois, le plaisir est dans le voyage.

Qu’obtenez-vous lorsque des chercheurs en sécurité ennuyés décident de fouiller dans l’application mobile pour scooters électriques ? Beaucoup de scooters qui klaxonnent et clignotent mystérieusement. Et quand ces mêmes chercheurs montent la barre et essaient de faire klaxonner les voitures ? Une liste vraiment impressionnante de vulnérabilités à distance dans les véhicules de toutes les marques. Du suivi GPS en direct à l’allumage des lumières, au déverrouillage des portes et même au démarrage à distance des véhicules, [Sam Curry] et sa bande de joyeux hackers l’ont fait. Au crédit des nombreux fournisseurs qui ont été touchés, à peu près toutes les vulnérabilités se terminent par « ils l’ont corrigé tout de suite ».

François Zipponi
François Zipponihttp://10-raisons.com/author/10raisons/
Je suis François Zipponi, éditorialiste pour le site 10-raisons.com. J'ai commencé ma carrière de journaliste en 2004, et j'ai travaillé pour plusieurs médias français, dont le Monde et Libération. En 2016, j'ai rejoint 10-raisons.com, un site innovant proposant des articles sous la forme « 10 raisons de... ». En tant qu'éditorialiste, je me suis engagé à fournir un contenu original et pertinent, abordant des sujets variés tels que la politique, l'économie, les sciences, l'histoire, etc. Je m'efforce de toujours traiter les sujets de façon objective et impartiale. Mes articles sont régulièrement partagés sur les réseaux sociaux et j'interviens dans des conférences et des tables rondes autour des thèmes abordés sur 10-raisons.com.

Articles récents