Microsoft a annoncé la semaine dernière qu’elle avait temporairement désactivé le gestionnaire de protocole ms-appinstaler, qui était utilisé pour diffuser des logiciels malveillants tels que Emotet, TrickBot et Bazaloader.
MSIX est un format de paquet d’installation universel, qui permet aux développeurs de distribuer leurs applications pour le système d’exploitation Windows ou d’autres plateformes. Le protocole ms-appinstaler, en particulier, est conçu pour permettre l’installation facile d’applications en cliquant sur un lien dans une page web.
L’année dernière, une vulnérabilité, CVE-2021-43890, a été découverte qui permettait d’usurper les installateurs d’applications légitimes tout en installant une application malveillante.
Alors que Microsoft a corrigé cette vulnérabilité en décembre dernier, la société a maintenant décidé de désactiver complètement le protocole ms-appinstaler pendant qu’elle travaille sur une solution complète et sécurisée au problème.
Microsoft reconnaît que cette fonctionnalité est essentielle dans de nombreuses entreprises et organisations, mais prendra le temps nécessaire avant de la réactiver. Cependant, la possibilité d’activer et de contrôler ce protocole par le biais de politiques de groupe est envisagée.
Les CVE-2021-44142, CVE-2021-44141 et CVE-2022-0336 affectant SAMBA ont été corrigés. Ces vulnérabilités facilitent l’exécution de code sur les systèmes qui utilisent SAMBA comme logiciel pour intégrer des ordinateurs Windows, Linux et macOS dans un réseau. Vous trouverez ci-dessous les correctifs qui ont été publiés pour atténuer ces vulnérabilités.
Ces vulnérabilités ont été divulguées dans le cadre du Pwn2Own Austin 2021 de la Trend Micro Zero Day Initiative et permettent à un attaquant distant d’exécuter du code arbitraire sur des installations utilisant le module vfs_fruit (module de système de fichiers virtuel). Les versions concernées sont les versions antérieures à 4.15.5 (CVE-2021-44142), 4.15.5 (CVE-2021-44141) et les versions 4.0.0 (CVE-2022-036) et ultérieures du démon smbd utilisé pour permettre le partage de fichiers et la connexion entre les périphériques réseau disponibles. Ces vulnérabilités sont respectivement de niveau critique, élevé et moyen. Outre l’exécution de code, un attaquant pourrait divulguer des informations et se faire passer pour un service arbitraire en cas d’exploitation de l’une de ces vulnérabilités.
Versions de RedHat affectées par CVE-2021-44142. Source: RedHat
Pour atténuer ces vulnérabilités, une série de correctifs a été développée et publiée sur le site web de SAMBA. Les versions actuellement corrigées pour atténuer cette vulnérabilité sont 4.15.5, 4.14.12 et 4.13.17. Il est conseillé aux administrateurs système d’appliquer les nouvelles mises à jour dès que possible. Si Trend Micro et Red Hat recommandent de supprimer le module VFS « fruit » de la liste des objets VSF configurés comme solution de contournement, ils indiquent également que cela pourrait poser des problèmes aux systèmes macOS qui tentent d’accéder à des informations sur des équipements réseau tels que des NAS, car ils pourraient rencontrer des problèmes tels que la perte d’informations ou l’inaccessibilité des informations stockées.
De multiples vulnérabilités classées comme critiques ont été publiées dans les produits de la gamme Cisco Small Business RV Routers Series. Elles pourraient permettre à un attaquant distant d’exécuter du code à distance sur l’appareil en plus de : l’élévation des privilèges, le contournement de l’authentification, l’exécution de logiciels non signés et le déni de service.
Parmi les vulnérabilités rapportées, il convient de signaler une vulnérabilité dans le module VPN SSL qui pourrait permettre l’exécution de code arbitraire par un attaquant non authentifié (CVE-2022-20699). Plusieurs failles dans l’interface de gestion web des routeurs pourraient permettre une élévation de privilèges en envoyant des commandes spécialement conçues (CVE-2022-20700, CVE-2022-20701 et CVE-2022-20702). Une autre faille existe dans la vérification incorrecte des images logicielles qui sont installées sur les ordinateurs, ce qui pourrait permettre l’installation d’images non signées (CVE-2022-20703). De multiples failles de sécurité ont été découvertes en raison d’une validation insuffisante des entrées fournies par l’utilisateur, permettant à un attaquant d’exécuter des commandes arbitraires sur le système (CVE-2022-20707, CVE-2022-20708 et CVE-2022-20749).
Certaines de ces vulnérabilités sont dépendantes les unes des autres, il est donc nécessaire d’en exploiter une pour en exploiter une autre.
Cisco recommande de mettre à jour vers les versions les plus récentes qui résolvent ces vulnérabilités :
12 ans. C’est le temps pendant lequel une vulnérabilité dans PolKit (anciennement Policykit), un système de gestion des autorisations largement utilisé par les distributions Linux les plus populaires, a été cachée. La faille se trouve dans le composant ‘pkexec’, qui permet une fonctionnalité similaire à ‘sudo’, c’est-à-dire l’exécution d’une commande avec les privilèges d’un autre compte ou utilisateur. Par conséquent, lorsqu’il est exploité, il permet l’élévation des privilèges de l’utilisateur root, puisque ‘pkexec’ est un binaire SUID root.
En plus d’être présent dans presque toutes les distributions Linux, l’exploitation est triviale. Grosso modo, il suffit de manipuler uniquement les variables d’environnement pour l’effectuer. En d’autres termes, il ne s’agit pas d’un exploit typique, dans lequel il faut échapper à la protection et disposer d’un contexte d’exécution favorable, mais le succès de l’exploit est pratiquement garanti. En fait, un grand nombre d’exploits émergent pour cette vulnérabilité (avec CVE-2021-4043).
Il est intéressant de noter que la base de la faille a été décrite en 2013 dans un billet d’un chercheur australien, Ryan Mallon, qui prévenait que l’injection d’un pointeur nul dans le tableau d’arguments d’un programme pouvait avoir des conséquences désastreuses. Bien qu’il n’ait pas été en mesure à l’époque d’identifier un vecteur sur lequel appliquer son constat. Elle s’est finalement matérialisée par cette élévation de privilège, triviale à exploiter, rappelons-le.
Un article récemment publié par le chercheur en sécurité du GitHub Security Lab, Kevin Backhouse, détaille la procédure qui permet l’escalade des privilèges sur les systèmes Linux qui utilisent le service polkit.
Un attaquant non privilégié peut obtenir un shell avec l’utilisateur root en utilisant la vulnérabilité de contournement d’authentification dans le service polkit.
Bien que de nombreuses distributions Linux n’aient pas inclus la version vulnérable de polkit jusqu’à récemment, tout système Linux sur lequel est installé polkit 0.113 ou une version ultérieure est exposé à cette attaque.
La liste des distributions actuellement vulnérables partagée par Kevin Backhouse comprend des distributions populaires telles que RHEL 8, Fedora 21 (ou ultérieure), Ubuntu 20.04, ainsi que des versions instables comme Debian testing (« bullseye ») et ses dérivés.
L’exploitation de la vulnérabilité est extrêmement facile, ne nécessitant que quelques commandes de terminal utilisant uniquement des outils standard tels que bash, kill et dbus-send ; une démonstration vidéo fournie par Kevin Backhouse est incluse ci-dessous.
Lorsqu’un processus demandeur se déconnecte du service dbus juste avant que l’appel à polkit_system_bus_name_get_creds_sync soit lancé, le processus ne peut pas obtenir un uid et un pid uniques du processus et ne peut pas vérifier les privilèges du processus qui a fait la demande. La plus grande menace de cette vulnérabilité concerne la confidentialité et l’intégrité des données, ainsi que la disponibilité du système.
La nouvelle vulnérabilité CVE-2022-0185 dans le noyau Linux permet de prendre le contrôle du nœud tant que le conteneur a activé le privilège CAP_SYS_ADMIN.
Les mainteneurs du noyau Linux ont découvert une nouvelle vulnérabilité dans le noyau, identifiée comme CVE-2022-0185, qui pourrait être exploitée dans des environnements tels que Kubernetes pour échapper aux conteneurs et prendre le contrôle du nœud. L’exploitation de la faille nécessite que le conteneur ait la permission CAP_SYS_ADMIN activée, ce qui permet des actions telles que le montage de disques ou la définition de quotas sur le conteneur.
La vulnérabilité consiste en un sous-débit d’entier dans le composant de contexte du système de fichiers, par lequel la valeur peut être réduite en dessous de zéro et au lieu de prendre une valeur négative, atteindre la valeur maximale de l’entier. Ce bug peut être exploité pour écrire en dehors de la mémoire allouée et ainsi modifier d’autres valeurs dans l’espace.
En principe, d’autres technologies telles que Docker ne sont pas vulnérables à ce bug car seccomp est activé en standard. Cette fonctionnalité du noyau est utilisée pour restreindre les actions autorisées dans le conteneur, empêchant ainsi l’exploitation de la vulnérabilité. Cette restriction peut être testée en essayant d’exécuter ‘unshare’ sur l’instance, et vous verrez apparaître une erreur indiquant que l’opération n’est pas autorisée. En théorie, les opérateurs Kubernetes pourraient également activer seccomp par défaut, bien que cette fonctionnalité soit encore en phase de test.
La vulnérabilité a déjà été corrigée dans la version 5.16.2 de Linux, et est maintenant disponible dans la plupart des distributions telles que Redhat, Debian ou Ubuntu. La faille n’est présente qu’à partir de la version 5.1 du noyau, les versions antérieures n’ont donc pas besoin de corriger le problème. Une autre possibilité est de désactiver les espaces de noms des utilisateurs non privilégiés, pour lesquels vous pouvez utiliser : ‘sysctl -w kernel.unprivileged_userns_clone = 0’.
Pour l’instant, rien ne prouve qu’il ait été exploité par des attaquants, bien que des Proof of Concept (PoC) soient déjà disponibles et que d’autres utilisateurs les testent déjà. Le même utilisateur de Twitter a publié un repository où il promet de mettre en ligne ses résultats prochainement.
Il est recommander de mettre à jour dès que possible si vous avez des conteneurs qui utilisent la permission ‘CAP_SYS_ADMIN’. De plus, il convient généralement de ne pas accorder de permissions supplémentaires aux conteneurs, sauf si leur utilisation est vraiment nécessaire.
