Microsoft Azure silently install management agents with vulns on your Linux VMs

The issue is that the unfixed Azure agent allows remote unauthenticated root access, if you send it a request without an Authorization: header. It is supposed to verify that requests come from Azure’s management infrastructure, but the check is broken.

has to be -- I hope

The basic firewall (Network Security Groups) blocks network access by default. So you have to grant the attacker access to the port and IP.

One would assume that absence of credentials would necessarily = auth failure.

Like, the basic flow would check the validity and, implicitly, the presence of the auth header. To bypass auth in the case of the absence of the header itself would need to be an explicit conditional. IF no header, then authenticated. Right? That’s crazy.

I suppose I could look at the code.

Been using cloud-init on Azure Linux VMs for a long time (5+ yrs). Did you experience this on a specific distro?

I'm a complete dork in terms of cloud infrastructure and hosting, so I'm heavily drawn to providers with great UX/DX, documentation, simple interfaces, and predictable cost such as Linode, Cloudflare, railway.app, Vercel to name a few examples.

Whenever I have to work with Azure I get uneasy... (SAML...)

This is not great. In terms of ethical concerns I would rather use Azure than AWS for example.

I don't know your use case, but if you need access to a Windows Desktop you can download some ready made VMs from Microsoft

https://developer.microsoft.com/en-us/microsoft-edge/tools/v...

Hello fellow time traveler

It doesn't seem that abysmal, more like not maintained by enough people.

Are they optional? As far as I understand, AWS doesn't do the same.

Is that an official statement?

The vuln is that API calls with no auth headers run as root.

They're not mandatory- we don't use these agents, and instead consider every VM to be replaceable.

The threat is not the cloud provider and this has nothing to do with physical access.

The software vulnerability can be exploited by anyone with network access to the machine.

I don't think that's the threat model here - this is more a lateral movement vector for an attacker that's able to get inside your service network perimeter.

Correct. Sadly the issue is that the cloud provider installed an agent that only blocks requests if the authentication header does not contain correct authentication.

If you remove the authentication header, that check never fires, and it considers you authenticated. Then it proceeds to let you run any command.

Now the point is, anyone who can send you messages can strip the authentication header, so anyone who can send you messages can execute arbitrary commands.

The thread model isn't the cloud provider, it's anyone who can spoof the IP of your cloud provider's metadata service CIDR block. These tend to be link-local IPs, so it's common for the cloud boundary firewall itself to block anything incoming from that block, so the attacker would need to already in the perimeter, but it isn't exactly hard to get inside the data center just by being another tenant. This is one reason why it's common to block at the host level any packets with a src IP in the metadata service's CIDR block, just in case. You give up certain forms of remote management capabilities, but that is often worth it not to open up back doors developers are rarely even aware of.

And use disk encryption. I've encountered situation when hoster mounted root partition and wrote his scripts inside after OS installation. Fortunately it broken network, so I noticed it. Very sneaky and unexpected.

The vuln is that API calls with no auth headers run as root.

Bare metal ig.

You can avoid unwanted agents by avoiding cloud provider.

There is an important qualification, however: the AWS SSM agent does not start a network server at all (it connects to their API endpoint) and it doesn't do anything if you don't add the appropriate permissions to the instance's role.

The GCP agent similarly does not listen to the network.

Both the Google and AWS agents are written in Go, too, so they're unlikely to have the classic C/C++ errors, more likely to use libraries rather than reinventing the wheel, and using a higher-level language often makes the logic easier to understand. Neither of those are foolproof or prevent logic errors, of course, but I would still expect a lower bug density all other things being equal.

You may have just borked your VM's. OMI installed because it is needed for certain feature integrations (most notably Log Analytics/Azure Monitor).

It's worth mentioning many of these features which deploy OMI do so in a way that does not set up a listening port. Therefore, the impact of the vulnerability is pretty low. Indeed, I just spun up a Ubuntu VM and while it got a vulnerable version of OMI, it doesn't have an open port.

The LA table VMBoundPort will let you assess if you've got one configured for listening on the OMI ports. I think a lot of the people in this thread, and possibly the people writing the articles aren't Azure SME's, hence all the panic and grumbling and eye rolling.