惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

人人都是产品经理
人人都是产品经理
博客园_首页
IT之家
IT之家
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Vercel News
Vercel News
美团技术团队
D
Docker
WordPress大学
WordPress大学
T
Tailwind CSS Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
The Cloudflare Blog
Y
Y Combinator Blog
F
Fortinet All Blogs
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
G
Google Developers Blog
爱范儿
爱范儿
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
月光博客
月光博客
MongoDB | Blog
MongoDB | Blog
S
SegmentFault 最新的问题
GbyAI
GbyAI
Hugging Face - Blog
Hugging Face - Blog
Microsoft Azure Blog
Microsoft Azure Blog
A
About on SuperTechFans

Wiz Blog | RSS feed

Meet Wiz for M365: Bringing SaaS into the Security Graph Bringing Security Visibility to Vercel with Wiz Axios NPM Distribution Compromised in Supply Chain Attack Tracking TeamPCP: Investigating Post-Compromise Attacks Seen in the Wild The Wiz Blue Agent, now Generally Available Beyond the Badge: What Achieving Microsoft’s Certified Software Designation Means for Your Cloud Security Introducing the Green Agent: AI-Powered Remediation for the Cloud Three’s a Crowd: TeamPCP trojanizes LiteLLM in Continuation of Campaign KICS GitHub Action Compromised: TeamPCP Strikes Again in Supply Chain Attack Introducing the Wiz Red Agent- AI-Powered Attacker Introducing Wiz AI Application Protection Platform (AI-APP) Introducing Wiz Agents & Workflows: Security at the Speed of AI AI Runtime Threat Detection: From Input to Real-World Impact Trivy Compromised: Everything You Need to Know about the Latest Supply Chain Attack It’s Official: Wiz Joins Google Understanding and Reducing AI Risk in Modern Applications Introducing Wiz Tenant Manager: Multi-Tenant Management for Federated Organizations The Agile FedRAMP Playbook, Part 4: Reactive Risk Management through Enriched Incident Response Wiz Achieves CPSTIC Certification in Spain Seeing AI Clearly: Building Visibility Across Modern AI Applications The Agile FedRAMP Playbook, Part 3: Preventative Risk Management by building Secure by Design Wiz Leads the 2026 Latio Application Security Report with awards in 4 categories Building an Agentic Cloud Security Ecosystem: A Reference Architecture with Wiz MCP and Infosys Cyber Next The Agile FedRAMP Playbook, Part 2: Proactive Risk Management with Continuous Monitoring Cloud-native Security for your Windows environment: Announcing the Wiz Runtime Sensor for Windows Would You Click ‘Accept’? Automatically detecting malicious Azure OAuth applications using LLMs Wiz Named a Leader in The Forrester Wave™: Cloud Native Application Protection Solutions, Q1 2026 From Detection to Remediation: It’s Time to Rethink AppSec Around Exploitability and Root Cause Fixes The Agile FedRAMP Playbook, Part 1: Why Risk is Your Best Starting Point Introducing AI Cyber Model Arena: A Real-World Benchmark for AI Agents in Cybersecurity
Revisiting OMI: Analysis of CVE-2022-29149, a privilege e...
2022-08-05 · via Wiz Blog | RSS feed

In the last year, we invested time and effort researching cloud middleware, the software that bridges between customers' virtual machines and cloud providers’ managed services.

As part of June 2022 Patch Tuesday, Microsoft published a patch to fix a new privilege escalation vulnerability, CVE-2022-29149 in Open Management Infrastructure (OMI), with a CVSS score of 7.8 (the highest score possible for vulnerabilities that allow local privilege escalation). OMI is cloud middleware software used by Azure, typically installed on Linux VMs without explicit customer notification, like most other cloud agents. This is the fifth known vulnerability affecting OMI. Wiz Research found and reported the previous four vulnerabilities in June 2021, including an unauthenticated remote code execution vulnerability dubbed “OMIGOD” (CVE-2021-38647).

OMI is installed automatically by multiple popular Azure services usually as part of the OMS agent (Operations Management Suite). While it is documented by Microsoft, customers may still not be aware of its existence. This lack of awareness can lead to lower remediation rates as customers don’t address associated risks or make necessary updates. We've validated that CVE-2022-29149 is exploitable and collaborated with Azure to improve patching and customer notification processes for such issues. We thank Microsoft for the fruitful collaboration that resulted in the onboarding of OMI dependent agents (Azure’s Operations Management Suite agentDesired State Configuration agent and Azure Diagnostics agent) to the Extension Auto-update feature of Azure. Read more about the collaboration between Wiz and Azure in our blog.

In this post, we share technical details about the vulnerability based on our own research and provide detection and remediation instructions. Additionally, we review the cloud middleware issue and explain why it can leave cloud customers at risk.

See Microsoft’s advisory for more information and mitigation guidance here. Wiz customers can also check the in-app Threat Center, which links directly to our detailed threat advisory.

Who is at risk?

This latest vulnerability affects every version of OMI earlier than 1.6.9-1. According to Microsoft’s advisory, the following services currently do not support auto-updates, meaning that Linux virtual machines deployed in Azure using any of these services remain vulnerable unless updated:

  • OMI as standalone package

  • System Center Operations Manager (SCOM)

  • Azure Automation

  • Azure Automatic Update

  • Azure Operations Management Suite (OMS)

  • Azure Log Analytics

  • Azure Diagnostics

  • Azure HDInsight

  • Azure Container Monitoring solution

  • Azure Security Center

  • Azure Sentinel

What is cloud middleware?

Cloud middleware software is often silently installed by CSPs when customers onboard services. Also, cloud middleware often runs with high privileges. This combination of lack of customer awareness and high privilege access may expose customer environments in case of vulnerabilities. Software of this nature increases the attack surface of cloud environments, potentially exposing customers to local privilege escalation and remote code execution vulnerabilities. The current shared responsibility model does not clearly define who is responsible for securing cloud middleware, and as a result customers often fail to address the associated risks, leaving their environments and data vulnerable even after vulnerabilities have been disclosed and patched.

To learn more about cloud middleware and its effect on cloud customers' security posture, you can read our latest blog post on the subject.

What is OMI?

A notable example of cloud middleware software in Azure is OMI, short for Open Management Infrastructure. It is an open-source project sponsored by Microsoft in collaboration with The Open Group. Essentially, it is Windows Management Infrastructure (WMI) for UNIX/Linux systems. OMI allows you to gather statistics and synchronize configurations across your environment. Thanks to the ease of use and abstraction that OMI provides, it sits behind the scenes of many Azure services including Open Management Suite (OMS), Azure InsightsAzure Automation, and more.

Technical details

Microsoft introduced a large patch to OMI that involved multiple changes across several files, which tells us that fixing this vulnerability was not a simple task. Upon reviewing the changes, we observed that the patch included a major design change in the internal communication protocol between the various components of OMI. For one thing, the developers removed the secretString mechanism, which had previously been used to verify some of the most critical internal communications – so why did the developers of OMI decide to get rid of it?

Figure 1: OMI secretString mechanism removal

Fooled by randomness

secretString is a randomly generated password used for securing communications between several of OMI’s components and verifying messages originating in the highly-privileged OMI process. You can refer to the appendix in our OMIGOD publication to learn how we were able to manipulate OMI to elevate our privileges to root in cases where OMI did not have this secretString mechanism in place.

The secretString is randomly generated when the OMI process is launched. But how random is it? Let’s review the method that generates the “random” secretString:

(1) shows that the current system time serves as the seed for the randomly generated string. Since OMI generates the secretString upon launch, it is possible to reveal the seed, since we can find out how long the OMI process has been running. Knowing the secretString seed, we can predict the secretString and forge messages as though they were coming from the high-privileged OMI process: By replacing the time method (1) in the above code snippet with the actual time at which the OMI process was launched, we can recover the secretString.

I know your secret

What possibilities does this secret open? Apparently, we can use the recovered secretString to bypass the patch Microsoft introduced to address CVE-2021-38645 (one of the LPE vulnerabilities we disclosed in June 2021) and elevate our privileges to root.

Figure 2: CVE-2022-29149 exploitation

Detection & remediation

Following our collaboration with Microsoft on the issue, Microsoft onboarded OMS, LAD and DSC to the Automatic Extension Upgrade feature. With this feature, these agents (and therefore also OMI, which comes bundled with them) can be updated as soon as a new version is introduced. We join Microsoft’s recommendation and urge customers to enable automatic updates for the OMS, LAD and DSC agents and encourage customers to migrate to Azure Monitoring Agent which does not rely on OMI. Automatic Extension Upgrade will ensure that Azure customers get any important security updates to the agent as soon as possible with no manual overhead, and is therefore an excellent way to mitigate the vulnerability detailed above.

Customers who do not opt in to auto-updates need to perform manual steps to patch their environment. For most Azure services, OMI can be updated using the package manager.

However, the CPE details for the OMI vulnerability do not specify the OMI package. Without any link between the CVE and the OMI package, the vulnerability is invisible to traditional vulnerability management tools, making it hard to track.

To assess an Azure Linux VM’s vulnerability to CVE-2022-29149, Azure customers can connect to the VM and run the commands below in the terminal to check which version (if any) of OMI is installed:

  • For Debian systems (e.g., Ubuntu): dpkg -l omi

  • For Redhat based systems (e.g., Fedora, CentOS, RHEL): rpm -qa omi

If no results return, this means OMI isn’t installed and the machine is not vulnerable. If any results are returned, you’ll see what version of OMI is installed. The patched version for the recently announced vulnerability CVE-2022-29149 is 1.6.9-1. See Microsoft’s advisory for more information and mitigation guidance here.

Detection & remediation with Wiz

Wiz has a dedicated team of researchers who track new high-profile vulnerabilities in order to provide appropriate and immediate detection for cases like this one. Thanks to their vigilance, the Threat Center started detecting vulnerable workloads the same day that CVE-2022-29149 was announced.

Figure 3: Wiz Threat Center pre-built detections for the recent OMI vulnerability

Wiz customers can use the Threat Center to find all affected workloads in their environment, prioritized according to effective risk, and review the in-product advisory for additional guidance.

The cloud middleware dataset

To address the increasing risk of cloud middleware, Wiz recently launched a community-driven cloud middleware dataset to map all the agents that cloud providers install on customers' machines along with the additional attack surface they introduce. This GitHub page gives cloud customers the power to understand the security risks posed by certain cloud services.

Mapping all the agents that cloud providers are installing is not a trivial task. We call on the entire security community to help us achieve this ambitious goal by contributing and helping us keep this database updated.

We encourage you to check out our GitHub page, share it with your colleagues, and help us in our effort to create a better and more secure cloud.

Finally, CVE-2022-29149 is now listed on cloudvulndb.org, a community-driven open cloud vulnerability and security issue database.