APIs in Zombieland: How abandoned Microsoft Azure URL Allowed Exposed Unauthorized Access
Take action: Invest time in shutting down old APIs and URLs in your application. Or if nothing else locking them out from access. It's a thankless part of the job, both for Product and Development, until someone hacks the API. Then everyone will ask "how could you miss this!"
Learn More
What do you call it when you have left an abandoned vulnerable and compromised API exposed to the public? Microsoft calls it "prompt remediation".
This week Microsoft announced that they have "promptly" removed a compromised, abandoned reply URL from the Azure AD application. This removal effectively closed an unauthorized access vector into the Microsoft's Power Platform API.
What is a reply URL?
A reply URL, also known as a redirect URL or callback URL, is a crucial component in the context of web applications that implement authentication and authorization processes, particularly within the OAuth and OpenID Connect frameworks. It serves as an endpoint where users are redirected after they have completed an authentication or authorization process on an external identity provider's website.
Imagine you're using an app that allows you to sign in with your Facebook or Google account. When you choose that option, the app takes you to the Facebook or Google website to log in. Once you've successfully logged in there, you're brought back to the app you started from. This return trip is what we call a reply URL. It's like a virtual gateway that connects the two places – where you logged in and where you want to use your account.
Now, in this situation with Microsoft's Power Platform, a reply URL was abandoned, meaning it was left unused and unattended.
What happened?
Security researchers have discovered an abandoned vulnerable reply URL in the Microsoft Power Platform within the Azure Active Directory (AD) environment, granting unauthorized access to elevated permissions and control within an organization.
By exploiting this vulnerability researchers were able to divert authorization codes – these are like digital keys that grant access – towards themselves. By doing this, they could convert authorization codes into access tokens, which are essentially virtual keys that open the doors to certain parts of the system.
Once inside, the attackers were potentially able to acquire special privileges, giving them control over certain aspects of the system. This kind of unauthorized control could lead to misuse of the system or access to information that should be restricted. The flaw allowed the researchers to essentially gain administrative powers within the Power Platform API, but they didn't take the exploit any further – they stopped short of actually carrying out any malicious actions.
What can we learn from this?
While all development teams rush to develop new features, functionalities and attract customers, nobody wants to think about the end of life of product components. Product, launch, growth and even maintenance get plenty of focus. Retiring an API/URL doesn’t get the same focus. It doesn't have an owner, because nobody will celebrate the shutting down of an API.
So we tend to live in the land of API zombies, never fully dead but never maintained. Until someone hacks them.
There are many reasons to retire APIs. Take some time in your sprint, planning, strategy to invest in the end of life of the product components.
