Oh, my God, Please Patch OMIGOD!
Last week I was talking with a friend.
“Azure has a fun new vulnerability.”
“Oh yeah? What is it?”
“They silently install this OMI thing on all their Linux VMs. It’s a remote management framework. It talks over HTTPS. If you remove the authentication header from a request, you get root on the VM.”
“What?! Oh my God!”
“Exactly. They’re calling it OMIGOD.”
The reality is a bit more nuanced, but not by much. On September 14, 2021, Microsoft announced four CVEs in the Open Management Infrastructure framework (OMI). OMI is a management tool installed on every Azure Linux VM that runs as root and can present either an HTTPS listener or TCP socket for remote management of the VM.
By sending a “specially crafted request”—in the HTTPS case, by just removing the authentication header—you can remotely execute code as the root user. The flaw appears in all OMI versions below v1.6.8-1.
This feels like it should be impossible in 2021, but here we are. The cause of the vulnerability is a simple logical error in how the authentication is processed. It’s not a bug, it’s just bad logic, which is generally harder to spot in testing. That said, surely someone should see what happens to a root binary when you simply don’t log in?
The vulnerabilities were discovered by researchers at Wiz. Their writeup is the authoritative guide on the subject and is well worth the read.
OMI doesn’t do automatic updates and many users will not think to patch themselves, since they didn’t install this thing and may not even know they have it. The flaw also appears in a bunch of Azure PaaS services, which Microsoft will patch, but that will probably take a while. As of September 17, 2021, they still hadn’t updated the OMI agent in Linux VMs spun up via the Azure console.
(The vulnerability also affects SCOM, Microsoft’s on-premises systems management software, which is widely deployed and itself difficult to patch.)
According to a thread from the incomparable Kevin Beaumont, a former senior threat intelligence analyst at Microsoft, the Mirai botnet malware is already exploiting this vulnerability and mass scanning appears to be underway.
Some, including at Microsoft, have suggested that because most Linux VMs are behind firewalls, this isn’t really a big deal.
Right.
First of all, much of the work of exploiting a network is in moving laterally and elevating privileges. These vulnerabilities make both easy. Secondly, remote management interfaces are left open on the internet all the time. Finally, as said, many admins won’t know they’re vulnerable because they aren’t aware of the silently-installed OMI.
The main message for Azure customers: patch now. Every Linux VM running on Azure should be considered vulnerable.
Detection of active exploitation within a SIEM (like our Cloud SIEM) is a matter of hunting for audited events to find commands used by attackers to execute remote code. In the case of OMIGOD, that would be hunting the SCXcore service. In Azure Linux VMs, these run out of a specific working directory—look for activity in ‘/var/opt/microsoft/scx/tmp’.
You should also monitor for attempted network connections specifically to ports 5986, 5985 or 1270, as these are the OMI defaults. These flows will contain legitimate management traffic as well as traffic from a potential attacker, so sifting legitimate signals from noise is key here.
Unfortunately, the only foolproof remedy is to hand-audit your Azure environment for Linux VMs and hand-patch OMIGOD. In the cloud era, and with security vendors promising magic AI bullets, this all feels very 1995. But, again, as so often happens in infosec, here we are.
