En raison de la nouvelle politique de Twitter consistant à tester de nouvelles fonctionnalités en production, l’intérêt pour Mastodon en tant que remplaçant potentiel a explosé. Et qu’est-ce qu’il ne faut pas aimer ? Vous pouvez l’héberger vous-même, cela fait partie du Fediverse, et vous pouvez même exécuter l’un des forks expérimentaux pour plus de fonctionnalités. Mais il y a aussi le danger de mettre un service sur Internet, car [Gareth Heyes] illustre en volant les mots de passe de, ironiquement, l’instance infosec.exchange.
Chaque service qui permet à un utilisateur de saisir du texte, puis de montrer ce texte à d’autres utilisateurs, doit être renforcé contre les scripts intersites, XSS. C’est l’attaque où HTML ou Javascript peut être injecté dans l’expérience d’un autre utilisateur. Habituellement, ce durcissement est effectué avec un filtre qui assainit l’entrée de l’utilisateur. Les deux fonctionnalités qui peuvent provoquer ce problème sont les éléments HTML autorisés et les fonctionnalités d’analyse spéciales. Dans ce cas, cette fonctionnalité spéciale était l’icône « vérifiée » ironique que les utilisateurs pouvaient ajouter à leur nom d’affichage, en ajoutant un :verified: étiquette.
Mastodon remplace la balise par un HTML img bloc qui inclut des guillemets doubles pour afficher l’icône. Cela devient intéressant lorsque cette icône se trouve dans un champ HTML fourni par l’utilisateur, comme un <ABBR title="" étiquette. Les guillemets doubles de votre code ABBR ne correspondent pas aux guillemets doubles créés par l’icône vérifiée, et vous pouvez soudainement injecter toutes sortes de codes amusants. La porte n’est cependant pas grande ouverte, car Mastodon a une politique de sécurité du contenu (CSP) bien écrite. Il autorise les iframes, mais aucun autre contenu ne peut être chargé à partir de domaines extérieurs. Cela va à l’encontre de la plupart des attaques normales, mais [Gareth] avait un tour dans sa manche : des formes invisibles.
Les gestionnaires de mots de passe, comme celui intégré à Chrome, sont assez agressifs en ce qui concerne le remplissage automatique des formulaires, et il n’y a pas de vérification pour savoir si ces formulaires sont visibles. Le seul problème était de savoir comment soumettre le formulaire. Cela doit être une action initiée par l’utilisateur. La solution ici consiste à usurper un deuxième message et à simuler la barre d’outils entre les messages. Ce n’est pas un exploit parfait en 0 clic, mais les résultats sont assez convaincants.
[Gareth] signalé la faille à Mastodon et à la fourche Glitch, et les deux ont publié des correctifs pour atténuer les éléments de cette attaque, bien que le noyau Mastodon n’ait jamais été vulnérable car il ne permet pas le <ABBR title=""> attribut en premier lieu.
Pushwoosh
Il est assez courant qu’une entreprise soit enregistrée à un endroit et fasse physiquement des affaires à un autre. Aux États-Unis, le Delaware est un choix populaire pour le dépôt des statuts de société. C’est d’ailleurs la raison pour laquelle l’affaire Twitter contre Musk s’est déroulée devant la Cour de chancellerie du Delaware – Twitter est une société du Delaware. Quoi de moins casher est une entreprise basée dans un pays et prétend être basée dans un autre, sans trace écrite à divulguer. Et cela semble être exactement ce que fait Pushwoosh.
Ce serait une histoire relativement inintéressante, à l’exception du fait que Pushwoosh semble en fait être basé en Russie et a pris des contrats pour faire du travail avec le DoD. Il semble que certaines manipulations de données se produisent sur les serveurs Pushwoosh, y compris la collecte de données de géolocalisation. Il n’est pas clair que quoi que ce soit de malveillant se produise, mais ce n’est pas un risque que le gouvernement américain est prêt à prendre.
Shufflecake apporte le déni
Vous vous souvenez de Truecrypt ? C’était un logiciel de chiffrement de disque qui avait des fonctionnalités supplémentaires sophistiquées, comme des volumes cachés pour un déni plausible. Vous pouvez configurer un volume crypté qui afficherait un ensemble de fichiers avec un mot de passe, et un ensemble différent avec un autre. Le développement sur Truecrypt a été abandonné dans une étrange tournure des événements, il y a des années. Il y a maintenant un nouveau projet qui cherche à combler le vide de déni plausible, Shufflecake.
Il est open source, fonctionne comme un module de noyau Linux et un outil d’espace utilisateur, et prend en charge les volumes cachés imbriqués de 15 profondeurs. Le volume crypté est stocké dans l’espace inutilisé du périphérique bloc et est totalement indiscernable des bits aléatoires sur le disque. Le bit de déni plausible intervient lors du décryptage et du montage, car vous pouvez simplement décrypter le volume externe avec un seul mot de passe, et il est impossible de dire s’il existe des volumes supplémentaires, jusqu’à ce qu’un mot de passe valide soit donné.
F5 BIG-IP CSRF
[Ron Bowes] chez Rapid7 a des recherches amusantes qui réalisent l’exécution de code à distance sur les appareils F5 BIG-IP et BIG-IQ. Ce sont de puissants périphériques réseau qui façonnent le trafic à l’échelle des FAI, et ils exécutent CentOS sous le capot. Félicitations à F5 pour avoir bien fait, comme laisser SELinux activé, ce qui a apparemment rendu l’exploitation beaucoup plus difficile. Le problème est un point de terminaison d’API qui ne dispose pas de protections CSRF (Cross-Site Request Forgery), et ces points de terminaison peuvent être appelés à partir d’un script exécuté sur une page Web visitée. L’attaque consiste à inciter un administrateur à charger une telle page, puis à détourner le cookie de session existant pour appeler l’API.
Pour pivoter vers l’exécution du code, un générateur de spécification RPM est abusé, et un %check la commande est injectée. Ceci est utilisé dans les packages RPM légitimes pour lancer des tests post-installation, mais ici est utilisé pour lancer un webshell. Quelques autres faiblesses sont enchaînées pour accéder à l’accès au niveau racine. La recherche a été signalée à F5 et des correctifs ont été publiés cette semaine.
Pixel 6 parties deux et trois
Nous avons couvert la première et la deuxième partie de cette histoire, mais pour boucler la boucle, la troisième partie est maintenant disponible, dans l’histoire de la façon dont le chargeur de démarrage Pixel 6 a été fissuré. Le premier obstacle ici était de trouver une section de mémoire marquée lisible, inscriptible et exécutable. Ensuite, obtenir un shellcode qui s’exécutera réellement dans cet environnement est un peu difficile, mais seul l’assistant d’écriture du makefile génère le code nécessaire. L’ensemble de trois messages est une excellente introduction sur la façon de casser les chargeurs de démarrage Android.
