Pour chaque protocole de sécurité très intelligent qui assure la sécurité des personnes, il existe un piratage stupide qui le défait de manière inattendue. Prenez OAuth par exemple. C’est la technologie qu’utilisent les sites lorsqu’ils proposent de « se connecter avec Facebook ». C’est un excellent protocole, car il vous permet de prouver votre identité en utilisant un tiers de confiance. Vous n’avez pas besoin d’utiliser un mot de passe sur le site que vous essayez d’utiliser, il vous suffit d’être connecté à votre compte Google/Facebook/Apple et de cliquer sur le bouton pour autoriser l’accès. Si vous n’êtes pas connecté, la fenêtre contextuelle vous demande votre nom d’utilisateur et votre mot de passe, ce qui est bien sûr un moyen pour les attaques de phishing de voler les mots de passe. Nous disons donc aux gens de regarder l’URL et de s’assurer qu’ils se connectent réellement au bon site.
Le hack stupide qui n’est pas stupide, parce que ça marche : Recréer la fenêtre du navigateur en HTML/CSS. Oui, c’est assez simple d’ajouter un div à votre site et décorez-le pour qu’il ressemble à une fenêtre de navigateur, tout comme une fenêtre contextuelle OAuth. À l’endroit approprié, une iframe pointe vers le formulaire de phishing réel. Cela semble convaincant, mais une fois que vous êtes au courant du jeu, il y a un cadeau mort – essayez de déplacer la fenêtre OAuth en dehors de la fenêtre du navigateur qui l’a engendré. Les sites Web ne peuvent pas dessiner en dehors de la fenêtre du navigateur ou sur ses décorations de fenêtre, donc cette limitation permet de confirmer facilement si ce hack est en jeu. L’autre grâce salvatrice est qu’un gestionnaire de mots de passe n’est pas du tout dupe de cette astuce.
Par: Ars Technica
Typo-squattage à l’échelle
Il y a une campagne de typo-squatting en cours chez NPM, principalement destinée aux utilisateurs d’Azure. NPM dispose d’une fonctionnalité d’empaquetage appelée « paquets de portée ». Une étendue commence par le signe arobase et indique les packages intentionnellement regroupés. Dans ce cas, la portée est @azurey compris des forfaits comme @azure/core-tracing, avec plus de 1,5 million de téléchargements hebdomadaires. La faute de frappe ? Il suffit de laisser tomber la lunette. NPM considère qu’il est tout à fait acceptable d’avoir à la fois le @azure/core-tracing et core-tracing packages – en fait, c’est une fonctionnalité du système de portée. Mais oubliez d’inclure la portée et vous risquez d’obtenir un paquet malveillant à la place. Plus de 200 packages ont été ciblés de cette manière, mais ont depuis été retirés par NPM.
La charge utile était strictement de reconnaissance, saisissant des listes de répertoires, des adresses IP, etc. Il est probable que les informations soient utilisées pour créer des mises à jour futures plus malveillantes, bien qu’aucun comportement de ce type n’ait été observé. Cela est probablement dû à la rapidité avec laquelle ces colis ont été capturés et retirés – après seulement environ deux jours. Le domaine utilisé pour la collecte des données est 425a2.rt11.mlde sorte que cette chaîne apparaissant quelque part dans un journal DNS indique que l’un de ces packages a été installé.
Lapsus$ frappe encore, encore
La collection lâche de pirates informatiques sait que Lapsus $ a potentiellement marqué des brèches à la fois chez Microsoft et Okta. KrebsonSecurity a un peu plus d’informations sur le groupe et l’affaire Microsoft. Le groupe semble faire une partie de sa coordination sur une chaîne Telegram, qui est ouverte à tous. Le groupe s’est vanté de ses exploits sur ce canal, et les répondants de Microsoft ont trouvé et coupé leur accès lors de l’exfiltration des données. Un fichier de 10 Go a été publié contenant une source partielle pour la recherche Bing, Bing Maps et Cortana.
La situation d’Okta est encore plus trouble, car les captures d’écran publiées indiquent un accès fin janvier. L’accès semble avoir été limité à un portail administratif, via le compte d’un technicien de support. Okta a fait tout son possible pour assurer à tout le monde qu’il n’y avait pas de violation réelle, et l’accès malveillant a été rapidement traité. Cela semble être un peu malhonnête, car Lapsus $ était après les entreprises utilisant les services Okta et n’avait pas besoin de compromettre davantage leurs systèmes. Okta fournit la gestion des accès pour d’autres entreprises, comme Cloudflare. Il y a probablement eu une infiltration discrète dans les mois qui ont suivi.
Linux devient plus aléatoire
[Jason Donenfeld], hackeur du noyau et développeur principal de Wireguard, a récemment travaillé sur le générateur de nombres aléatoires Linux. Quelques changements ont atterri dans la version 5.17, et d’autres arrivent dans la 5.18. Il a eu la gentillesse d’écrire quelques-uns des changements intéressants pour notre éducation. Il considère que sa contribution la plus importante est la documentation. Je peux confirmer que l’un des problèmes les plus frustrants auxquels un programmeur peut être confronté est lorsque la documentation est devenue inutile.
L’un des changements les plus importants pour l’utilisateur a été la tentative d’unifier /dev/random et /dev/urandom. Nous disons tentative, car ce changement a provoqué plusieurs échecs de démarrage sur la configuration de test du noyau. Apparemment, certaines architectures, en particulier lorsqu’elles sont virtualisées, n’ont aucune méthode pour générer un caractère aléatoire de haute qualité lors du démarrage. La prochaine fonctionnalité qui tue est la nouvelle add_vmfork_randomness() call, qui permet à une machine virtuelle nouvellement clonée de demander une régénération de son pool aléatoire. Sans un appel comme celui-ci, les premiers nombres aléatoires générés par le noyau après un fork de VM seraient identiques – évidemment un problème.
En interne, le code aléatoire retire le vénérable algorithme SHA-1, le remplaçant par la fonction de hachage BLAKE2 plus moderne. Un avantage intéressant est que BLAKE2 est intentionnellement un algorithme très rapide, de sorte que le noyau gagne un peu en performances lors de la génération de nombres aléatoires. Le reste des changements se plongent dans des considérations de cryptographie plus compliquées. A lire absolument si cela vous intéresse.
Western Digital NAS RCE
Nous avons couvert de nombreuses vulnérabilités et attaques dans les boîtiers NAS de QNAP et Synology, mais cette semaine, c’est Western Digital qui se lance dans l’action. Heureusement, il s’agit d’une recherche du groupe NCC, démontrée à Pwn2Own 2021 et corrigée dans une mise à jour de janvier. Cette vulnérabilité d’exécution de code à distance (RCE) réside dans la manière dont le NAS gère le protocole Apple Filing Protocol (AFP) et constituait en fait un problème dans le projet Netatalk. AFP prend en charge le stockage des métadonnées de fichier dans un fichier séparé, par souci de compatibilité. Ces fichiers sont au format AppleDouble, prennent le nom de leur fichier parent, précédé d’un ._. Le plus important est que ces fichiers sont également accessibles à l’aide du protocole Windows SMB, permettant une manipulation directe du fichier de métadonnées. La fonction qui analyse le fichier de métadonnées détecte en effet une structure de données mal formée et enregistre une erreur à cet effet, mais échoue – elle continue et traite les mauvaises données.
Cette erreur continue est le défaut central, mais la création d’un exploit a nécessité une fuite de données pour vaincre la randomisation de la disposition des adresses en place sur l’appareil. Une première étape plus simple consistait à écrire des emplacements de mémoire dans le fichier AppleDouble et à utiliser l’accès SMB pour le lire. Avec l’adresse divulguée en main, l’exploit complet était facile. Ce serait déjà assez grave, mais ces appareils sont livrés avec un partage « Public » accessible dans le monde entier via SMB et AFP. Cette configuration en fait un RCE de pré-autorisation. Et cela démontre le but de Pwn2Own – il a été découvert, a rapporté un peu d’argent aux chercheurs et a été corrigé avant que les détails ne soient rendus publics.
