Experts at Wiz have found that when certain methods of deploying web applications in the Azure App Service make their source code publicly available.
For four years, a bug persisted in Microsoft Azure App Service that allowed viewing the source code of applications deployed there. The Wiz experts who discovered this “bug” believe that hackers may well have already exploited it.
Azure App Services (or Azure Web Apps) is a cloud-based platform for hosting websites and applications. Wiz experts point out that the vulnerability only manifests itself in cases where web applications are written in PHP, Python, Ruby or Node and are deployed in the cloud using the Local Git option, which allows the local Git repository to be synchronized with the Azure App Service container.
The problem is that when using the Local Git option, the contents of the .git directory where the source code is stored also ends up in a cloud container and can be accessed by anyone (/ home / site / wwwroot).
Attempts to fix
To fix this problem, Microsoft added a web.config file to the .git directory to restrict this access. The problem is that only Microsoft IIS understands web.config files. As a result, if using C # or ASP.NET, the application is deployed using IIS and access to .git is appropriately restricted.
With certain methods of deploying web applications in Microsoft Azure App Service, their source code is made publicly available.
But if the application is written in PHP, Ruby, Python or Node, then it is deployed using other web servers (Apache, Nginx, Flask, etc.) that do not take into account the settings of the web.config files. This means that the source code of the application remains publicly available.
Moreover, it turned out that the web.config files contained an error (unclosed tag) that prevented IIS from reading it correctly; however, in the end, access to .git was still blocked, so the file was doing its job.
However, later it turned out that users who used other means of offloading local resources also risked their sources: if a file was created or modified in the Azure App Service container using FTP, Web Deploy or SSH before deploying Git, the service worked in the “in-place deployment, in which Git is deployed only to open, public directories.
This made the source code publicly available for all PHP, Node, Ruby, and Python applications deployed after September 2017 using Local Git on the Azure App Service with nominal settings.
How to increase investments in IT insourcing by one and a half times
IT in banks
Also vulnerable are applications written in the listed languages that have been deployed since September 2017 using any other Git resources after a file has been created or modified directly in the application container.
Only applications deployed using IIS are free from this vulnerability.
What to do?
Between December 5 and December 17, 2021, Microsoft sent messages to users of its service on how to check for a problem and try to neutralize it. Basically, it all comes down to disabling in-place deployment and moving the .git directory to a safer place.
“Unauthorized disclosure of the source code of proprietary web applications can be a big nuisance for their developers,” says Anastasia Melnikova, director of information security at SEQ. “In addition to the fact that it threatens to leak intellectual property in itself, the source code quite often contains all kinds of development artifacts, such as preset passwords, or errors that attackers can use in attacks. The scale of the problem is all the more great since hackers of various kinds are constantly scanning network resources for public Git repositories. Most likely, many more people had access to the source code of all vulnerable web applications that the Wiz experts write about than the developers expected. “
Cloud storages have received a three-level protection against ransomware
The Wiz team ran the following experiment: they deployed a vulnerable application to the Azure App Service and connected it to an unused domain to see if anyone would try to exploit the vulnerability. We didn’t have to wait long, four days later, numerous requests from unknown sources poured into the .git directory. The cybercriminals did not experience any serious problems with exploiting the vulnerability.