Source code exposed to Azure App Service vulnerabilities for 4 years
Third Party Risk Management, Application Security, Cloud Security
The “NotLegit” flaw affects all applications based on PHP, Node, Ruby and Python using Git local
Mihir Bagwe •
December 27, 2021
Microsoft’s Azure App Service had a security vulnerability, which researchers refer to as “NotLegit,” which kept your local Git repository in the publicly accessible service, according to a security blog from Wiz.io. The flaw means that the source code of client applications written in Java, Node, PHP, Python and Ruby has been exposed for four years – since its deployment in September 2017.
See also: How to improve your defenses with Security Analytics
Based on the results of the honeypot defined by the researchers, they also believe that the security hole has been actively exploited in the wild by malicious actors.
Microsoft recently patched the flaw and issued alerts to a “limited subset” of customers via email communication between December 7 and December 15. Alerts ask affected users to take certain actions to protect their applications.
“We have informed the limited subset of customers that we believe to be at risk because of this and we will continue to work with our customers to secure their applications,” the Microsoft Security Response Center said in a blog post.
The “non-legitimate” vulnerability
Azure App Service is a cloud-based platform for hosting web applications and websites. There are several ways to deploy source code and artifacts to the Azure App service, and one of them is Local Git, according to the researchers. Once users launch a local Git repository in the Azure App Service container, it allows them to push their code to the server, according to Wiz.
Researchers say that when deploying git repositories to web servers and storage compartments, care should be taken to ensure that the .git folder is not downloaded as it contains information such as source code, e- addresses. developer mail and other sensitive data. But Microsoft has deployed the git repository for Azure App Service in the publicly accessible directory / home / site / wwwroot. “This was a known oddity to Microsoft and to protect your files it added a ‘web.config’ file to the .git folder in the public directory which restricted public access,” the researchers said.
But the oddity created a problem nonetheless. “Only Microsoft’s IIS web server manages the web[.]config… if you are using C # or ASP.NET, the application is deployed with IIS and this mitigation is perfectly fine, ”say the researchers. But if a user is using the programming language PHP, Ruby, Python or Node, the application is deployed to different web servers, such as Apache, Nginx, Flask, etc., which do not support the web.[.]config and the vulnerability can be exploited, they say.
By analyzing the code, the researchers also found that Microsoft’s website[.]config contained a typo – config tag was not closed properly. This error turned out to be a godsend, researchers said, as it ended up blocking access to the entire directory.
“It’s worrying, but perhaps not too surprising, that we are seeing configuration errors from the cloud service provider,” Sounil Yu, CISO at JupiterOne, told Information Security Media Group. “We all make mistakes, and Microsoft, Google, and Amazon aren’t foolproof,” he says, citing the recent example of the AWS “Support Service Role” getting read permissions to everyone’s S3 buckets. .
“These cloud provider configuration errors expose customer data even though the customer is doing everything right. Selecting the right cloud asset attack surface management tools is the key to quickly and easily detecting these issues, ”says Yu.
Storm Swendsboe, Threat Intelligence Director at SafeGuard Cyber, explains to the ISMG the three simple conditions that website and application owners can check to determine if they have been affected by the NotLegit vulnerability. If the answer to all questions is “yes”, the user has been assigned:
- 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 Ruby, PHP, Python, or Node programming language?
If the source code is written in C # or ASP.NET, then you are not affected, says Swendsboe.
A major flaw
Although Microsoft has said, and Wiz confirms it, that the vulnerability has been fixed, “This is important to security practitioners,” says Randy Pargman, former member of the FBI Cyber Task Force and now vice president of the 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 code, but should instead be referenced from environment variables or secure keystores,” he says. While many website developers embed API keys and secrets in the source code because it is faster and easier, if an attacker obtains these keys, “he can do whatever the API allows. “Pargman told ISMG.
Oliver Tavakoli, CTO at Vectra AI, says the impact of this vulnerability varies widely, but the fact that researchers have seen it exploited in the wild is concerning as it shows that the vulnerability was no secret. well kept.
“From the point of view of espionage [corporate or national], this could be used to get information about sensitive information hosted on these servers or to completely steal the developers’ IP. And from a cybercrime perspective, that could be used to gain access to systems or accounts that an actor could exploit or demand a ransom, ”Swendsboe said. “In about a week or so, we’ll probably see attempts to exploit this.
Otavio Freire, co-founder and CTO of SafeGuard Cyber, agrees and cites the example of how Conti incorporated the Log4j 2 vulnerability into its attack methods after the vulnerability was disclosed (see: Apache Log4j: new attack vectors, ransomware detected).
“Although Microsoft informed affected users of the Azure service earlier this month, there will likely still be some lag due to the holiday season. This, compounded by the fact that fixing this exposure issue requires manual action on the part of the user beyond a simple update, means that there are probably still quite a few exhibitions [.]git in the wild, ”Freire told ISMG.