MS Azure - AppService Configuration Vulnerability

Please note this critical vulnerability affects mainly those who use AppService for PCI DSS related services. As the service is not designed according to best security practices and security standards ITS NOT COMPLIANT with the PCI DSS standard at least its requirement 6. This in the end means the complete customer service is not compliant too. This is because the AppService is not designed and maintained according to best practices and industry standards as PCI DSS requires.

I've started with development of some application with targeting the Azure as the hosting platform. Because I was ethical hacker for last 10 years I was interested how secure the Azure is before I'll put anything there. I've read all that stuff related to sandboxes and isolation level of VM's running in the cloud, especially those related to web applications... Its good to trust but also to check.

Once I've created the account to the Azure Portal I have deployed my first small Asp.Net application to it and just checked what the application can do on the local host. Not that much. It seems to be well jailed in the sandbox, but I didn't spend so much time with it. But after some time I have discovered it can write to strange locations.

So I decided to install the ASPX file browser to allow me do things easier. With it I've found I have complete write access to the home directory, where the wwwroot also exists. I didn't want to believe my eyes first. I was still hoping I'll not be, at least, able to modify web config or deploy something to the BIN folder. I was really, really wrong. it was possible.  I was still hoping I'll not be able to execute uploaded content. So I have created a new Hello World application. It consisted just two files, wtf.aspx and the wtf.dll. I delivered both of them to the server using the regularly deployed file manager and viola, it is working. It was possible to execute it.

I didn't see this very basic web server configuration vulnerability for more than 5 or 6 years. It is not so easy to discover it during regular penetration test as if the web application deployed is not vulnerable or if there is no other configuration problem on the server its not possible to exploit it. This is also maybe the reason why I didn't see it for that long time. 

So in short, if there is vulnerability or intentional back door in the web application which allows write to the local file system and it is deployed in the Azure Web Service it is possible to deploy and execute any code as anonymous user without possibility to be tracked at all (of course, the IP address can be visible somewhere in the log, but probably not with the action performed so correlation will be hard). Its also possible to modify the regular application running. Because the deployed code will be running under the same application pool as the regular application it will have access to all resources the regular application have.

There are more attack vectors there and also some prerequisites. Prerequisites are:

a) vulnerable application

b) intentional backdoor

c) dangerous administrative interface

Attack vectors could possibly be:

For two first prerequisites they are quiet straightforward. Vulnerability it is exploitable by regular application users (in case of internet web application by everyone with access to vulnerable functionalities).

Another attack vector could be related to the administrative interface allowing the local file administration what can be a designed application feature. In this case, the application administrator can deploy whatever files without any doubts that somebody else will be able to discover who made changes. That's because only the one information visible in the audit log will be the IIS account has changed something on the drive. Without internal application logging it is again impossible to track the user who has made the change.

This vulnerability would be ranked as CVSS 9.0 according to version 2.0 of this vulnerability scoring system.

It can be also ranked as A5 – Security Misconfiguration according to OWASP top 10 (2010/1013/2017)

Possible consequences (out of many others) could be:

- Increased bills for computation resources and data transfers

- Stealing of sensitive configuration information (i.e. connection strings or machine keys)

- Stealing of the application data

- Deployment of applications containing malicious code

- Deployment of phishing applications

- Attacking of the sandbox while breaking out of it would allow access to internal Azure network

I just want to warn everybody this "very basic" vulnerability exists there. As I've been told by MS  (after almost 2 months of very very lazy email communication) this is by design and it is required by some applications to make them possible to self-auto update themselves. What...???

They namely mentioned Wordpress. As I don't have so much experience with it's deployment, hardening and administration I just opened Hardening WordPress guide to check if it is really that bad it requires a write access to wwwroot. Of course not. It recommends the "standard 755/644 respectively" to be set.

---

So, I din't want to publish my communication with MS about reporting this vulnerability. In the beginning, I even didn't want to make it publish, but unfortunately...

This is official answer from https://azure.microsoft.com/en-us/blog/microsoft-payment-card-industry-pci-data-security-standards-dss-revised-for-2016/

Hi – Thanks for your interest. Please note that our PCI certification does not cover individual customer applications, since those are the responsibility of the customer. Customers building PCI apps on Azure are responsible for developing those apps securely, and certifying their specific app. As you noted in your blog, the ability for an app to have R/W access to content is driven by customer requests for that functionality and is by design. This however does not make App Service itself non-compliant with PCI DSS requirements.

The main assumption you made is that the customer has created an app with an (intentional or unintentional) flaw that would then expose it to a vulnerability. Also, the write access in this case is not given to a location on local disk, but rather it is a virtual disk that is mounted just for the app content and is sandboxed to the app’s process. Given these restrictions, write permissions for app content looks different than running a site locally on an IIS web server. Since writes don’t affect the entire server, but just the app, the onus for protecting it is on the customer that implements it.

As stated this does not affect the security of the product overall or our PCI compliance. However, we really appreciate the opportunity to dive into these shared responsibility concepts and these are good points for customers to keep in mind when creating their apps.

Thanks,

Alice

---

I wrote really kind answer to this but it was deleted. So I replied again:

Hello Alice,

I really appreciate your answer. I replied already, but my answer disappeared from whatever reason. Never mind, I'll write it again.

Lets take a look on your response in detail:

Please note that our PCI certification does not cover individual customer applications, since those are the responsibility of the customer

I 100% agree. Secure application development is responsibility of Application developer. Or, customer. Its not MS responsibility. Maybe I unhinged you because I mentioned requirement 6 of PCI DSS. Thats because its about secure systems and applications. Of course, the vulnerability discussed is more related to requirement 2. But I didn't see your configuration standards. So I mentioned requirement 6. As in my opinion you do not maintain secure systems (not applications) see my explanation bellow.

This however does not make App Service itself non-compliant with PCI DSS requirements.

This exactly renders the App Service itself non-compliant with PCI DSS. Why? Because you do not follow best security practices and industry standards. Even yours own. See https://technet.microsoft.c... for details. Disable anonymous access to server directories and resources. Do not allow anonymous writes to the server. This is exactly what you are not doing. Moreover, and hopefully nobody will deploy WordPress to PCI DSS environment, you don't even follow WordPress hardening guide as it says: set 755 / 644 permissions on the wwwroot, never 777. But what do you have? 777. READ/WRITE/EXECUTE. On whole D:\home. Moreover, Read on whole D:\local so its possible to grab sensitive configuration information from there (such as machine keys for view state encryption). Unfortunately, this is not possible to be avoided from operational perspective.

The main assumption you made is that the customer has created an app with an (intentional or unintentional) flaw that would then expose it to a vulnerability.

The assumption I have made does not have anything to do with the Azure App Service Critical, OWASP A.5, CVSS 9.0 Configuration Vulnerability I have described. The vulnerability is there. Its not a question if the application makes available or not. It is just there. Without any discussion. And the vulnerability is not described just like you have write access to the server. There are both WRITE and EXECUTE permissions. That is the reason why I have classified it as Critical.

If you say its like application turns it into vulnerability I would rather say that securely developed application only mitigates the risk the vulnerability will get exploited.

Also, the write access in this case is not given to a location on local disk, but rather it is a virtual disk that is mounted just for the app content and is sandboxed to the app’s process. Given these restrictions, write permissions for app content looks different than running a site locally on an IIS web server. Since writes don’t affect the entire server, but just the app, the onus for protecting it is on the customer that implements it.

I don't get this engineers explanation... I have never said the attacker can get out of the sandbox. As it is correctly written, the potentially malicious code uploaded and executed is running in the same sandbox and with same permissions as the application. But it also means it has access to same resources, such as key vault, database, local VIRTUAL file system (i can't see any difference if its really local or virtual. I can write there, read it, moreover it will be distributed to all HA/Failover endpoints - i can't see the reason why engineering guys said it. If I put some file there, it stays there even after restart).

If we say that potential attackers can't reach the OS resources itself, I would agree. But if the will get in by exploiting discussed vulnerability they have unlimited amount of time to try to break out of the sandbox. For free. Customer will pay for computational / networking resources...

As stated this does not affect the security of the product overall or our PCI compliance.
Unfortunately, it does. I have described why. Because it is potentially possible to reach all resources, replace the code, collect database data, deploy phishiing pages, DoS it basically whatever. So the integrity, availability and confidentiality (of the application) can be 100% affected. Moreover, its not possible to track who attacked it. Its another breach of PCI DSS. ANd as customers does not have any possibility how to fix it they really have only the one option... to develop and deploy secure applications. What is from my perspective impossible.

I am sorry I am publishing it like this. But I tried MSRC and it didn't work for two months. You can check TRK044100089 over there.