Wiz security researchers discover another major vulnerability in Azure

The security provider in the Wiz cloud, which recently made headlines by discovering a massive vulnerability in the database service managed by Microsoft Azure’s CosmosDB, has found another hole in Azure.

The new vulnerability affects Linux virtual machines in Azure. They end up with a little known service called IMO installed as a by-product that allows you to enable any of the various management options and / or log reports in the Azure user interface.

In the worst case, the IMO vulnerability could be exploited for remote root code execution, although fortunately the default Azure firewall, outside of the virtual machine, will limit it only to internal networks. of most customers.

OMIGOD

Opting for any of Azure’s various attractive infrastructure services (such as distributed logging) automatically installs a little-known service inside the Azure virtual machine in question. This service, OMI (short for Open Management Interface), is designed to work similarly to the Microsoft Windows WMI service, allowing the collection of records and metrics, as well as some remote management.

Part of the IMO specification requires authentication to link commands and requests to a specific user identifier (UID), but unfortunately an error caused malformed requests that omit the stanza to be completely accepted. ‘authentication completely as if given by the root user himself.

When configured for remote management, the IMO runs an HTTPS server on port 5986, which can be connected to a standard HTTPS client such as curl and have given reasonably human-readable commands to the XML-derived SOAP protocol. In other configurations, the IMO only runs on a local Unix socket in /var/opt/omi/run/omiserver.sock, which limits its exploitation only to local users.

As a senior security researcher at Wiz Nir Ohfeld made me go through a demonstration of the vulnerability, described it primarily in terms of privilege escalation: an attacker who has a checkpoint on an affected virtual machine can issue any arbitrary command as root using IMO syntax.

In larger environments where the IMO listens on a network port, not just on a local Unix socket, it’s also a fantastic way to pivot laterally – an attacker getting a shell on a virtual machine on the local network A client’s Azure can typically use the wrong IMO to gain control of any other virtual machine on the same network segment.

Turns out Azure isn’t the only place you’ll find IMO. Organizations that adopt the Microsoft System Center (announced in each new installation of Windows Server 2019 and later) and that manage on-premises or out-of-press Linux hosts also end up with the wrong IMO version deployed on those hosts managed.

While Nir and I talked about the scope of the vulnerability, I pointed out the likelihood that some Azure clients would activate logging in the user interface and add a “default permission” rule to the Azure firewall of a virtual machine. Linux; sure it’s a bad practice, though passes. “Oh my God,” I exclaimed and Wiz’s team burst out laughing. It turns out that this is exactly what they had called the vulnerability: OMIGOD.

A reward hard to pick up

Despite the obvious severity of OMIGOD, which includes four separate but Wiz-related errors discovered, the company had difficulty getting Microsoft to pay it a reward for its responsible discovery and disclosure. In a series of emails reviewed by Ars, Microsoft representatives initially dismissed the vulnerabilities as “out of reach” of Azure. According to Wiz, Microsoft representatives in a phone call characterized the errors in IMO as an “open source” problem.

This claim is complicated by the fact that Microsoft was the author of IMO, which he gave to The Open Group in 2012. Since then, the vast majority of commitments to IMO have continued to come from Microsoft partners, based in Redmond. open source or not, of course this is a Microsoft project.

In addition to Microsoft de facto owned by the project, Azure’s own management system automatically deploys the IMO; administrators are not required to access the command line and install the package themselves. Instead, it automatically deploys to the virtual machine each time an IMO-dependent option is clicked in the Azure GUI.

Even when Azure management deploys IMO, the administrator who activated it has no obvious warning. We have found that most Azure administrators only seem to discover that IMO exists if their / var partition is filled with their basic dumps.

Finally, Microsoft waived its refusal to pay an Azure Management error reward for OMIGOD and awarded Wiz a total of $ 70,000 for the four errors that make it up.

A dusty corner of the supply chain

“IMO is like a Linux implementation of the Windows management infrastructure,” Ohfeld told Ars. “Our assumption is that when they moved to the cloud and had to support Linux machines, they wanted to bridge the gap, to have the same interface available for both Windows and Linux machines.”

The inclusion of the IMO in Azure Management and the Microsoft System Center, announced directly in each new installation of Windows Server, means that it is installed as a low-level component on a surprising number of major Linux machines. critical, virtual or not. The fact that it listens for commands on an open network port in some configurations, using extremely well-known protocols (SOAP over HTTPS), makes it a very attractive target for attackers.

With the scope of both deployment and potential vulnerability, one could reasonably expect many eyeballs to be in the IMO, enough to quickly discover a vulnerability summarized as “you forgot to make sure the user authenticated.” Unfortunately, this is not the case: IMO has a disturbing total of 24 contributors, 90 forks and 225 “stars” (a measure of relatively casual developer interest) during the nine years it has had on Github.

By contrast, my own ZFS Sanoid management project, which doesn’t listen on any port and has been accurately described if incarnately as “a couple of thousand lines of Perl writing,” has more than double the col. laborers and forks and almost ten times the stars.

By any reasonable standard, an infrastructure component as important as the IMO should receive much more attention, which raises questions about how many others dusty corners of the software supply chain are not inspected or maintained evenly.

An unclear update path

Microsoft employee Deepak Jain committed the necessary repairs to the IMO GitHub repository on August 11, but, as Ars directly confirmed, these fixes had not yet been deployed to Azure as of August 13. September. Microsoft told Wiz it would announce a CVE on Patch Tuesday, but Wiz researchers expressed uncertainty as to how or when these fixes could be universally deployed.

“Microsoft has not shared its mitigation plan with us,” Ami Luttwak, technical director of Wiz, told Ars, “but based on our own customer’s telemetry, it could be difficult to correct properly. IMO is embedded in several Azure services and each may require a different upgrade path. “

For arbitrary Linux systems managed remotely from the Microsoft System Center, the upgrade path can be even more complicated, as System Center Linux agents have become obsolete. Clients who still use IMO-enabled Linux Center System may need to manually upgrade the IMO agent.

Mitigation for affected users

If you are a Linux system administrator, you are concerned that you may be running OMI, you can easily detect it by looking for listening ports in TCP 5985 and 5986 (TCP 1270, for OMI agents deployed by the Microsoft System Center instead of Azure), or a Unix plug located underneath /var/opt/omi.

If you have the Unix socket but not the ports, you are still vulnerable until Microsoft deploys a patch, but the scope is limited to local privilege escalation only.

In cases where the IMO listens on TCP ports, it joins all interfaces, including public ones. We recommend that you limit access to these ports through the Linux firewall, regardless of whether your IMO instance is repaired or not.

In particular, security-conscious administrators should carefully limit access to this and any other network service only to network segments that actually need access. Machines running Microsoft System Center obviously need IMO access on client systems, just like Azure’s own infrastructure, but the clients themselves don’t need IMO access from one to another.

The best practice for reducing the network attack surface, with this and any other potentially vulnerable service, is a global firewall. deny rule, with specific allow rules applicable only to machines that need to access a particular service.

When this is not practical, for example, in an Azure environment where the administrator is not sure which network segments Microsoft needs to access IMO for Azure Management to work properly, just deny access to other virtual machines in the same network segment prevent lateral movement of attackers from one machine to another.