Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Open Management Infrastructure (OMI) is an open source project managed by Microsoft for managing Windows/Linux systems. Essentially, it’s Windows Management Infrastructure (WMI) for UNIX/Linux systems. This is installed on all VMs within Azure by default to send arbitrary commands to the server.

OMI is an amazing thing to target. First, it runs as Root, has been a UNIX socket and HTTP API. This looks great for both privilege escalation and remotely gaining access to the system. On some systems, this is even exposed remotely!

The flow is going from the CLI to the server. However, due to a coding error, if the authorization error is not present then the authorization is passed through. As C programmers are expected to do, the memory for the authinfo struct is initialized to 0. These two facts turn the user into root from the request!

The next bug has the same result, but comes from an entirely different location. The architecture has three parts: CLI (where users make calls), the OMIEngine that is a lower privilege process that proxies requests to the next section and OMIServer which executes the commands.

OMIserver trusts the OMIengine for the identity of the user; the OMIengine is expected to validate the auth state of the user as well. Some message types get proxied straight to OMIserver while others are validated for auth. What would happen if we used a forwarded request, which added the auth header, without initializing it? Root yet again! Same initialization issue as before.

The final bug is a race condition in handling the authentication request. When authenticating to OMIengine a socket connection is made to the OMIserver as it awaits a response on the auth request. However, since the handling of the auth is NOT different between OMIcli and OMIserver, we can impersonate the response!

Only a valid id is needed on the request, which appears to be somewhat sequential; hence, this is not a problem. So, making an auth request with a bad password, then racing the response, we can provide our own authentication response. If we control it, of course we are now root!

Considering these agents run as root, they are installed on all Azure VMs and some are publicly exposed, this is one of the worst bugs that could possibility be found. It is amazing how bad the authentication process was in this; some of it was just bad luck while some of it was bad logic. Interesting finds though!