Avez-vous déjà pensé à toutes les complexités d’une implémentation d’authentification unique (SSO) ? De nombreux efforts d’ingénierie ont été déployés pour lutter contre les attaques intersites. Vous ne voudriez pas que chaque site que vous visitez puisse pirater votre compte Google ou Facebook. Dans le même temps, l’authentification unique est la capacité utile d’utiliser votre authentification sur un service pour vous authentifier auprès d’un site indépendant. Le SSO compromet-il jamais ce durcissement ? Si des erreurs sont commises, absolument, comme [Zemnmez] découvert en regardant le système Apple ID SSO.

Tout commence par le constat que icloud.com a une connexion qui parle à apple.com, deux domaines distincts. L’astuce sournoise utilisée pour que cela fonctionne est une iframe qui intègre la page de connexion Apple dans le icloud.com site. Il existe plusieurs mesures de sécurité destinées à empêcher les abus de ce site intégré. Le premier qui doit être surmonté est le Oauth2 redirect_uri est utilisé pour rechercher un domaine sur liste blanche, ainsi que pour définir le domaine autorisé pour le content-security-policy entête. En termes simples, l’attaque doit définir une seule chaîne qui semble être icloud.com au backend Oauth2, mais OurEvilSite.com au navigateur en vérifiant l’en-tête de la politique de sécurité. Comment ces pieds apparemment impossibles sont-ils accomplis? En abusant de l’extrême flexibilité inhérente à l’encodage URI. https://OurEvilSite.com;@icloud.com Les deux mécanismes de sécurité différents le comprennent différemment, permettant l’intégration.

Le prochain problème à résoudre est que l’iframe intégré transmet des messages dans les deux sens avec le icloud.com page, et rien ne se passe si cette poignée de main ne se termine pas. Cette poignée de main peut être falsifiée assez facilement, à l’exception d’un détail mineur. Le domaine est spécifié à nouveau, sur la base de ce même redirect_uri. L’astuce ici est de réaliser que cet URI passe par le decodeURIComponent fonctionner deux fois, à différents moments du processus de chargement de la page. Le double codage d’un point d’interrogation permet la supercherie supplémentaire nécessaire, contrôlant ce que voit ce contrôle de sécurité.

Le dernier obstacle à surmonter est la vérification de l’origine du message, une fonction de sécurité similaire. Plutôt qu’une attaque d’analyseur intelligent, cela est surmonté par une autre échappatoire. Si la source du message est NULL, cette vérification n’a jamais lieu. Le moyen d’y parvenir ? Laissez le allow-same-origin drapeau. Cela crée un iframe qui est partiellement en bac à sable du reste de la page. Cela semble inutile? La solution consiste à intégrer les deux iframes dans la page de l’attaquant et à transmettre les messages à travers le cadre qui a l’autorisation de le faire. Avec cette combinaison folle, un attaquant peut réussir à intégrer le apple.com widget de connexion sur leur propre page.

Je sais ce que tu penses. Et alors? Il suffit d’extraire le HTML, le CSS et les images de cet iframe, et vous pouvez le répliquer vous-même sans aucun problème supplémentaire. Une vulnérabilité de plus transforme cette attaque en quelque chose de vraiment impressionnant. Pour le comprendre, vous devez d’abord comprendre la bibliothèque JavaScript du guidon pour les modèles HTML. Cette bibliothèque vous permet d’écrire votre modèle de page et d’inclure {{someObject}} expressions. Vous exécutez ensuite le modèle en spécifiant les données appelées par les expressions. La page apple.com SSO utilise cette bibliothèque pour afficher des informations personnalisées à partir de la page d’appel, telles que des informations de confidentialité, etc.

La bibliothèque de guidon a un type spécial d’expression, {{{the triple handlebar}}}, qui permet une insertion HTML dangereuse. Rassemblez-le et vous pouvez créer un bouton « Se connecter avec Apple » valide qui redirige l’utilisateur vers Apple idmsa.apple.com page, mais injecter du code arbitraire sur cette page. Consultez la démo ci-dessous pour les marchandises.

Hacktivisme et Iran

Le bureau s'est bloqué au démarrage, affichant un message en arabe.
« Nous avons attaqué les systèmes informatiques de la Compagnie des chemins de fer et du ministère des Routes et de l’Urbanisme »

Checkpoint Research nous apporte un rapport sur les récentes cyberattaques contre les infrastructures de transport iraniennes. L’attaque a utilisé Active Directory pour déployer la charge utile sur les ordinateurs connectés, qui ont été effacés puis modifiés pour se bloquer lors du démarrage, affichant un message des attaquants. L’objectif semble être la perturbation du système de transport, et il y avait une exception intelligente codée dans le programme d’essuie-glace. Les machines portant une poignée de noms d’hôtes contenant « PIS » ont été automatiquement ignorées. Cet acronyme signifie « Système d’information sur les passagers » – les grands panneaux d’affichage numériques indiquant l’état et les retards. Les attaquants voulaient que les passagers en attente puissent voir exactement à quel point le système était affecté.

Checkpoint pense qu’il s’agit des mêmes acteurs qu’une attaque précédente contre l’Iran et de deux incidents contre des cibles en Syrie. Le nom autoproclamé est Indra, du nom d’un dieu hindou de la guerre. Pour ceux d’entre nous qui ne sont pas au courant de la théologie hindoue, Indra pourrait être considéré comme un personnage similaire à Thor. Le groupe prétend être essentiellement des hacktivistes contre l’Iran et son financement des groupes terroristes. Bien qu’Indra n’ait pas revendiqué la responsabilité de la dernière attaque, Checkpoint fait du bon travail en faisant valoir que la même attaque est utilisée.

CVE Sluething — Et les bizarreries de Perl

[Justin Kennedy] d’Atredis était au milieu d’un exercice d’équipe rouge, et il est tombé sur l’appliance de gestion des menaces Sophos UTM9. Cette installation particulière n’avait pas été mise à jour pour atténuer CVE-2020-25223, un RCE de pré-authentification. C’était une grande pause pour démontrer une attaque contre le client, mais il y avait un petit problème. Ce CVE n’a jamais été entièrement divulgué, et personne ne semblait avoir les détails de son exploitation. Il a récupéré une paire d’ISO d’installation et a exécuté des instances virtualisées de l’appliance vulnérable et corrigée. Faire une différence sur les deux versions serait facile sur certains systèmes, mais ceux-ci utilisent quelques astuces pour obscurcir le code. Tout d’abord, le Perl est compilé dans plx binaires. Cela peut être surmonté en utilisant un débogueur et en copiant le script désobscurci à partir de la mémoire. Le deuxième problème était que les modules Perl qui font le gros du travail ne faisaient pas partie de ce code récupéré. Un collègue ingénieur chez Atredis a découvert que les modules nécessaires étaient en fait cachés dans un système de fichiers BFS, ajouté à la fin du serveur Web plx. Maintenant, avec la source Perl originale en main, il pouvait se lancer dans les affaires.

Il y a eu un seul changement dans le code lui-même, une regex Perl ajoutée dans asg_connector.pm, qui a vérifié un SID entrant (ID de session) et l’a potentiellement rejeté comme non valide. Maintenant, l’expression régulière Perl a la réputation d’être lourde et difficile à analyser pour les humains. Et ceci est un exemple de cela.
if ($sid =~ m/[^a-zA-Z0-9]/) { #SID is invalid .... }
[Justin] a jeté un coup d’œil à cela et s’est dit: « Oh, c’est une chaîne de correspondance, à la recherche d’alphanumériques. Et cela commence par un caret, ce qui signifie qu’il ne vérifie que le premier caractère de la chaîne.’ Je sais que c’est à peu près son processus de réflexion, car il a écrit : « Le code mis à jour montre qu’un chèque est ajouté au switch_session sous-routine assurez-vous que le SID (ID de session) ne commence pas par des caractères alphanumériques. Pour sa défense, il a compris l’indice et a examiné comment abuser de la valeur SID sur les connexions entrantes en tant que vulnérabilité probable, mais ce n’est pas ce que fait cette regex.

Cela mérite un rapide détour dans Perl regex pour expliquer. Le =~ m/MyRegex/ construction est l’opérateur de correspondance et renvoie true si la chaîne sur laquelle elle agit contient le texte décrit par le modèle. Les classes de caractères entre crochets sont l’un des moyens de décrire ces modèles. Alors [a-z] correspondrait à un seul caractère alphabétique minuscule. Vous pouvez les combiner, comme cela se fait dans le code Sophos : [a-zA-Z0-9] correspondrait à tout caractère alphanumérique supérieur ou inférieur. Maintenant, qu’en est-il du curseur « ^ », qu’est-ce que cela fait ? On voit ici la complexité. Habituellement, un caret dans une regex Perl représente le début de la ligne. Cela correspondrait au SID commençant par un alphanumérique. Cependant, lorsque le curseur est *à l’intérieur* des crochets, il a un effet totalement différent. Dans ce cas, il fonctionne pour inverser la sélection. Tout cela pour dire que l’expression régulière ci-dessus vérifie en fait tous les caractères autres que les simples caractères alphanumériques et marque le SID invalide s’il les trouve. Regex est parfois difficile.

Ceci mis à part, quel mal pourrait être fait un SID contenant des caractères spéciaux ? Pour répondre à cela, nous devons explorer le code et voir où cela est utilisé. Le système Sophos crée un fichier sur le système de fichiers de l’appliance au nom de chaque SID valide et, lors d’une nouvelle connexion, tente de lire ce fichier avec un Perl open() appel. Je t’entends gémir, un autre Perlism. Oui. Perl a un mécanisme très pratique, que vous pouvez open() un tuyau vers ou depuis une autre commande sur le système. Cela ressemble à quelque chose comme open(Handle, "netstat -i -n |") Perl effectuera l’appel système et collectera la sortie pour vous, comme si vous la lisiez à partir d’un fichier. C’est très pratique, mais c’est un problème de sécurité terrible si l’utilisateur final a le contrôle sur le nom du fichier, tout comme le SID dans ce cas.

Notre protagoniste a trouvé cela et était ravi ! Il avait trouvé la vulnérabilité ! Il a essayé… et ça n’a pas marché. Le symbole du tuyau a été supprimé et son SID a été étrangement modifié. Mais attendez, alors qu’il y a eu un seul changement dans le code lui-même, il y a eu aussi un changement dans un fichier de configuration, l’Apache vhost configuration. La version avec le correctif de vulnérabilité a supprimé quelques paramètres, notamment un filtre d’entrée qui supprime le symbole du tuyau. Il a travaillé pendant un certain temps en essayant de trouver un trou dans le sed chaîne, en vain. Et puis la réponse est devenue évidente : il y avait une règle de réécriture qui permettait d’envoyer des requêtes à /var, et il serait redirigé vers le point de terminaison webadmin, en ignorant le filtre. Et c’est le RCE de pré-autorisation. Faites simplement une demande à /var sur l’appareil et définissez le SID sur | touch /tmp/pwned.

Violation de T-Mobile

T-Mobile a subi une autre énorme violation de données. Nom, date de naissance, numéro de sécurité sociale et informations sur le permis de conduire pour 40 millions de clients – toute personne ayant demandé un crédit chez T-Mobile. De plus, quelque 8,6 millions de clients actuels ont également vu leurs données compromises. Si vous êtes un client T-Mobile, méfiez-vous des escroqueries et des fraudes qui vous ciblent, vous et vos comptes. Jusqu’à présent, on ne sait pas grand-chose sur la façon dont la violation s’est produite, à part la déclaration officielle standard selon laquelle il s’agissait d’une « cyberattaque hautement sophistiquée ».

QNX Baddalloc

Une série de vulnérabilités ont récemment fait surface dans le système d’exploitation intégré QNX. Ce système Unix développé par Blackberry n’est peut-être pas l’un de ceux que vous connaissez, mais il apparaît dans de nombreux appareils autour de nous. Juste un exemple, le système de gestion de haut-parleurs Driverack PA2 exécute une ancienne version de QNX. (Une version plus ancienne qui possède son propre RCE de pré-authentification via un port de débogage, mais c’est une autre histoire pour une autre fois) L’endroit le plus préoccupant où QNX peut être trouvé est le transport et les charges de travail médicales. Être un véritable système d’exploitation en temps réel en fait un bon candidat pour certaines de ces charges de travail critiques, c’est pourquoi CISA a intensifié l’avertissement.

Airtags pour la justice

Et enfin, une histoire édifiante où un scooter électrique volé est récupéré grâce à la technologie. [Dan Guido] n’était pas votre victime normale quand sa voiture a été raflée. Il y avait caché une paire d’Airtags Apple à l’avance. Effectivement, il a reçu un ping via le système d’Apple et savait où se trouvait l’appareil volé. Il a contacté la police et a essayé de les convaincre de l’aider à le récupérer, et s’est heurté à une résistance compréhensible.

Les airtags sont nouveaux et la police est la cible d’arnaques comme le reste d’entre nous. Après avoir fait une pause pour Black Hat, il est retourné au commissariat pour tenter à nouveau de recruter de l’aide officielle. Il a fallu un cours accéléré sur les Airtags et quelques compétences convaincantes, mais il a réussi à obtenir une escorte pour aller regarder autour de l’emplacement indiqué pour le scooter. Le magasin de vélos électriques d’occasion semblait être un point de départ évident, et son téléphone était directement lié à son Airtag lorsqu’il a franchi la porte. Il a pu prouver la propriété et ramener son scooter chez lui.

Au bout du fil, [Dan] donne ses conseils pour reproduire son succès. Tout d’abord, cachez bien les étiquettes, car les voleurs sont déjà à leur recherche. Deuxièmement, n’utilisez pas le mode Perdu. Les tonalités audibles trahissent le jeu. Troisièmement, le temps presse. Apple a à juste titre mis en place un système pour alerter les victimes potentielles de harcèlement si un Airtag semble les suivre de trop près. Et enfin, n’essayez pas de jouer au héros. Impliquez la police et faites la récupération de la bonne façon.