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 agent, Desired 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 Insights, Azure 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?
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:
int GenerateRandomString(char *buffer, int bufLen)
{
const char letters[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
time_t t;
int i;
unsigned int availableLetters = sizeof(letters) - 1;
srand((unsigned) time(&t)); // <--- (1)
for (i = 0; i < bufLen - 1; ++i)
{
buffer[i] = letters[rand() % availableLetters];
}
buffer[bufLen - 1] = '\0';
return 0;
}(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.
Detection & remediation
Following our collaboration with Microsoft on the issue, Microsoft onboarded OMS, LAD and DSC to the 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.
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.
