Easily hack into Azure Bastion and Azure Container Registry via XSS vulnerabilities

Microsoft Azure Bastion and Azure Container Registry have each been found to have one potentially “dangerous” security flaw that, if taken advantage of, may have resulted in a cross-site scripting (XSS) attack being carried out on the affected service. XSS attacks take occur when threat actors insert arbitrary code into a website that would otherwise be trusted. This code is then run each time visitors who are not aware of the attack visit the website.

Both of the vulnerabilities that Orca found take use of a vulnerability in the postMessage iframe, which makes it possible for Window objects to communicate with one another across domains.The vulnerabilities allowed for illegal access to the victim’s session inside the compromised Azure service iframe. This may result in serious repercussions, such as unauthorized data access, unauthorized alterations, and interruption of the Azure services iframes, among other things. This meant that the vulnerability could be exploited to embed endpoints into remote servers by utilizing the iframe element. This would eventually result in the execution of malicious JavaScript code, which would compromise sensitive data.

However, in order to take advantage of these vulnerabilities, a threat actor would first need to undertake reconnaissance on various Azure services in order to identify vulnerable endpoints contained inside the Azure interface. These endpoints may be missing X-Frame-Options headers or have Content Security Policies (CSPs) that are inadequate.

The attacker will continue to exploit the misconfigured endpoint after they have successfully embedded the iframe in a remote server. They are concentrating on the postMessage handler, which is responsible for handling remote events like postMessages.

The adversary might later construct suitable payloads by embedding the vulnerable iframe in an actor-controlled server (for example, ngrok) and establishing a postMessage handler that delivers the malicious payload if they first analyzed the genuine postMessages sent to the iframe from portal.azure[.]com and then analyzed the postMessages sent from portal.azure[.]com to the iframe.

Because of this, when a victim is tricked into visiting the compromised endpoint, the “malicious postMessage payload is delivered to the embedded iframe, triggering the XSS vulnerability and executing the attacker’s code within the victim’s context.”

During the course of a proof-of-concept (PoC), it was discovered that a postMessage that had been carefully written might be used to alter either the Azure Bastion Topology View SVG exporter or the Azure Container Registry Quick Start in order to carry out an XSS payload.