The flaws, which existed in a popular cloud service called Azure App Services, specifically impacting Linux servers.
App Services is useful as it allows developers to simply write an application to serve HTTP and then push it to git. From there Azure will handle all deployment details and provide an Azure-managed domain name.
As described in their blog, the first vulnerability enabled an attacker with access to the server to take over the App Service’s git repository and implant phishing pages accessible through the Azure Portal.
The second one,allowed an attacker with an existing low-severity vulnerability on the application (SSRF) to upgrade to full code execution on the App Service and trigger the first vulnerability, as Intezer explained in this PoC:
Microsoft Azure: The first vulnerability
While investigating how webssh connects the web interface to the application node’s SSH service, the researchers noticed it uses hardcoded credentials “root:Docker!” to access the application node:
This poses no danger, they said, since the application node’s SSH port is not accessible from the internet.
“We observed earlier the KuduLite instance also ran SSH, so we used the same credentials on the KuduLite instance and were able to log in as root”.
The developers of the App Service KuduLite made sure admins were only able to log into it as a low privileged user, so this raised a few red flags.
These mitigations by Microsoft and their Microsoft Azure team were very effective in limiting this vulnerability’s potential damage.
Microsoft Azure: The second vulnerability
The second vulnerability resides in the KuduLite API of Microsoft Azure, which is very similar to Kudu’s API. The application node is able to send requests to the KuduLite API without requiring any access validation. This is especially problematic when considering a web app with an SSRF vulnerability.
An attacker who manages to forge a GET request may access the application node’s file system via the KuduLite VFS API:
This would enable an attacker to easily steal source code and other assets on the application node.
An attacker who manages to forge a POST request may achieve remote code execution on the application node via the command API:
By contrast, in Windows (where Kudu is used), packets sent from the application node to the manager node are dropped.
Finally, these two vulnerabilities can be chained together, since once an attacker achieves code execution with the second vulnerability—provided they have an SSRF vulnerability—they can exploit the first one.
Fortunately, Intezer reached out to Microsoft with our findings as part of the responsive disclosure process and the vulnerabilities were quickly acknowledged and fixed.