Skip to main content
Researchers at Intezer released details behind a previously undisclosed vulnerability that could allow Microsoft Azure users with low-level privileges to leak private data from any virtual machine extension plugged into their cloud environment. (Photo by Jeenah Moon/Getty Images)

Researchers at Intezer released details behind a previously undisclosed vulnerability that could allow Microsoft Azure users with low-level privileges to leak private data from any virtual machine extension plugged into their cloud environment.

Microsoft’s Azure Virtual Machine Linux uses an integrated plugin system that allows users to install first and third-party applications. In order to manage and update those installations, Azure installs a guest agent on systems to help coordinate and configure extension files. One of those communications takes place with an HTTP service called Wire Server that is used by Azure’s VM manager and helps users to query sensitive but encrypted data beyond what those extensions are authorized to access.

Decrypting these data require a private key and transport certificate, both of which the researchers were able to forge due to the fact that the certificates endpoint doesn’t validate transport certificates. While the IP address used to communicate with Azure components has a rule in place to automatically drops packets from anyone but the root user, the researchers discovered that the same machine is also connected to another IP address. By directing their requests to that second IP, Intezer was able to communicate with the server despite not having a privileged account.

The vulnerability was quietly patched in March, Ari Etan, but vice president of research at Intezer said they first discovered the flaw and informed Microsoft approximately a year ago. Etan said without internal Microsoft data, they are unable to confirm whether it has ever been exploited in the wild, but Microsoft’s CVE entry indicates it has not.

According to Etan, the flaw would first require an attacker to have an unprivileged or low-level user account on a victim’s cloud environment. Then, it would need to be paired with another vulnerability, like this one, that can recover plaintext passwords from Azure VM environments. Etan said this is likely only one of multiple pathways to exploit the flaw, and that the Guardicore vulnerability they settled on was just the first one they tested.

“To be honest we were looking for the fast track here, so maybe there are other vulnerabilities we could use…or find something from scratch, but [vulnerability chaining] is the path we wanted to go because we wanted to show the quick value from an attacker’s perspective,” he said.

Microsoft appears well aware of the way attackers are using Azure extensions, including to create or modify user privileges. Earlier this year the company said that Azure extensions for VMAccess, custom scripts and anti-malware are all being actively leveraged in attacks against client cloud environments; used to elevate privileges, mine cryptocurrency and disable security protections.

“There is no doubt that the VMAccess Extension is a handy way for an attacker to gain initial access to VMs with elevated privileges,” Microsoft wrote in March. “Such notorious usages of the extension may sometimes be difficult to notice. As an example, leveraging VM Access to create a common service user or modifying an existing one.”

Etan said in this case, because the flaw was in Microsoft’s code, there is little that businesses could have done pre-patch to protect themselves, though following cybersecurity basics like having distinct passwords for different endpoints could have limited the damage.

However, he emphasized that one of the biggest drivers of cloud insecurity today is the lackadaisical approach of users who believe that their cloud provider is the only one responsible for securing their assets, when in reality it is often a two-way street.

“I have a lot of discussions with Cloud and DevSecOps [people], sometimes they think once we publish a vulnerability on Azure, they have the feeling that Azure is in charge of security in the cloud and not them, and that’s not the message I want to deliver,” said Etan. “Azure is in charge of their part but you’re in charge of your part and mixing them together, that’s what you need to do to stay protected.”

Original article source was posted here

All rights reserved Jenson Knight.