OMIGOD Vulnerability Exposes Virtual Machines Running Inside Azure

Late last month, researchers from cloud security firm Wiz found a new vulnerability that allows Azure users to access cloud databases of other users, breaking the principle of secure multitenancy. They dubbed it ChaosDB.

This month, they found another one. In some respects, it's not as bad as the ChaosDB vulnerability because it doesn't break multitenancy. But in other respects, the new vulnerability, OMIGOD, is actually worse.

The ChaosDB vulnerability was a result of a misconfiguration error on the part of Microsoft. When the company fixed it, the vulnerability went away. Customers just needed to reset their security keys. Microsoft patched it quickly, and no exploits have been reported.

It was a serious vulnerability — Wiz researchers were able to get into the databases of Fortune 500 companies — but the impact was limited.

Not so with the newest one, dubbed OMIGOD, which is already being exploited by attackers.

"ChaosDB has a more complicated exploit path and can only lead to account takeover," said John Bambenek, principal threat hunter at cybersecurity firm NetEnrich and incident handler at the SANS Internet Storm Center. "With [the OMIGOD vulnerability], on the other hand, it was very easy to convert victim machines into botnets, where large-scale exploitation makes much more sense."

Details on OMIGOD Vulnerability

One of Microsoft's products is Linux virtual machines running on its Azure cloud. To manage these virtual machines, Microsoft installs an open source management tool called OMI, which stands for Open Management Infrastructure.

Wiz researchers discovered four critical vulnerabilities in OMI, which can be used to remotely execute code within the network with a single request and to escalate to root privileges.

Customers using any of the following services are vulnerable: Azure Automation, Azure Automatic Update, Azure Operations Management Suite, Azure Log Analytics, Azure Configuration Management, Azure Diagnostics and Azure Container Insights.

But OMI is also used in on-premises data centers when companies use the Microsoft System Center for Linux.

"It is less likely on-prem installations would have OMI exposed to the internet," Bambenek told Data Center Knowledge. "But in so far as they do, the same vulnerability and exploit should work."

According to Wiz, more than 65% of Azure customers are at risk.

That's bad, but that's not the worst of it.

The worst is that OMI is deployed inside customers' virtual machines by Microsoft, but most customers won't even know it's there. There's no clear documentation in Azure about the deployment, monitoring and updating of OMI, according to Wiz security researcher Nir Ohfeld.

And since OMI is running within customers' machines, Microsoft doesn't consider itself responsible for what happens with it. Normally, in cloud infrastructure, the "shared responsibility model" means that the cloud provider is responsible for the security of the infrastructure as a whole, and the customer is responsible for securing what happens inside its own virtual machines.

Microsoft has released a patch, but it's up to customers to find the affected systems and install the patch.

"There is no easy way for customers to know which of their VMs are running OMI since Azure doesn’t mention OMI anywhere on the Azure portal, which impairs customers’ risk assessment capabilities," wrote Ohfeld. "This issue highlights a gap in the famous shared-responsibility model."

Wiz has released an OMIGOD identification and remediation checklist to help companies address the issue.

Microsoft has also released its own guidance to help customers address the OMIGOD vulnerability.

Unfortunately, not everyone got the memo or installed the patches before hackers got wind of the vulnerability.

Several security firms, including Bad Packers and GreyNoise, have confirmed that attackers are scanning the web for vulnerable Azure Linux virtual machines — including a Mirai botnet operator.

“IT security teams trust cloud providers like Azure to provide a secure service and, in the event of a bug or vulnerability, to take immediate steps to mitigate the risk,” said Yonatan Amitay, security researcher at cybersecurity firm Vulcan Cyber. “In almost all cases, the cloud providers we use remediate the vulnerabilities found in their services before they are exploited at scale.”

That hasn’t been the case here, and security experts like Amitay say that Microsoft is dropping the ball.

“In my personal opinion, Microsoft should be responsible for fixing it if possible,” Amitay told Data Center Knowledge. “Or, at least, release a detection and patching tool that the customers can use to do it automatically.”

Instead, enterprises using Microsoft Azure virtual machines are already being hit by the Mirai botnet and are being hijacked to use for mining cryptocurrency.

“I think this vulnerability is more exploitable because of its unbelievable ease of use,” Amitay said.

In fact, he added, the security problems are so basic that they look like something out of the 1990s.

“There is no doubt in my mind that a cloud provider opting to install services as a result of enabling logging or management functionality is wholly responsible for ensuring its security,” said Archie Agarwal, founder and CEO at cybersecurity firm ThreatModeler.

The fact that the OMI service was almost unknown, and running with root privileges, is particularly worrying, he told Data Center Knowledge.

“This has potentially left a gaping hole for remote code execution that is in no way the fault of Azure customers,” Agarwal said.

“The biggest increase in cybersecurity in 20 years was when Microsoft went to apply patches automatically by default,” said NetEnrich’s Bambenek. “The same should be true in the Linux world.”

There are also steps that data center cybersecurity managers can take to be proactive against similar potential vulnerabilities, he added.

“Any system on any platform should be using automated configuration management to ensure only authorized packages are installed, configurations are managed, and systems are appropriately locked down,” Bambenek said.

Insecure Management Software: It’s Not Just Azure

The same issue that is at the heart of the OMIGOD vulnerability — insecure management software running on customer machines, unknown to those customers — will probably show up with other cloud providers, Amitay said.

"I don't think it's a Microsoft thing," he said. "Other cloud providers also had vulnerable components."

To protect themselves, data center cybersecurity managers should stay on top of media reports and threat intelligence, and prioritize and remediate vulnerabilities as they arise, Amitay said.

"Also, use security best practices," he added. "Security architecture always helps to mitigate the impact of being exposed to unknown vulnerabilities."

"One thing I can almost guarantee you is that people will be looking at all providers for this type of issue going forward," said Tyler Shields, chief marketing officer at JupiterOne and board member or board advisor for several cybersecurity firms. "This is going to get researched for all cloud service providers — both by the good guys and the bad ones."

Although cloud providers should be responsible for fixing problems like this, it should be a situation with multiple checks and balances, he added. "Ultimately, the enterprise is responsible for the security of the code running in their container no matter what," Shields told Data Center Knowledge.

OMIGOD proves that outsourcing patch management to a cloud service provider isn't flawless, said Oliver Tavakoli, chief technology officer at Vectra, a cybersecurity firm.

"The bill of materials that end up in a software image as a result of a few clicks of a mouse are not guaranteed to be secure," he said. "This is a case of — mostly — trust but — definitely — verify."

Configuration Errors

At the end of the day, it's not cloud providers' own vulnerabilities that are the most problematic, Amitay said.

They might seem worse because they're outside of enterprise control. But the real threat is in your own configuration errors.

"Providers like AWS and Azure are aggressively proactive about the cyber hygiene of their products," he said. "The real risk in cloud security stems from the fact that 95% of all cloud security breaches are due to user error and cloud service user misconfigurations."