Threat Signal Report

#OMIGOD IPS Signatures Released to Definitions

description-logo Description

Last week, researchers discovered the #OMIGOD vulnerability targeting Windows Azure containers. Disclosed to Microsoft by security vendor Wiz, these vulnerabilities contain 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.

OMI is an agent within Microsoft Azure, and is already preinstalled on various Azure cloud environments. Creating further confusion, there were reports that newly created Linux virtual machines still contained the vulnerability and updates were not automatically deployed to affected Azure machines. The resulting workaround would be for on premise administrators of the Azure machine(s) to install the OMIGOD patch themselves.

Compounding matters, there is little to no documentation on the OMI agent itself. On Thursday of last week Microsoft confirmed that automatic updates were available for some of the affected Azure extensions. According to Microsoft "Extensions are small applications that provide post-deployment configuration and automation on Azure VMs." Over the weekend, Microsoft has confirmed that there has been scanning by the operators of the Mirai botnet, DDOS botnets, various crypto mining outfits and other malicious actors.

What are the Technical Details of the Vulnerability?

The vulnerability is due to an error when the vulnerable software handles a maliciously crafted request. An unauthenticated remote attacker may be able to exploit this to execute arbitrary code via a crafted HTTP request. Ultimately, the vulnerability allows for unauthenticated attacker to perform remote code execution at the root level.

What is OMI?

According to Microsoft; OMI is an open-source project to further the development of a production quality implementation of the OMI CIMOM (common information model object manager) 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.

What Versions of OMI are Vulnerable?

All OMI versions below 1.6.8-1 are vulnerable.

What Services are Vulnerable?

Azure Automation

Azure Automatic Update

Azure Operations Management Suite

Azure Log Analytics

Azure Configuration Management

Azure Diagnostics

What Suggested Mitigations Are Available?

Please refer to the section - "What can I do to protect against these vulnerabilities?", in the Additional Guidance Regarding OMI Vulnerabilities within Azure VM Management Extensions link in the APPENDIX. This contains comprehensive list of mitigation steps and workarounds issued by Microsoft for #OMIGOD.

What is the Status of Coverage?

Customers running the latest IPS definitions are protected against this vulnerability with the following signature:




Traffic Light Protocol

Color When Should it Be used? How may it be shared?


Not for disclosure, restricted to participants only.
Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused. Recipients may not share TLP:RED information with any parties outside of the specific exchange, meeting, or conversation in which it was originally disclosed. In the context of a meeting, for example, TLP:RED information is limited to those present at the meeting. In most circumstances, TLP:RED should be exchanged verbally or in person.


Limited disclosure, restricted to participants’ organizations.
Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risks to privacy, reputation, or operations if shared outside of the organizations involved. Recipients may only share TLP:AMBER information with members of their own organization, and with clients or customers who need to know the information to protect themselves or prevent further harm. Sources are at liberty to specify additional intended limits of the sharing: these must be adhered to.


Limited disclosure, restricted to the community.
Sources may use TLP:GREEN when information is useful for the awareness of all participating organizations as well as with peers within the broader community or sector. Recipients may share TLP:GREEN information with peers and partner organizations within their sector or community, but not via publicly accessible channels. Information in this category can be circulated widely within a particular community. TLP:GREEN information may not be released outside of the community.


Disclosure is not limited.
Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction.