[Azure] Insecure development practice: exposing access credentials

[et_pb_section admin_label=»section»]
[et_pb_row admin_label=»row»]
[et_pb_column type="4_4"][et_pb_text admin_label="Text"]During recent penetration tests, we identified a development practice that exposes platform access credentials Microsoft Azure Web Sites – a service that allows the development and hosting of web applications in the cloud. This practice can lead to the compromise of the associated FTP server and, consequently, allow illegitimate read and write access to the source code, log files, and underlying operating system.

According to our cell of Cyber Threat Intelligence, more than a thousand access credentials are made public on GitHub, Pastebin and other code or file hosting services.

Context

The service Microsoft Azure Web Sites allows you to generate and export a configuration file PublishSettings This file, designed to be imported into PowerShell or Visual Studio to facilitate application administration within a continuous development framework, allows these applications to query the Azure API without manual procedures. It is particularly sensitive because it contains the usernames and passwords for accessing the FTP and deployment servers. MSDeploy.

Obtaining the file

The file in question can be downloaded from the resource page corresponding to the web application on the Azure portal:

 

We then obtain a file named $SiteName.PublishSettings in which are entered the usernames and passwords allowing access to the deployment server MSDeploy (in green) and to the FTP server (in blue):

 

Compromise

The practice we were referring to is as follows: often, the file PublishSettings is appended to the project's source code. The file then reaches the various stakeholders in the development chain (development teams, security auditors, quality engineers, etc.) and, in the most critical cases, it is published on online services such as GitHub or in the website directory (although’Azure blocks access to this type of file from the browser by default), thus giving an attacker the opportunity to access and use the sensitive information stored there.

Let's assume that we have obtained the file PublishSettings presented in the previous section. We simply need to follow the links. publishUrl and to enter the provided usernames and passwords.

For example, we can connect to the FTP server and access the source code:

 

We can also add or delete files. Below, we have deleted index.html and added poc_ftp.html :

 

 

Our file poc_ftp.html is indeed accessible on the web application:

 

It is notably possible to execute system commands by dropping a webshell :

 

Finally, we can access the application logs:

 

 

This log file contains the requests made to the web server. It includes the GET request we made to the server to access the file. poc_eval.html :

 

Numerous other log files are accessible on the FTP server: system logs containing information about the operating system, application logs storing the outputs of functions, debug, or extension logs indicating the name and version of extensions added to the application.

Recommendations

The content of this file is particularly sensitive and unencrypted; therefore, special attention should be paid to the permissions applied to it and the opportunities for reading by an illegitimate third party.

Intrinsec recommends the following practices:

• Do not save the file PublishSettings in the project directory;
• Delete the file once it has been imported;
• Implement unit tests in the continuous integration pipeline to verify the absence of a P fileublishSettings in published directories;
• Include verification in the tests performed by your vulnerability scanners;
• Consider a specific use case in detection strategies for the different stakeholders in the development chain;
• Monitor the leakage or exposure of this type of document;
• Communicate the best practices outlined above to the development teams.

 [/et_pb_text][/et_pb_column]
[/et_pb_row]
[/et_pb_section]