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

La nouvelle vulnérabilité affecte les machines virtuelles Linux sur Azure. Ils se retrouvent avec un service peu connu appelé OMI installé en tant que sous-produit de l’activation de l’une des nombreuses options de rapport et/ou de gestion de journalisation dans l’interface utilisateur d’Azure.

Au pire, la vulnérabilité d’OMI pourrait être exploitée dans l’exécution de code racine à distance, bien que heureusement, le pare-feu extérieur à la machine virtuelle d’Azure le limitera uniquement aux réseaux internes de la plupart des clients.

L’activation de l’un des nombreux services d’infrastructure Azure attrayants (tels que la journalisation distribuée) installe automatiquement un service peu connu à l’intérieurla machine virtuelle Azure en question. Ce service, OMI – abréviation de Open Management Interface – est destiné à fonctionner un peu comme le service WMI de Microsoft Windows, permettant la collecte de journaux et de métriques ainsi qu’une certaine gestion à distance.

Une partie de la spécification OMI nécessite une authentification afin de lier les commandes et les demandes à un ID utilisateur (UID) spécifique – mais malheureusement, un bogue a provoqué l’acceptation de demandes malformées qui omettent entièrement la strophe d’authentification comme si elles étaient données par le rootutilisateur lui-même.

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 comme curl et donné des commandes raisonnablement lisibles par l’homme dans le protocole SOAP dérivé de XML. Dans d’autres configurations, OMI ne s’exécute que sur un socket Unix local à /var/opt/omi/run/omiserver.sockce qui limite son exploitation aux seuls utilisateurs locaux.

En tant que chercheur senior en sécurité Wiz Nir Ohfeldm’a guidé à travers une démonstration de la vulnérabilité, il l’a décrite principalement en termes d’escalade de privilèges – un attaquant qui prend pied sur une machine virtuelle affectée 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, pas seulement sur un socket Unix local, c’est également un excellent moyen de pivoter latéralement – un attaquant qui obtient un shell sur une machine virtuelle dans le réseau local Azure d’un client peut généralement utiliser l’OMI bogué pour obtenir contrôle de 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 trouverez OMI. Les organisations qui adoptent Microsoft System Center (qui est annoncé à chaque nouvelle installation de Windows Server 2019 et versions ultérieures) et gèrent des hôtes Linux sur site ou hors site avec lui se retrouvent également avec la version boguée d’OMI déployée sur ces hôtes gérés.

Alors que Nir et moi parlions de la portée de la vulnérabilité, j’ai souligné la probabilité que certains clients Azure activent à la fois la journalisation dans l’interface utilisateur et l’ajout d’une règle “d’autorisation par défaut” au pare-feu Azure d’une machine virtuelle Linux – bien sûr, c’est une pratique incorrecte, mais ilarrive. “Oh mon dieu”, m’exclamai-je, et l’équipe de Wiz éclata de rire. En fin de compte, c’est exactement ce qu’ils avaient nommé la vulnérabilité-OMIGOD.

Malgré la gravité évidente d’OMIGOD, qui comprend quatre bogues distincts mais liés découverts par Wiz, la société a eu du mal à convaincre Microsoft de lui verser une prime pour sa découverte et sa divulgation responsable. 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 en outre caractérisé les bogues dans OMI comme un problème “open source”.

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

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

Même lorsque la gestion Azure déploie OMI, l’administrateur qui l’a activé est peu averti. Nous avons constaté que la plupart des administrateurs Azure ne semblent découvrir qu’OMI existe que si leur partition /var se remplit de ses vidages mémoire.

Finalement, Microsoft a cédé sur son refus de payer une prime de bogue Azure Management pour OMIGOD et a accordé à Wiz un total de 70 000 $ pour les quatre bogues qui le composaient.

“OMI est comme une implémentation Linux de WindowsManagement Infrastructure”, a déclaré Ohfeld à Ars. “Notre hypothèse est que lorsqu’ils sont passés au cloud et ont dû prendre en charge des machines Linux, ils voulaient combler le fossé, avoir la même interface disponible pour les machines Windows et Linux.”

L’inclusion d’OMI dans Azure Management – et dans Microsoft System Center, annoncée directement sur chaque nouvelle installation de Windows Server – signifie qu’elle est installée en tant que composant de bas niveau sur un nombre impressionnant de machines Linux d’importance critique, virtuelles et autres. Le fait qu’il écoute les commandes sur un port réseau ouvert dans certaines configurations, en utilisant des protocoles extrêmement connus (SOAP sur HTTPS), en fait une cible très attrayante pour les attaquants.

Avec la portée à la fois du déploiement et de la vulnérabilité potentielle, on pourrait raisonnablement s’attendre à ce que beaucoup de globes oculaires soient sur OMI – suffisamment pour qu’une vulnérabilité résumée comme “vous avez oublié de vous assurer que l’utilisateur est authentifié” soit rapidement découverte. Malheureusement, ce n’est pas le cas – OMI a un total inquiétant de 24 contributeurs, 90 fourches et 225 “étoiles” (une mesure de l’intérêt relativement occasionnel des développeurs) au cours des neuf années où il a été installé sur Github.

En revanche, mon propre projet de gestion ZFS Sanoid – qui n’écoute aucun port et a été décrit avec précision mais sans charité comme “quelques milliers de lignes de script Perl” – a plus de deux fois plus de contributeurs et de fourches et près de 10 fois plus d’étoiles.

Selon toute norme raisonnable, un élément d’infrastructure aussi important que l’OMI devrait recevoir beaucoup plus d’attention, ce qui soulève des questions sur le nombre deautre les coins poussiéreux de la chaîne d’approvisionnement des logiciels sont également sous-inspectés et sous-maintenus.

Deepak Jain, employé de Microsoft, a apporté les correctifs nécessaires au référentiel GitHub d’OMI le 11 août, mais comme Ars l’a confirmé directement, ces correctifs n’avaient toujours pas été déployés sur Azure au 13 septembre. Microsoft a déclaré à Wiz qu’il annoncerait un CVE le mardi du patch, mais Wiz les chercheurs ont exprimé leur incertitude quant à la manière ou au moment où ces correctifs pourraient être déployés universellement.

“Microsoft n’a pas partagé son plan d’atténuation avec nous”, a déclaré Wiz CTO Ami Luttwak à Ars, “mais sur la base de notre propre télémétrie client, cela pourrait être difficile à corriger correctement. OMI est intégré à plusieurs services Azure et chacun peut nécessiter un chemin de mise à niveau différent.”

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

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

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

Dans les cas où OMI écoute sur les ports TCP, il se lie à toutes les interfaces, y compris les interfaces publiques. Nous vous recommandons vivement de limiter l’accès à ces ports via le pare-feu Linux, que votre instance OMI soit réparée 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 seuls segments de réseau quibesoin accéder. Les machines exécutant Microsoft System Center ont évidemment besoin d’accéder à OMI sur les systèmes clients, tout comme la propre infrastructure d’Azure, mais les clients eux-mêmes n’ont pas besoin d’un accès OMI les uns aux autres.

La meilleure pratique pour réduire la surface d’attaque du réseau – avec ce service et tout autre service potentiellement vulnérable – est un pare-feu global denyrègle, avec des allowrègles en place uniquement pour les machines quibesoin pour accéder à un service donné.

Là où ce n’est pas pratique, par exemple, dans un environnement Azure où l’administrateur n’est pas certain des segments de réseau Microsoft dont ils ont besoin pour accéder à OMI afin qu’Azure Management fonctionne correctement, il suffit de refuser l’accès à d’autres machines virtuelles sur le même segment de réseau pour au moins empêcher les mouvements latéraux des attaquants d’une machine à l’autre.

Pour plus d’informations techniques, le propre article de blog de Wiz détaillant ses conclusions peut être trouvé ici.

Leave a Comment

Your email address will not be published. Required fields are marked *