WTF? Microsoft makes fixing deadly OMIGOD flaws on Azure your job
Clouds usually fix this sort of thing before bugs go public. This time it's best to assume you need to do this yourself
Microsoft Azure users running Linux VMs in the IT giant's Azure cloud need to take action to protect themselves against the four "OMIGOD" bugs in the Open Management Infrastructure (OMI) framework, because Microsoft hasn't raced to do it for them.
As The Register outlined in our report on this month's Patch Tuesday release, Microsoft included fixes for flaws security outfit Wiz spotted in Redmond's open-source OMI agents. Wiz named the four flaws OMIGOD because they are astonishing.
The least severe of the flaws is rated 7/10 on the Common Vulnerability Scoring System. The worst is rated critical at 9.8/10.
Complicating matters is that running OMI is not something Azure users actively choose.
As Wiz explained: "When customers set up a Linux virtual machine in [Azure], the OMI agent is automatically deployed without their knowledge when they enable certain Azure services.
"Unless a patch is applied, attackers can easily exploit these four vulnerabilities to escalate to root privileges and remotely execute malicious code (for instance, encrypting files for ransom)."
Faced with that threat, it seems reasonable to expect that Microsoft would fix all the OMI agents it deploys and update VMs running vulnerable versions. That's the sort of thing cloud operators usually do – and do quietly before flaws are made public, so that attackers don't go to town.
Microsoft hasn't done so on this occasion. Indeed, the super-corp has kept deploying known bad versions of OMI when users create new Linux VMs.
- Microsoft's end-of-summer software security cleanse crushes more than 80 bugs
- Azure's now-fixed Cosmos DB flaw could have been exploited to read, write any database
- All your DNS were belong to us: AWS and Google Cloud shut down spying vulnerability
The Windows goliath's latest advice, dated September 16, is: "Customers must update vulnerable extensions for their Cloud and On-Premises deployments as the updates become available per schedule outlined in table below."
Bad formatting means the table is wider than the section of Microsoft's web page, so rather a lot of lateral and vertical scrolling is required to learn that automatic updates have been enabled for six of the Azure services impacted by the bugs. But another seven services require manual updates. And even then, the automatic updates are a gradual rollout over the course of this week and not immediate.
It's on you to make sure you're running the latest OMI software in your Linux guests; a vulnerable build may have been injected into the virtual machine if you enabled certain services (see the aforementioned table.)
Understandably, Microsoft's actions – or lack thereof – have not gone down well.
They’ve also failed to update their own systems in Azure to install the patched version on new VM deployments. It’s honestly jaw dropping.— Kevin Beaumont (@GossiTheDog) September 16, 2021
Researchers quickly found unpatched instances of OMI.
Security vendor Censys, for example, wrote that it discovered "56 known exposed services worldwide that are likely vulnerable to this issue, including a major health organization and two major entertainment companies."
Happily, the biz also found "mass external exposure as seen with other hosts in the past (Microsoft Exchange comes to mind) does not appear to be present in this case."
In other words, there may not be that many vulnerable machines facing the public internet, or not many that are easily found. "The small footprint can be associated with nuances of how the OMI service responds, and that exposing OMI to the Internet likely requires deliberate effort," Censys noted.
Focus instead then will be on Microsoft's approach to patching and redeploying its open-source code.
That all said, the method needed to exploit the remote-code execution flaw is rather simple. We've already had sight of public proof-of-concept exploit code.
Sophos's description of the flaw explains the peril:
Astonishingly, the bug seems to boil down to a laughably easy trick.
Rather than guessing a valid authentication token to insert into a fraudulent OMI web request, you simply omit all mention of the authentication token altogether, and you’re in!
Your next step is therefore obvious: patch ASAP. Because, as Censys puts it, "these issues would easily allow compromise with the highest-level privileges possible into any host which is running OMI." ®