Au cours des deux dernières semaines, Log4j a continué à générer des informations sur la sécurité, avec la découverte de plates-formes plus vulnérables et la sortie de CVE supplémentaires. Le premier est le travail effectué par TrendMicro, en examinant les véhicules électriques et les chargeurs. Ils ont découvert une attaque log4j dans l’un des frameworks de chargeurs publiés et ont également réussi à observer des preuves de vulnérabilité dans le système d’infodivertissement embarqué Tesla. Il n’est pas exagéré d’imaginer un malware qui pourrait fonctionner à la fois sur un chargeur et sur un VE. Et puisque ces systèmes communiquent entre eux, ils pourraient propager le virus dans les voitures passant de chargeur en chargeur.
Log4j est maintenant à 2.17.1, car il y a encore un autre RCE à corriger, CVE-2021-44832. Celui-ci n’obtient qu’un score de 6,6 sur l’échelle CVSS, contrairement à l’original, qui pesait 10. 44832 oblige l’attaquant à exercer d’abord un contrôle sur la configuration Log4j, ce qui rend l’exploitation beaucoup plus difficile. Cette chaîne de vulnérabilités de suivi démontre un modèle bien connu, où une vulnérabilité de haut niveau attire l’attention des chercheurs, qui trouvent d’autres problèmes dans le même code.
Il existe maintenant des rapports indiquant que Log4j est utilisé dans les campagnes de ransomware Conti. De plus, une entreprise basée à Marai un ver a été observé. Cette attaque auto-propagée semble viser les serveurs Tomcat, entre autres.
WebOS tombe en un instantané
[David Buchanan] reconnaît que même s’il s’agit d’un exploit intéressant, il n’a pas beaucoup d’utilité à ce stade. Cela pourrait changer, mais regardons le défaut pour l’instant. Les instantanés sont une fonctionnalité intéressante du moteur JavaScript V8. Lorsque vous accédez à une page Web, le contexte JavaScript de cette page doit être généré en mémoire, y compris le chargement de toutes les bibliothèques appelées par la page. Cela ne prend pas trop de temps sur un ordinateur de bureau, mais sur un périphérique embarqué ou un téléphone portable chargeant une interface locale, cette étape d’initialisation peut représenter un grand pourcentage du temps nécessaire pour dessiner la page demandée. Les instantanés sont un excellent hack, où le contexte est initialisé, puis enregistré. Lorsque l’interface est ouverte plus tard, le moteur V8 peut être appelé avec ce fichier et le contexte est pré-initialisé, ce qui rend le lancement de l’application ou de l’interface sensiblement plus rapide. Le seul problème est que V8 s’attend à ce que les instantanés ne soient chargés qu’à partir d’une source fiable.
Passons à la plate-forme WebOS elle-même. Les applications individuelles sont en bac à sable, mais les applications Web exécutent leur code dans le contexte de WebAppMgr (WAM), leur navigateur basé sur Chromium/V8. Alors que les applications individuelles sont en bac à sable, WAM ne l’est pas. Le kicker est qu’une application Web peut spécifier son propre instantané à charger dans V8. Le chargement d’un instantané corrompu a donné [David] Confusion de type JS, et une primitive de lecture/écriture arbitraire en conséquence. À partir de là, sortir de l’exécution de JS et passer au shellcode réel était assez facile. Ce RCE s’exécute en tant qu’utilisateur « wam », mais il s’agit d’un compte légèrement privilégié. Notamment, wam a accès à /dev/mem — accès direct à la mémoire système. L’escalade vers la racine est presque triviale.
[David] a publié le PoC complet, notant que LG sous-paye notoirement les primes de bogues. Je ne suis pas d’accord avec son affirmation selon laquelle cette attaque repose entièrement sur le chargement latéral d’une application malveillante, pour la simple raison que LG exécute son Content Store pour cette plate-forme. Un développeur malveillant peut être en mesure de contourner toutes les routines de détection de logiciels malveillants que LG utilise pour contrôler les applications. Les applications malveillantes sur l’App Store ne sont certainement pas nouvelles, après tout. Le pire de cet exploit est qu’il est difficile de mettre le doigt sur la vulnérabilité.
Équipe à quatre bogues en équipes
[FABIAN BRÄUNLEIN] trouvé un comportement inattendu intéressant dans la fonction d’aperçu de lien de Microsoft Teams. Le premier problème est une contrefaçon de demande côté serveur. L’aperçu du lien est généré côté serveur Teams et, par définition, nécessite l’ouverture de la page pour générer l’aperçu. Le problème est le manque de filtrage – la liaison à 127.0.0.1:80 génère un aperçu de ce qui se trouve sur l’hôte local du serveur Teams.
La prochaine étape est une technique d’usurpation de lien simple. Celui-ci utilise un outil comme Burp pour modifier les données envoyées par le client Teams. Une partie du message qui est envoyé lors de l’intégration d’un lien est l’URL à appeler pour la génération d’aperçu. Aucune autre validation n’est effectuée, il est donc possible de générer un aperçu à partir d’une URL bénigne, tandis que le lien réel renvoie à une page arbitraire. Le troisième problème est lié, car le lien vers la vignette elle-même se trouve également dans ce message et peut être falsifié. Le cas d’utilisation intéressant ici est qu’un attaquant pourrait définir cela sur une URL qu’il contrôle et extraire des informations d’une cible, à savoir l’adresse IP publique. Maintenant, cela est bloqué par le client de la cible sur la plupart des plates-formes, mais sur Android, les vérifications manquaient.
Et enfin, également un problème uniquement Android, un attaquant peut envoyer un « Message de mort », essentiellement un message mal formé qui fait planter l’application simplement en essayant de rendre l’aperçu. Celui-ci plante l’application à chaque fois que l’utilisateur essaie d’accéder au chat, verrouillant ainsi complètement l’utilisateur hors de l’application. Maintenant, ce ne sont pas des problèmes bouleversants, mais le haussement d’épaules collectif de Microsoft en réponse est… décevant. Ils ont corrigé furtivement la fuite d’adresse IP, mais il est apparemment toujours possible d’usurper les aperçus de liens, ainsi que de faire planter l’application Android.
Portes dérobées PBX
Des chercheurs de RedTeam Pentesting ont examiné un PBX conçu par Auerswald, un fabricant allemand d’équipements de télécommunications. Ce qui a attiré leur attention, c’est un service annoncé, où Auerswald pouvait effectuer une réinitialisation du mot de passe administrateur pour un client bloqué hors de son équipement. Ceci est une porte dérobée de manuel, et une enquête certainement justifiée.
Leur approche, plutôt que d’attaquer directement le matériel, consistait à récupérer le dernier progiciel du site Web d’Auerswald et à l’analyser. Utilisation du file, gunzip, et dumpimage les utilitaires leur ont donné le système de fichiers racine dont ils avaient besoin. En travaillant sur le Web des fichiers de configuration, ils se sont installés sur le binaire du serveur Web qui contenait probablement la porte dérobée de réinitialisation du mot de passe. Juste une note, il est très courant que les périphériques embarqués incluent toute leur interface utilisateur et leur logique de configuration dans un seul binaire httpd.
Étant donné un binaire, ils se sont tournés vers ce qui est rapidement devenu l’outil préféré des chercheurs en sécurité du monde entier, Ghidra. Ils avaient un autre indice, l’utilisateur « sous-administrateur », alors ils ont recherché cette chaîne à l’aide de Ghidra. Payer la saleté. En explorant les fonctions, le nom d’utilisateur codé en dur « Schandelah » était là. Un peu plus de détective est venu avec la fonction de mot de passe. Pour chacun de ces PBX, le mot de passe de la porte dérobée est constitué des 7 premiers caractères du hachage MD5 du numéro de série de l’unité + « r2d2 » + la date du jour.
Juste pour le plaisir, les chercheurs ont utilisé Ghidra pour rechercher d’autres utilisations de la fonction de mot de passe de porte dérobée. Il s’avère que si l’utilisateur admin est spécifié et que le mot de passe ne correspond pas au mot de passe configuré par l’utilisateur, il est comparé à cet algorithme. Si ça correspond ? Vous êtes connecté en tant qu’administrateur sur le matériel. C’est évidemment plus utile que de réinitialiser le mot de passe administrateur, car cela permet l’accès sans aucune modification évidente du système. L’ensemble de l’article est un excellent tutoriel sur l’utilisation de Ghidra pour ce type de recherche.
Auerswald a très rapidement poussé les changements de firmware pour corriger les problèmes identifiés. Une porte dérobée comme celle-ci, qui est divulguée publiquement, n’est pas du tout une mine terrestre légale et éthique comme certaines des autres dont nous avons discuté ici. Il y a toujours un problème avec la mise en œuvre – une réinitialisation de mot de passe devrait également réinitialiser l’appareil aux paramètres d’usine et supprimer les données utilisateur. Rien de moins invite à une divulgation majeure de données.
Usurpation SAM
Cette vulnérabilité d’élévation des privilèges de Windows Active Directory est fascinante par sa simplicité. C’est une combinaison de CVE-2021-42287 et CVE-2021-42278. Windows Active Directory a deux types de comptes distincts, les comptes d’utilisateur et de machine. Les comptes de machine sont utilisés pour introduire du matériel spécifique dans le domaine et se terminent généralement par le signe dollar (MyMachine1$). Par défaut, un utilisateur peut créer des comptes de machine, ainsi que renommer ces comptes. Le premier problème est qu’un utilisateur peut créer puis renommer un compte d’ordinateur de la même manière qu’un contrôleur de domaine, sans le dernier signe dollar. Par exemple, je pourrais créer MyMachine1$, puis renommez-le en DomainController1. DomainController1$ existerait toujours et le domaine les considérerait comme des comptes de machine séparés.
Les domaines Windows modernes utilisent Kerberos sous le capot, et Kerberos utilise le paradigme du ticket. Un compte peut demander un Ticket Granting Ticket (TGT) qui agit comme un jeton d’authentification temporaire. Considérez-le comme un remplacement de mot de passe, qui peut être automatiquement envoyé avec les demandes. L’attaque consiste à demander un TGT pour le compte de machine renommé, puis à renommer ce compte une fois de plus, de nouveau à MyMachine1. La clé est que l’attaquant a toujours un ticket valide pour le DomainController1 compte, même si un compte n’existe plus avec ce nom exact. Ensuite, l’attaquant demande une clé de session au centre de distribution de clés (KDC) à l’aide de ce TGT. Le KDC note que le compte demandeur n’existe pas et ajoute utilement le signe dollar et relance la vérification. Il voit le TGT valide pour DomainController1, et renvoie une clé de session autorisant l’attaquant comme DomainController1$, qui se trouve être un compte d’administrateur de domaine.
Les douleurs du vieillissement de Chrome
On dit que nous n’avons pas obtenu de Windows 9, car trop d’anciennes applications ont été écrites avec des expressions régulières qui empêcheraient l’exécution, se plaignant que l’application ne fonctionnerait pas sous Windows 95 ou 98. Chrome essaie d’éviter un problème similaire, car Les développeurs de Google voient la version 100 à l’horizon. Ce genre de chose a déjà mordu le navigateur Web, notamment lorsque Opera a publié la version 10, brisant davantage la chaîne user-agent dans le processus. Firefox s’amuse également, et les développeurs des deux navigateurs ont une demande de votre part : naviguez sur le Web avec une chaîne d’agent utilisateur usurpée et faites-leur savoir ce qui se passe à la suite de la version 100. Ce serait un bon possibilité de tester vos propres sites, aussi. Faites-nous savoir si vous voyez des résultats particulièrement étranges.
