Pour commencer notre semaine de vulnérabilités dans tout, il y a une vulnérabilité potentiellement importante dans les combinés Android, mais c’est la faute d’Apple. OK, c’est peut-être un peu dur – Apple a publié le code de son Apple Lossless Audio Codec (ALAC) en 2011 sous la licence Apache. Ce code a été récupéré et expédié dans le cadre de la pile de pilotes pour plusieurs appareils par divers fournisseurs, notamment Qualcomm et MediaTek. Le problème est que le code d’Apple était terrible, un chercheur l’appelant une « passoire ambulante » de problèmes de sécurité.
Apple a corrigé son code en interne au fil des ans, mais n’a jamais poussé ces mises à jour vers la base de code publique. C’est une version source à feu et à oublier, et cela peut causer des problèmes comme celui-ci. Le fait que l’ALAC ait été publié sous une licence permissive peut contribuer au problème. Quelqu’un (en plus d’Apple) a probablement trouvé et corrigé les problèmes de sécurité, mais la licence permissive ne nécessite pas de partager ces correctifs avec une communauté plus large. Cela vaut la peine de se demander si une licence Copyleft comme la GPL aurait obtenu un correctif distribué il y a des années.
Quoi qu’il en soit, CVE-2021-0674 et CVE-2021-0675 ont été corrigés dans les mises à jour de sécurité de Qualcomm et MediaTek de décembre 2021. Ces vulnérabilités sont déclenchées par des fichiers audio malveillants et peuvent entraîner des RCE. Une application pourrait utiliser cette astuce pour échapper au bac à sable et augmenter les privilèges. Ce type de faille a été utilisé par des acteurs comme le groupe NSO pour compromettre des appareils via des applications de messagerie.
Nimbuspwn
Les chercheurs de Microsoft se sont penchés sur D-Bus et les différents démons qui l’écoutent. C’est intéressant, car beaucoup de ces démons s’exécutent en tant que root, mais un programme non root peut appeler D-Bus. Il semble probable qu’une interaction involontaire puisse entraîner des problèmes de sécurité. Juste au bon moment, une paire de problèmes dans networkd-dispatcher peuvent être chaînés pour élever les privilèges de l’utilisateur à la racine. Les problèmes ont été résolus en networkd-dispatcher version 2.2, recherchez donc au moins cette version sur votre distribution Linux.
CVE-2022-29799 et CVE-2022-29800 sont les deux failles, la première étant une faille de traversée de répertoire. Un message peut être envoyé, définissant un champ d’état sur un nom de répertoire comme ../../maliciousScripts/. La seconde est une faille TOCTOU (time-of-check-time-of-use), où un script est vérifié comme étant contrôlé par root, mais l’exécution n’est pas lancée immédiatement. Étant donné que les liens symboliques peuvent être utilisés dans ces répertoires, l’astuce consiste à configurer des liens symboliques vers ce qui semble être des scripts correctement sécurisés, et une fois la vérification effectuée, basculez le lien vers les scripts contrôlés par l’attaquant.
Via Ars Technica
VirusTotal a été totalisé
La gestion des logiciels malveillants en direct est délicate, et la gestion d’un site public dédié à la recherche sur la sécurité a tendance à attirer à la fois la bonne et la mauvaise attention. Dans ce cas, ce sont des collègues chercheurs en sécurité qui ont découvert que VirusTotal était vulnérable aux attaques. La faille était CVE-2021-22204, une vulnérabilité dans exiftool. VirusTotal l’utilise dans le cadre de sa fonction d’analyse de fichiers et n’a pas encore intégré les correctifs. Il était simple d’intégrer la commande malveillante et de soumettre le fichier pour analyse. Au fur et à mesure que les hôtes individuels travaillaient sur l’échantillon de malware, ils ont frappé l’exploit et renvoyé des shells inversés aux chercheurs. Une victoire totale. Après avoir confirmé qu’ils avaient effectivement touché la terre, les chercheurs de Cysrc ont transmis leurs découvertes à Google, qui exécute VirusTotal, et le binaire vulnérable a depuis été mis à jour.
Oui, je suis d’accord, qu’est-ce qui pourrait mal tourner ?
Lisez-vous les contrats de licence utilisateur final des applications que vous installez ? Avez-vous déjà trouvé le CLUF si onéreux que vous avez refusé d’accepter ? Nous pourrions tous vouloir perdre l’habitude d’accepter sans réfléchir les conditions d’utilisation. Beaucoup de ces applications utilisent des données de localisation GPS, et bon nombre de ces CLUF précisent que vos données de localisation peuvent être vendues à des annonceurs. Les données sont « anonymisées », ce qui signifie simplement qu’au lieu de noms ou d’adresses e-mail, les données de localisation sont liées à des identifiants numériques pseudo-aléatoires. Personne ne se donnerait la peine d’obtenir vos données et de dévoiler votre identité, n’est-ce pas ? À droite?
Selon The Intercept, deux sociétés de renseignement ont ingéré en masse des données de localisation et automatisé le processus de désanonymisation. Combien de personnes ont leurs données prises dans cette version réelle de The Machine ? Quelque chose comme trois milliards d’appareils. Ouais.
Donc à propos de ce Pentest…
Les exercices de l’équipe rouge sont à l’origine de certaines des histoires de sécurité les plus impressionnantes. Comment une équipe décousue a surmonté l’adversité pour réussir le hack ultime est l’étoffe des légendes. (Sérieusement, allez regarder à nouveau Sneakers.) Mais que se passe-t-il lorsque vous faites tout ce travail, essayez plusieurs approches et ne réussissez toujours pas une brèche ?
C’était la question [DiabloHorn] réfléchi, avec quelques bonnes directives pour aider chacun d’entre nous dans cette situation délicate. La première tâche consiste à demander, qu’est-ce qui a conduit à un résultat nul ? Le test était-il trop limité ? Trop de restrictions sur les techniques ? Pas assez de temps accordé ? Ce sont toutes de bonnes informations à signaler, de sorte que le prochain test peut être plus rentable. De plus, qu’est-ce qui a fonctionné ? Si le code utilisé était à l’épreuve des balles grâce à une très bonne suite de tests avec un fuzzing déjà en cours, c’est aussi une bonne information. L’ensemble de la rédaction est un exercice stimulant, même pour le reste d’entre nous, qui essayons simplement de rester en sécurité.
Signatures psychiques (suite)
La semaine dernière, nous avons présenté l’histoire de Java Psychic Signatures, et moins d’une semaine plus tard, il y a une preuve de concept particulièrement amusante à examiner : Breaking TLS. Étant donné que l’implémentation défectueuse peut être utilisée pour sécuriser le trafic HTTPS via TLS, cela signifie qu’un serveur malveillant peut s’authentifier comme n’importe quel hôte souhaité. Il semble que cela irait également à l’encontre du HSTS et de l’agrafage des certificats. L’attaque s’étend également aux attaques Man-in-the-Middle. N’oubliez pas que cette vulnérabilité ne s’applique qu’aux clients Java qui n’ont pas été mis à jour. Voir la couverture de la semaine dernière pour plus d’informations.
