Researchers at Wiz have discovered four flaws in the OMI (Open Management Infrastructure) agent that is part of the Microsoft Azure product and which are pretty easy to exploit for escalation of privileges to root and the execution of malicious code. Microsoft has released fixes for these flaws and also published the CVEs today.
Azure admins are advised to follow the instructions on how to add the OMI repositories on the Linux distribution they’re using and update the agent to a non-vulnerable version (v 1.6.8.1 or newer).
The four flaws are:
Because OMI is a component that's deployed in the background, many admins don’t even realize that they are using it, but chances are that they are. The Azure services and tools that rely upon OMI and thus are vulnerable to the quartet of flaws are the following:
Possibly, there are more services that deploy OMI silently, but the above put users in a certain vulnerable position. Microsoft estimates that roughly half of all Azure instances are vulnerable to exploitation, so patching as soon as possible is imperative.
In short, because the OMI agent runs as root on the target system, accessing its ports remotely is an excellent RCE channel. As the researchers explain, the attackers can simply send a single packet to the agent that removes the authentication header, and they can become root on a remote machine. That’s ‘CVE-2021-38647’, relying on the external exposure of OMI management ports which is the default configuration.
The other three flaws, which are all privilege escalation flaws of lower but still high severity, enable the attacker to elevate privileges to root without going through an authentication step. The third one is a tad bit less risky because it's local, while the first two are remote.
Wiz reported the four flaws to Microsoft on June 1, 2021, and it took the software giant three weeks to confirm them all. The fixing patch was released on September 8, 2021, while the CVEs were published today with the Patch Tuesday pack. We consider this a timely response to an embarrassing discovery and another good reminder of why trusting cloud services to be “Secure by Default” is simply wrong.