Le système d’authentification RADIUS, abréviation de « Remote Authentication Dial-In User Service », a été largement déployé pour l’authentification des utilisateurs dans toutes sortes de scénarios. Il est un peu étrange, dans la mesure où les utilisateurs individuels s’authentifient auprès d’un « client RADIUS », parfois appelé serveur d’accès réseau (NAS). En réponse à une demande d’authentification, un NAS regroupe les détails d’authentification et les envoie à un serveur RADIUS central pour vérification. Le serveur renvoie ensuite un jugement sur la demande d’authentification et, en cas de succès, l’utilisateur est authentifié auprès du NAS/client.
Le schéma a été mis à jour dans sa forme actuelle en 1994, à l’époque où MD5 était considéré comme un hachage cryptographiquement bon. Il a été démontré que MD5 présente des problèmes, notamment une attaque par collision de préfixe choisi démontrée en 2007. Le principe de cette attaque par collision est que, étant donné deux messages arbitraires, il est possible de trouver une paire de valeurs qui, une fois ajoutées à la fin de ces messages, donnent lieu à des hachages md5 correspondants pour chaque message combiné. Il s’avère que cela est directement applicable à RADIUS.
L’attaque est de type « man-in-the-middle », mais pas contre un utilisateur en cours d’authentification. Cette attaque est de type « man-in-the-middle » entre le NAS et le serveur RADIUS, et un véritable utilisateur n’est même pas nécessaire. Cette position élevée rend une attaque plus difficile à réaliser dans certains cas, mais des situations telles que RADIUS fournissant une authentification pour l’accès administratif à un périphérique sont tout à fait concernées. L’encapsulation des communications back-end RADIUS dans une couche TLS protège contre l’attaque.
Gitlab
Il est à nouveau temps de mettre à jour vos instances Gitlab, et celle-ci vous semble familière. Il s’agit d’un autre problème où un attaquant pourrait exécuter des tâches de pipeline en tant qu’utilisateur arbitraire. Il s’agit d’un autre problème dans Gitlab, dont au moins un est exploité dans la nature. Il n’est pas surprenant de voir une vulnérabilité à haute visibilité conduire à la découverte de plusieurs autres problèmes similaires. Ce dernier problème étant si similaire au problème de pipeline précédent, il est possible qu’il s’agisse en fait d’un correctif incomplet ou d’une solution de contournement supplémentaire découverte pour exploiter le même problème.
Exim
Il existe un bug dans le serveur de messagerie Exim, qui affecte le traitement des règles de blocage des pièces jointes. Plus précisément, le nom de fichier dans l’en-tête du courrier électronique est divisé en plusieurs parties, avec quelques octets supplémentaires déroutants entre les deux. Il est techniquement conforme à la bonne RFC, mais le code de gestion MIME d’Exim est confus et ne parvient pas à trouver le bon nom de message.
Le serveur Exim peut être configuré pour bloquer certains types de fichiers, et cette vulnérabilité permet le passage de ces pièces jointes bloquées. Le CVSS original de la version 9.1 est un peu fou. La dernière mise à jour le ramène à la version 5.4, qui semble beaucoup plus appropriée.
Plomberie de votre ORM
Prisma est un ORM (Object Relational Mapper) de nouvelle génération, qui prend le schéma d’une base de données et le met en correspondance avec des objets de code. En d’autres termes, il permet d’écrire du code qui interagit avec une base de données. Il existe ici quelques problèmes potentiels, comme l’utilisation de filtres sur des données protégées, pour divulguer des informations un octet à la fois, de manière très hollywoodienne.
Cela nous amène à une deuxième approche, une fuite de données basée sur le temps. Ici, une requête SQL s’exécutera lentement ou rapidement en fonction des données de la base de données. L’outil plormber est conçu pour créer facilement des tentatives de fuites basées sur le temps. D’où le jeu de mots. Si vous avez une fuite dans votre ORM, appelez un plORMber. *soupir*
Internet Explorer se relève à nouveau
Lorsque Microsoft a finalement rendu Internet Explorer obsolète en 2022, j’avais un peu d’espoir que cela ne soit plus la cause de problèmes de sécurité. Et pourtant, nous voici, en 2024, à parler d’une campagne d’exploitation qui a utilisé une faille 0-day dans Windows pour lancer Internet Explorer.
Une extension de fichier très étrange, .pdf.urlparvient à apparaître sous forme de fichier PDF avec l’icône appropriée, et pourtant ouvre IE lorsqu’il est exécuté. Cela a finalement été classé par Microsoft comme une vulnérabilité et corrigé.
Bits et octets
Il y a un autre problème SSH, lié à regreSSHion. Cette fois, un correctif du fournisseur fait un appel à cleanup_exit() à partir d’une fonction de gestion de signal, appelant plus de code non sécurisé asynchrone. Si cela n’a aucun sens, revenez à l’article de la semaine dernière pour plus de détails. Cette fois, ce sont Fedora, Red Hat et d’autres distributions qui ont utilisé le correctif.
L’une des barrières de sécurité sur lesquelles la plupart d’entre nous comptent est que le trafic provenant du côté WAN du routeur doit y rester. Lorsque ce paradigme s’effondre, nous avons des problèmes. Et c’est exactement ce que les gens de Claroty s’efforcent de vaincre. L’astuce cette fois-ci est une vulnérabilité dans le service DNS dynamique d’un routeur. Parvenez à usurper une recherche DNS ou à utiliser MitM cette connexion, et soudain, c’est RCE sur le routeur.
Et enfin, nous avons couvert deux histoires remarquables cette semaine ici sur Hackaday. Vous devriez aller lire comment l’application Ticketmaster a été conçue à rebours, suivie d’un plan brillant et complètement impraticable pour obtenir votre connexion Internet gratuitement pendant votre vol.
