Les chercheurs en sécurité de Wiz découvrent une autre vulnérabilité Azure majeure

Les chercheurs en sécurité de Wiz découvrent une autre vulnérabilité Azure majeure

14 septembre 2021 0 Par Le Caiman
Augmenter / Ce n’est pas ainsi que fonctionne la vulnérabilité OMIGOD, bien sûr – mais la foudre est beaucoup plus photogénique que le XML conçu de manière malveillante.

Le fournisseur de sécurité cloud Wiz – qui a récemment fait l’actualité en découvrant une vulnérabilité massive dans un service de base de données géré par Microsoft Azure CosmosDB – a trouvé un autre trou dans Azure.

La nouvelle vulnérabilité affecte les machines virtuelles Linux sur Azure. Ils se retrouvent avec un service peu connu sous le nom d’OMI installé en tant que sous-produit pour activer l’une des options de journalisation et/ou de génération de rapports de gestion dans l’interface utilisateur Azure.

Au pire, la vulnérabilité dans OMI pourrait être exploitée dans l’exécution à distance du code racine – heureusement, le pare-feu Azure ne la limitera pas, par défaut, hors de la machine virtuelle à la majorité des réseaux internes des clients.

OMIGOD

La sélection de l’un des services d’infrastructure les plus attrayants d’Azure (comme la journalisation distribuée) installe automatiquement un service peu connu à l’intérieur la machine virtuelle Azure en question. Ce service, OMI – abréviation de Open Management Interface – est destiné à fonctionner de manière similaire au service WMI de Microsoft sous Windows, permettant la collecte de journaux et de métriques ainsi que la gestion à distance.

Certaines des spécifications OMI nécessitent une authentification afin d’associer des commandes et des demandes à un ID utilisateur unique (UID) – mais malheureusement, un bogue causé par l’acceptation complète des demandes informelles qui omettent la section d’authentification fournie par le root propre utilisateur.

Lorsqu’il est configuré pour la gestion à distance, OMI exécute un serveur HTTPS sur le port 5986, qui peut être connecté à un client HTTPS standard tel que curl et des commandes relativement lisibles par l’homme sont données dans le XML-dérivé DU SAVON protocole. Dans d’autres configurations, OMI ne s’exécute que sur un socket Unix local à /var/opt/omi/run/omiserver.sock, ce qui limite son exploitation aux seuls utilisateurs locaux.

En tant que chercheur senior en sécurité Wiz Nir ohfeld J’ai parcouru une démonstration de la vulnérabilité, elle l’a décrite principalement en termes d’élévation de privilèges – un attaquant qui obtient n’importe quel orteil sur une machine virtuelle peut émettre n’importe quelle commande arbitraire en tant que root en utilisant la syntaxe OMI.

Dans les environnements plus vastes où OMI écoute sur un port réseau, non seulement un socket Unix local, c’est aussi un excellent moyen de pivoter latéralement – un attaquant qui obtient un shell sur une seule machine virtuelle dans le réseau Azure local d’Azure peut infecter le bogue client normalement utilisé. contrôler toute autre machine virtuelle sur le même segment de réseau.

Il s’avère qu’Azure n’est pas le seul endroit où vous obtenez OMI. Les organisations qui acceptent Centre des systèmes Microsoft (annoncé sur toutes les nouvelles installations de Windows Server 2019 et versions ultérieures) et géré par un hôte Linux sur site ou hors site, avec la version boguée d’OMI également utilisée sur ces hôtes gérés.

Alors que Nir et moi parlions de l’étendue de la vulnérabilité, j’ai souligné la probabilité que certains clients Azure se connectent à l’interface utilisateur et ajoutent une règle « autoriser par défaut » au pare-feu de la machine virtuelle Azure Linux – c’est certainement une mauvaise pratique, mais ce arrive. « Oh mon dieu », ai-je dit – et l’équipe Wiz a éclaté de rire. Il s’avère que c’est exactement ce qu’ils ont nommé la vulnérabilité – OMIGOD.

Subvention difficile à collecter

Malgré la gravité apparente d’OMIGOD – y compris quatre bogues distincts mais liés découverts par Wiz – la société a eu du mal à obtenir que Microsoft lui verse une prime pour sa découverte et sa divulgation responsables. Dans une série d’e-mails examinés par Ars, les représentants de Microsoft ont initialement rejeté les vulnérabilités comme « hors de portée » pour Azure. Selon Wiz, les représentants de Microsoft lors d’un appel téléphonique ont signalé des bogues dans OMI comme un problème « open source ».

Cette affirmation est compliquée par le fait que Microsoft a été le premier auteur d’OMI accordé à The Open Group en 2012. Depuis lors, la grande majorité des engagements envers OMI ont continué à provenir de Redmond, qui est employé par Microsoft participants– open source ou non, il s’agit clairement d’un projet Microsoft.

En plus de Microsoft de facto propriété du projet, le propre système de gestion Azure d’Azure utilise automatiquement – les administrateurs ne sont pas invités à cliquer sur la ligne de commande et à installer le package pour eux-mêmes. Au lieu de cela, il est automatiquement déployé dans la machine virtuelle chaque fois que vous cliquez sur une option dépendante de l’OMI dans l’interface graphique Azure.

Même lorsque Azure Management utilise OMI, il y a peu de notification explicite à l’administrateur qui l’a activé. Nous avons constaté que la plupart des administrateurs Azure ne semblent pas l’aimer trouver que OMI existe si leur partition / var se remplit avec ses vidages de mémoire.

Microsoft a finalement retiré son refus de payer la prime de bogue d’Azure Management pour OMIGOD et a attribué à Wiz 70 000 $ pour les quatre bogues.

Coin poussiéreux de la chaîne d’approvisionnement

« OMI est similaire à l’implémentation Linux de Windows Infrastructure de gestion, « Ohfeld a dit à Ars. » Notre hypothèse est que lorsqu’ils sont passés au cloud et ont dû prendre en charge les machines Linux, ils ont voulu combler l’écart, en ayant la même interface disponible pour les machines Windows et Linux. « 

L’inclusion d’OMI dans Azure Management – et dans Microsoft System Center, qui est annoncé directement sur toutes les nouvelles installations de Windows Server – signifie qu’il est installé en tant que composant de bas niveau sur un excellent nombre de machines Linux critiques, virtuelles et autres. Parce qu’il écoute les commandes sur un port réseau ouvert dans un certain nombre de configurations, en utilisant des protocoles hautement reconnus (SOAP sur HTTPS), c’est une cible très attrayante pour les attaquants.

Compte tenu de l’étendue du déploiement et de la vulnérabilité potentielle, vous pouvez raisonnablement vous attendre à ce qu’OMI ait suffisamment de globes oculaires – suffisamment pour que la vulnérabilité soit résumée comme « vous avez oublié de vous assurer d’authentifier l’utilisateur » rapidement. Malheureusement, ce n’est pas le cas – OMI (une mesure de l’intérêt relativement occasionnel des développeurs) a eu un nombre très faible de 24 contributeurs, 90 forks et 225 « stars » au cours des neuf dernières années. ville sur Github.

En revanche, mon propre projet de gestion ZFS Sanoid – qui n’écoute aucun port et a été décrit avec précision s’il s’agit de « quelques milliers de lignes de script Perl » – compte plus de deux fois plus de participants et de forks et presque 10 fois plus d’étoiles.

Quelle que soit la norme raisonnable, une plus grande attention devrait être accordée à un élément d’infrastructure qui est aussi important que l’OMI – ce qui soulève des questions sur la quantité autre Les recoins de la chaîne d’approvisionnement des logiciels sont inspectés et entretenus de manière uniforme.

Chemin de mise à niveau vague

L’employé de Microsoft Deepak Jain engagé les paramètres nécessaires sur le référentiel OMI GitHub le 11 août – mais comme Ars l’a directement confirmé, ces paramètres n’ont pas encore été déployés sur Azure depuis le 13 septembre. Microsoft a annoncé à Wiz qu’il annoncerait CVE le Patch Tuesday, mais les chercheurs de Wiz ont exprimé leur incertitude quant à lorsque ces dispositions pourraient être utilisées de manière universelle.

« Microsoft n’a pas partagé son plan d’atténuation avec nous », a déclaré le Wiz CTO Ami Luttwak à Ars, « mais sur la base de notre propre télémétrie client, cela peut être difficile à corriger correctement. ‘Chacun peut nécessiter un chemin de mise à niveau différent. « 

Pour les systèmes Linux arbitraires gérés à distance depuis Microsoft System Center, le chemin de mise à niveau peut être encore plus controversé, car les agents Linux pour System Center ont été obsolète. Les clients qui utilisent encore System Center compatible OMI avec Linux peuvent avoir besoin de mettre à jour manuellement l’agent OMI.

Atténuation pour les utilisateurs concernés

Si vous êtes un administrateur système Linux et que vous craignez d’exécuter OMI, vous pouvez facilement le détecter en recherchant des ports d’écoute sur TCP 5985 et 5986 (TCP 1270, pour les agents OMI utilisés par Microsoft System Center plutôt qu’Azure) ou Unix prise située sous /var/opt/omi.

Si vous avez le socket Unix mais que vous n’avez pas les ports, vous êtes toujours vulnérable jusqu’à ce que Microsoft utilise un correctif – mais la portée est limitée aux privilèges locaux uniquement.

Dans les cas où OMI écoute sur les ports TCP, il se connecte à toutes les interfaces, y compris les interfaces publiques. Nous vous recommandons fortement de limiter l’accès à ces ports via un pare-feu Linux, que votre boîtier OMI soit réparé ou non.

En particulier, les administrateurs soucieux de la sécurité doivent soigneusement limiter l’accès à ce service et à tout autre service réseau aux seules parties du réseau qui sont en fait avoir besoin accès. Les machines exécutant Microsoft System Center ont clairement besoin d’un accès OMI aux systèmes clients, tout comme la propre infrastructure d’Azure, mais les clients n’ont pas besoin d’un accès OMI de l’un à l’autre.

La meilleure pratique pour réduire la surface d’attaque d’un réseau – avec ce service et tout autre service potentiellement vulnérable – est un pare-feu global deny règle, avec des allow les règles ne s’appliquent qu’aux machines avoir besoin pour accéder à un service particulier.

Lorsque cela n’est pas pratique – par exemple, dans un environnement Azure, l’administrateur n’est pas sûr de ce dont les segments de réseau Microsoft ont besoin pour accéder à OMI pour qu’Azure Management fonctionne correctement – il n’accédera qu’aux machines virtuelles à partir d’autres machines virtuelles. rejettera le même segment de réseau. empêcher le déplacement latéral des attaquants d’une machine à l’autre.