Api Zipdeploy

[Eva Dunckel]

Completeerror- requests.exceptions.ConnectionError: HTTPSConnectionPool(host='admin-testapp.scm.netpost', port=443): Max retries exceeded with url: /api/zipdeploy?isAsync=true (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -2] Name does not resolve',))

Azure Functions are a serverless way to run code. They support different programming languages and can scale quickly. As a developer, it is particularly easy to deploy functions directly from Visual Studio or Visual Studio Code.

In order to still enable a WebDeploy or ZipDeploy, the SCM endpoint must be published in addition to the regular endpoint. Both endpoints require different health probes, so retrieval and control cannot go through the same Application Gateway listener. At the SCM endpoint, the probe can check for 401 and at the regular endpoint of the function itself, depending on the configuration, but usually for 200.

Unfortunately, deployment via Visual Studio no longer works, even if the following steps are carried out. In order to be able to start the deployment of the function from the VS, the publish profile can be downloaded from the azure portal, adapted and imported. The publish profile contains the original URL for the function (line 7) and the URL for the SCM (line 4). Both lines must be adjusted to the new URLs.

Deployment via FTPS, on the other hand, works without any problems, since the FTP endpoint cannot be protected by the network configuration. It is even available when public access is completely disabled. The URL from the Deployment Center and the user under Application Scope must be used for the login.

For the Application Scope User, only the character string starting with the $ symbol is used. The host is the FTPS endpoint, but without the /site/wwwroot path and without the ftps:// scheme. It is important to use FTP as the protocol, since SFTP (in contrast to FTPS) only activates encryption after the connection has been established.

The target is the new SCM endpoint via the Application Gateway, where the path /api/zipdeploy or /api/publish?type=zip is added like described in the documentation. You can then check whether the deployment was successful:

The SCM portal, also known as the Kudu portal, cannot be opened via the regular SCM URL because it automatically redirects to the original SCM URL. However, if the call is made with the path /basicauthviaproxy (in this example -scm.zuehlke.cloud/basicauthviaproxy), the login is possible. You must use the credentials (Application Scope) from the FTPS Deployment Center blade again:

Tenable One Exposure Management Platform enables you to gain visibility across your attack surface, focus efforts to prevent likely attacks, and accurately communicate cyber risk to support optimal business performance.

The Tenable Cloud Security research team discovered a remote code execution vulnerability affecting Microsoft Azure cloud services such as Function Apps, App Service, Logic Apps and others, as well as other cloud sovereigns.

A remote code execution (RCE) vulnerability affecting Function Apps, App Service, Logic Apps and other Microsoft Azure cloud services, and other cloud sovereigns, was discovered by the research team at Tenable Cloud Security. The vulnerability exploits the Kudu source control management (SCM) service, which underlies many major Azure services.

The EmojiDeploy vulnerability is achieved through CSRF (Cross-site request forgery) on the ubiquitous SCM service Kudu. By abusing the vulnerability, attackers can deploy malicious zip files containing a payload to the victim's Azure application.

The vulnerability enables RCE and full takeover of the target app. The impact of the vulnerability on the organization as a whole depends on the permissions of the applications managed identity. Effectively applying the principle of least privilege can significantly limit the blast radius.

The vulnerability exploits the Kudu SCM service. This service underlies many major Azure services, among them: Azure Functions, Azure App Service, Azure Logic Apps and others. The vulnerability is now fully remediated; previously, anyone using any of the following common core services was vulnerable to the EmojiDeploy vulnerability:

Kudu is the engine behind Git deployments in Azure Web Apps. It is a web-based Git repository manager that provides SCM for deploying and managing applications on Azure. The SCM web panel acts as a management interface for these services.

Thanks to the rapid response and cooperation of the Microsft Security Response Center (MSRC), EmojiDeploy is fully remediated. However, there are actionable steps you can take to defend against similar vulnerabilities in the future, and against exploitation of SCM capabilities.

We can categorize three major Azure services as Azure Web Services: App Service, Function Apps and Logic Apps. These services have something in common: they all deploy the SCM panel by default. The SCM panel grants IT teams, DevOps and web administrators access to modify and manage their Azure web applications.

The SCM panel requires Azure Active Directory (AAD) authentication. If the user has authenticated to their Microsoft account through the browser, they can simply navigate to the SCM panel and log in. Otherwise, they need to log in manually with their Microsoft-authorized credentials.

The Same-Site attribute is a browser security feature introduced in 2016; its default value is set to "Lax". The purpose of the Same-Site attribute is to protect against cross-origin information leakage/attacks, e.g. cross-site request forgery (CSRF). According to the request for comments (RFC), the "None" value in the Same-Site attribute provides no protection against cross-origin attacks.

While researching the SCM panel, I made several HTTP origin checks by trying to replicate requests in BurpSuite/Postman while sending different origins. The default origin that is sent and accepted by the server is:

The origin check is also a site-wide/service-wide check. Using a black box approach, I raised the hypothesis that there is a regex on the server that checks for malformed origins as another layer of defense in order to defend against cross-origin attacks like cross-origin resource sharing (CORS) misconfiguration, CSRF and more.

At this point, we have solid grounds to believe that special characters, combined with a domain under our control, can be used to bypass the regex that is being used to defend against cross-origin attacks.

We managed to bypass the origin check, but only with a web proxy and not by using a browser. In order to adapt the attack to the browser client, the browser should accept my special characters as a valid origin/URL.

Surprisingly, earlier browser versions accept special characters as valid URLs and pass the requests sent with the manipulated URL as the value of the origin header. However, modern browsers only accept "_" and "-". The following table shows the current compatibility of each browser tested:

To summarize: This finding allows an attacker to create a wildcard DNS record for his own domain and send cross-origin requests with special characters that eventually will be accepted by the server origin check.

While reviewing the Kudu service source code and the REST API documentation, most endpoints were PUT/DELETE, other non-standard HTTP methods, or accepted only non-standard Mime-types. However, a couple of endpoints did meet the requirements:

Usually, this is used as mitigation for CSRF and cross-origin attacks. When an attacker sends a custom header in a cross-origin request, it is no longer flagged as a standard request by the browser and gets blocked due to Same-Origin-Policy.

Unfortunately, the SCM server does not validate or even require the custom headers originally sent by the client. This means an attacker can construct an attack with a request to /api/zipdeploy without those custom headers. The request will be flagged as "standard" by the browser and will be accepted.

The original request to /api/zipdeploy is sent with application/x-www-form-urlencoded;charset UTF-8 Mime-type. Sending a standard CSRF request with the charset omitted returns Forbidden. Furthermore, you can not force charset UTF-8 from the browser.

Microsoft has fixed EmojiDeploy, and your organization is no longer vulnerable to it. However, there are lessons that can be learned to mitigate the effect of similar vulnerabilities and attack vectors.

Least Privilege: While EmojiDeploy directly compromises the target application, the wider impact for the organization depends on the permissions of the compromised managed identity. Applying the principle of least privilege can make the difference between application takeover and complete organizational takeover.

Tenable detects unrestricted network inbound access to the SCM site (which is open to the public by default) to protect customers from similar attacks, and implement a least privilege approach. For example, here is an organization with a misconfigured App service SCM site:

Liv Matan is a Senior Security Researcher at Tenable, where he specializes in application and web security. As a bug bounty hunter, Liv has found several vulnerabilities in popular software platforms, such as Azure, Google Cloud, AWS, Facebook, and Gitlab. He was recognized as Microsoft's "Most Valuable Researcher" and has presented at conferences such as DEF CON Cloud Village and fwd:cloudsec.

Enjoy full access to our latest web application scanning offering designed for modern applications as part of the Tenable One Exposure Management platform. Safely scan your entire online portfolio for vulnerabilities with a high degree of accuracy without heavy manual effort or disruption to critical web applications. Sign up now.

Enjoy full access to a modern, cloud-based vulnerability management platform that enables you to see and track all of your assets with unmatched accuracy. Purchase your annual subscription today.

3a8082e126