Imagine you just learned from a vulnerability report that your application's source code has been kept public since its deployment. There's more: Imagine it's been like this for a couple of years now and anyone anywhere could download files that are not intended to be public, such as authentication information. Is your heart racing now?
Problems like that arise when teams leave exposed
About a year ago,
an ethical hacking and security research team gained access
to over 100,000 private records of United Nations Environment Programme (UNEP)
The contents that were publicly accessible included files
exposing the administrator's database credentials,
which granted access to UNEP's source code,
as well as databases exposing project funding source records,
UN staff demographic data
and travel history.
Plenty of other information was there for the prying eyes.
It was suggested back then that "threat actors likely already have the data."
In this post,
we will talk about a recently discovered four-year-old vulnerability
that also involved compromised
The NotLegit vulnerability
On September 12 last year, researchers at cloud security firm Wiz found a security issue at Microsoft Azure App Service. The latter is a cloud computing-based platform for creating and deploying web and mobile applications for any device. One very worrying thing is that, according to the researchers, the vulnerability has existed since September 2017. Just like with the security issue that enabled access to UNEP's databases, the researchers say Azure's misconfiguration has probably been exploited in the wild for a while.
Users can deploy source code and artifacts to Azure in multiple ways.
they may pull their source code from a Git-based repository hosting service
(e.g., GitHub, Bitbucket).
An alternative is using "Local Git."
This method lets users create a local Git repository
within the Azure App Service container
that lets them push their code to the server.
anyone can access the application on the internet
The recently discovered security problem affected
applications deployed using Local Git.
those written in PHP, Node, Python, Java or Ruby,
which are not served
in Microsoft's very own Internet Information Services (IIS) server.
by the researchers,
the Local Git method created the Git repository
within a publicly accessible directory,
which researchers named NotLegit (don't ask us why!),
left hundreds of source code repositories exposed for anyone to see.
Time for the long-overdue fixes
Microsoft was aware of Local Git's behavior
and had mitigated the risk of unauthorized access
by adding a
web.config file that placed restrictions.
This file can only be handled by the ISS server, though.
applications written in C# or ASP.NET were protected
because they are deployed with this server.
applications written in other languages are deployed with other servers
like Nginx or Apache.
These servers do not support
As there were no restrictions in place,
anyone could access the source code and other sensitive information.
The researchers at Wiz reported the issue to Microsoft on October 7.
The Microsoft Security Response Center (MSRC) explained
in a very recent post what caused the vulnerability.
What happened is the applications served the
.git folder as static content
that goes into the public content root folder.
Static content is
all the data that doesn't have to be generated for each and every request
and thus is served the same to every end-user.
Microsoft fixed the problem for PHP applications on November 17.
The fix disallows serving the
.git folder as static content.
Fixes for applications written in Node, Python, Java or Ruby
require manual work from customers, though.
It's the application code that controls the serving of static content.
customers themselves need to look at the code
and make sure the
.git folder is not served within the public folder.
On December 7, Microsoft started sending emails notifying all vulnerable customers and advising them to take specific actions to protect their applications. It turns out, customers using Local Git from the start were not the only ones affected. Customers whose applications were deployed using other methods but had got files created or modified in the Azure App Service container were also impacted.
Do you know where your source code sits now?
As we hinted at the start of this post,
teams may mistakenly publish the
.git folder to the internet.
NotLegit was not enabled by admin error.
it was the cloud service provider
that mistakenly exposed the customers'
It's been said
experts are urging users to check if their source code has been leaked.
This should not be regarded as a serious matter by Azure's customers only.
All teams should know if they are exposing things they want to keep private,
so they need to ensure security is an integral part
We have stated elsewhere, however, that a hidden source code isn't necessarily a secure one. Indeed, the bigger issue isn't exactly that anyone can review your code, but rather that if your exposed code has any vulnerability, you're just moments away from being attacked.
At Fluid Attacks,
we perform comprehensive testing
in search of vulnerabilities during the entire software development lifecycle.
By using our services,
you can find out,
among many other things,
whether you are inadvertently exposing your
.git folder and,
in doing so,
possibly compromising sensitive data.
But most importantly,
you can find out just how secure your code is
at each point in development.
if it's actually supposed to be out there,
you'll know it's fine.
Take this step now and
If you're still on the fence,
read about our
secure code review solution.
Recommended blog posts
You might be interested in the following related posts.
An OffSec Exploitation Expert review
Towards an approach that engages more than SCA and SBOM
An interview with members of our hacking team
A brief overview of this recent EU draft regulation
What is invisible to some hackers is visible to others
Increase the board's cyber savvy with these reads
Soon it will be a must in cybersecurity due to NIS2
Toyota's ancient and recently disclosed data leaks