Researchers are shedding light on a Microsoft Azure misconfiguration bug that leaked sensitive access tokens, which could have given hackers access to virtual machine instances and cloud-based storage buckets. Since its discovery, an update has fixed what researchers said was a misconfiguration vulnerability in the Microsoft Azure Portal.

CyberArk found the bug in September and Microsoft “unintentionally” fixed it within two weeks as part of a regular update to its Azure platform.

Researchers said the Microsoft Azure Portal bug is tied to URL parsing within a JavaScript file used within Azure’s Extension Manifest. The Microsoft Azure Portal is a web-based and unified console for building, managing and monitoring cloud infrastructure.

“In this vulnerability in Microsoft Azure, attackers could take over Azure Accounts by exploiting a misconfiguration bug in Azure Portal’s manifest,” wrote Omer Tsarfati, a cyber security researcher at CyberArk.

A manifest, in this context, is a JSON configuration file, which defines settings to be used by web applications. A JSON, or JavaScript Object Notation, is a lightweight format for storing and transporting data sent from a server to a web page.

Within this matrix, researchers said they observed “telemetry reports being sent to a non-existing domain and that most of those telemetry requests include access tokens.”

Microsoft defines access tokens as “an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account associated with the process or thread.”

CyberArk went as far as creating two proof-of-concept (PoC) exploits against the vulnerability. In both PoCs the goal is to gain control of user access tokens.

To do this, researchers developed two DNS manipulation techniques – one local and one remote. Both take advantage of the error made by Microsoft in its Azure Portal’s manifest code where the path “AzureHubs/Hubs” is interpreted as “urehubs” domain. The error triggered Azure to attempt to connect to a nonexistent hostname “urehubs” (dropping the “Az” from the beginning of the URL) under certain conditions.

One PoC is based on the fact “urehubs” is interpreted as a URL that is missing the .com or any top-level domain suffix. Because of this, Azure automatically attempts to connect to the non-existent domain “urehubs” running through a litany of TLDs ranging from .com, .net and .org.

CyberArk’s first PoC takes advantage of this by setting up an HTTP server with the hostname “ureuhbs” and acquires a signed certificate. “Eventually, every Azure user in this local domain who surfs to the Azure portal… will send its access token to the attacker’s server,” CyberArk said.

Exploiting the bug in the wild, researchers said, requires taking control of the TLDs associated with the hostname “ureuhbs.” “As a responsible and protective measure, we bought 27 ‘urehubs’ domains with different suffixes to prevent malicious attackers from exploiting this bug, including urehubs.com, urehubs.net, urehubs.org, etc,” researchers wrote.

An important prerequisite to the attack also included a valid certificate (for the local server and signed by a public root CA). CyberArk said this allowed an attacker to abuse different “urehubs” domains and ultimately have access tokens transmitted to them.

“In a POC… we were able to successfully exploit this vulnerability and got an Azure token of an external organization,” CyberArk wrote.

Microsoft updated the Azure on September 6, 2019, with three lines of code and closed the door for the hack. That was after CyberArk discovered the bug, but before it could report the vulnerability. “By adding the URL to the href attribute, Microsoft managed to mitigate the vulnerability by ensuring that the URL is not only the path but a full valid URL,” CyberArk wrote.

Researchers estimate the window of time hackers had to exploit this vulnerability was a mere two weeks. However, they stress this bug serves as a harbinger of other potential cloud bugs. Companies need to stay on their toes when it comes to relying on a third-party cloud infrastructure and the third-party cloud security.

“Cloud services are great options for many companies. Still, you must remember that relying on ‘someone else’s infrastructure’ is relying on someone else security measures – which can be a risky endeavor,” Tsarfati wrote.