Les chercheurs en sécurité de Wiz découvrent un autre Azure majeur

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

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 reporting 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, même si heureusement, le pare-feu par défaut d’Azure en dehors de la machine virtuelle le limitera aux réseaux internes de la plupart des clients uniquement.

OMIGOD

L’inscription à l’un des nombreux services d’infrastructure Azure attrayants (tels que 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 conçu pour fonctionner 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 requiert une authentification afin de lier les commandes et les requêtes à un ID utilisateur (UID) spécifique, mais malheureusement, un bogue a provoqué l’acceptation des requêtes malformées qui omettent entièrement la strophe d’authentification comme si elles étaient données par le root l’utilisateur 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é avec un client HTTPS standard comme curl et donné des commandes raisonnablement lisibles par l’homme 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é chez Wiz Nir ohfeld m’a guidé à travers une démonstration de la vulnérabilité, il l’a décrite principalement en termes d’élévation 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, et 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 du réseau local Azure d’un client peut généralement utiliser l’OMI bogué pour 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 Centre système Microsoft (qui est annoncé à chaque nouvelle installation de Windows Server 2019 et versions ultérieures) et gérer les hôtes Linux sur site ou hors site avec elle se retrouve é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 autorisent à la fois la connexion à l’interface utilisateur et l’ajout d’une règle « autoriser par défaut » au pare-feu Azure d’une machine virtuelle Linux. arrive. « Oh mon dieu », me suis-je exclamé – et l’équipe Wiz a éclaté de rire. Il s’avère que c’est exactement ce qu’ils avaient nommé la vulnérabilité – OMIGOD.

Une prime difficile à collecter

Malgré la gravité évidente d’OMIGOD, qui comprend quatre bogues distincts mais connexes découverts par Wiz, la société a eu du mal à faire payer par Microsoft 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 fait don à The Open Group en 2012. Depuis lors, la grande majorité des engagements envers OMI ont continué à provenir de Redmond, employés par Microsoft contributeurs— open source ou non, il s’agit clairement d’un projet Microsoft.

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

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

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

Un coin poussiéreux de la chaîne d’approvisionnement

« OMI est comme une implémentation Linux de Windows Infrastructure de gestion« , a déclaré Ohfeld à Ars. « Notre hypothèse est que lorsqu’ils sont passés au cloud et ont dû prendre en charge les 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é directement sur chaque nouvelle installation de Windows Server, signifie qu’il est installé 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 attractive pour les attaquants.

Avec l’étendue 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é » serait rapidement découverte. Malheureusement, ce n’est pas le cas – OMI a un total inquiétant de 24 contributeurs, 90 fourchettes et 225 « étoiles » (une mesure de l’intérêt relativement occasionnel des développeurs) au cours des neuf années où il a eu un domicile 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 forks et près de 10 fois plus d’étoiles.

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

Un chemin de mise à niveau peu clair

L’employé de Microsoft Deepak Jain engagé 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. comment et quand ces correctifs pourraient être déployés universellement.

« 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 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 ont été obsolète. Les clients qui utilisent encore System Center avec Linux compatible OMI 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 inquiet d’exécuter OMI, vous pouvez le détecter facilement en recherchant des 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 publiques. Nous vous recommandons fortement 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 qui avoir besoin accès. 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 de l’un à l’autre.

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 deny règle, avec des allow règles en place uniquement pour les machines qui avoir besoin pour accéder à un service donné.

Lorsque cela n’est pas pratique, par exemple, dans un environnement Azure où l’administrateur n’est pas certain de ce dont les segments de réseau Microsoft ont besoin pour accéder à OMI pour qu’Azure Management fonctionne correctement, refuser simplement l’accès à partir d’autres machines virtuelles sur le même segment de réseau sera au moins empêcher le déplacement latéral 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.