3rd Party Risk Management , Application Security , Cloud Security
Azure App Service's Flaw Exposed Source Code for 4 Years'NotLegit' Flaw Affects All PHP, Node, Ruby and Python-Based Apps Using Local Git
Microsoft's Azure App Service had a security flaw, which researchers call "NotLegit," that kept your Local Git repository in the service publicly accessible, according to a security blog from Wiz.io. The flaw means the source code of customer applications written in Java, Node, PHP, Python and Ruby has been exposed for four years - since its deployment in September 2017.
See Also: Live Webinar | Education Cybersecurity Best Practices: Devices, Ransomware, Budgets and Resources
Based on the results of the honeypot set by the researchers, they also believe that the security flaw has been actively exploited in the wild by threat actors.
Microsoft has recently fixed the flaw and issued alerts to a "limited subset" of customers via email communication between Dec. 7 and Dec. 15. The alerts ask affected users to take certain actions to protect their applications.
"We have notified the limited subset of customers that we believe are at risk due to this and we will continue to work with our customers on securing their applications," the Microsoft Security Response Center says in a blog post.
The 'NotLegit' Vulnerability
Azure App Service is a cloud-based platform for hosting web applications and websites. There are multiple ways to deploy source code and artifacts to the Azure App service, and one of these is Local Git, the researchers say. Once users initiate a Local Git repository in the Azure App Service container, it lets them push their code to the server, according to Wiz.
The researchers say that while deploying git repositories to web servers and storage buckets, one needs to ensure that the .git folder is not uploaded since it contains information such as the source code, developers' email addresses, and other sensitive data. But Microsoft deployed the git repository for the Azure App Service within the publicly accessible directory /home/site/wwwroot. "This was a known quirk to Microsoft and to protect your files it added a 'web.config' file to the .git folder within the public directory that restricted public access," the researchers say.
But the quirk still created a problem. "Only Microsoft's IIS webserver handles web[.]config files … if you use C# or ASP.NET, the application is deployed with IIS and this mitigation is perfectly fine," the researchers say. But if a user uses the PHP, Ruby, Python or Node programming language, the app is deployed on different web servers, such as Apache, Nginx, Flask, etc., that do not support web[.]config files and the vulnerability can be exploited, they say.
While analyzing the code, researchers also discovered that Microsoft’s web[.]config file contained a typo - the configuration tag wasn’t closed properly. This error proved to be a boon, the researchers say, as it ended up blocking access to the entire directory.
"It's disturbing, but perhaps not too surprising, that we are seeing configuration errors on the part of the cloud service provider," Sounil Yu, CISO at JupiterOne, tells Information Security Media Group. "We all make mistakes, and Microsoft, Google and Amazon are not infallible," he says, citing the recent example of the AWS "Support Service Role" getting read permissions to everyone's S3 buckets.
"These configuration errors by the cloud provider expose customer data even if the customer is doing everything right. Selecting the right cloud asset attack surface management tools is the key to quickly and easily spot these issues," Yu says.
Storm Swendsboe, director of threat intelligence at SafeGuard Cyber, tells ISMG the three simple conditions that website and application owners can check for in order to determine whether they have been affected by the NotLegit flaw. If the answer to all of the questions is "yes," the user has been affected:
- Are you using Microsoft Azure?
- Are you using the Local Git source code deployment method, which hosts the source code locally for the Azure service?
- Is the source code written in the Ruby, PHP, Python or Node programming language?
If the source code is written in C# or ASP.NET, then you are not affected, Swendsboe says.
A Significant Flaw
Although Microsoft has said, and Wiz confirms, that the vulnerability has been fixed, "This is significant for security practitioners," says Randy Pargman, a former FBI Cyber Task Force personnel and now the vice president of threat hunting and counterintelligence for Binary Defense.
Pargman says attackers can use the source code to exploit the service or find hidden vulnerabilities in the website. "No secrets or API keys should be stored in the code, but instead should be referenced from environment variables or secure key stores," he says. While many website developers embed API keys and secrets in the source code because it's faster and easier, if an attacker gets those keys, "they can do anything that the API allows," Pargman tells ISMG.
Oliver Tavakoli, CTO at Vectra AI, says the impact of this vulnerability is highly variable but the fact that the researchers saw it exploited in the wild is concerning as it shows that the vulnerability was not a well-kept secret.
"From an espionage angle [corporate or national], this could be used to gain intelligence about sensitive information hosted on these servers or to completely steal IP from developers. And from a cybercrime angle, this could be used to gain access to systems or accounts that an actor could exploit or ransom," Swendsboe says. "Within a week or so, we will probably see some attempt to exploit this."
Otavio Freire, co-founder and CTO of SafeGuard Cyber, agrees and cites the example of how Conti integrated the Log4j 2 vulnerability into its attack methods after thte vulnerability was disclosed (see: Apache Log4j: New Attack Vectors, Ransomware Seen).
"While Microsoft notified affected users of the Azure service earlier this month, there will still likely be some lag due to the holiday season. This, compounded with the fact that remediation for this exposure issue requires a manual action from the user beyond a simple update, means that there are likely still a fair number of exposed [.]git files out in the wild," Freire tell ISMG.