Your private Git repository might have been exposed by Azure App Service
3 minute read
The .git folder inside a Git repository is the most important folder as it has the entire Git commit history. In fact everything else is your current working area and .git is the true repository folder.
If someone gets access to this folder, you can easily imagine the damage to your intellectual property (provided it’s a private Git repository).
What’s more damaging is the likelihood of leaking the secrets, such as API keys and/or admin passwords related to your own apps and integrated third-party services (email senders, payment gateways and so on), which you might have put directly in the source code during the course of development. Repository being private, you didn’t consider it important to worry about the best security practices for source code repositories.
This is exactly what has happened.
Wiz researchers recently discovered this vulnerability in Git based deployments on Azure App Service.
It doesn’t impact IIS-based apps because Microsoft was aware about the flow and had added a web.config file into the .git folder in your deployment, which forbids access to the directory. However, web.config is only processed by IIS.
So, if you’ve been deploying on an App Service instance which uses a web server other than IIS – such as Apache, Nginx, Flask, etc. – which is likely true for many PHP, Ruby, Python and Node based web applications, you were likely exposed to this vulnerability.
Mitigation steps
- Make sure your public content folder on the server doesn’t contain
.gitfolder. - If it’s not possible to remove the
.gitfolder due to the deployment method you use, make sure you deny access to it via your web server’s access control lists (ACLs). - Reset all the credentials (API keys, admin passwords, connection strings) that were ever mentioned in the repository’s source code as the hacker would already be possessing them from the Git history.
Zero Trust security best practices for source code repositories
As mentioned in the ‘Ensure security of the application environment’ section of the Zero Trust whitepaper:
Keep sensitive production environment settings (API Keys/passwords/connection strings) in encrypted form or at least not accessible to everyone having access to the code.
Following the Zero Trust approach from the very beginning of SDLC is crucial. Because as the complexity of the application grows, the chances of leaking sensitive data grow proportionally. Your logs, source code, build environments, databases should all be operated with a mindset that if anyone of these is compromised, how can you limit the damage. If your development team is lacking in Zero Trust Thinking, security becomes only another item in the checklist; marking it done will only give a false sense of security.
Build Zero Trust thinking for software development
Because Zero Trust is not just an approach; it’s a mindset.
You can also develop this mindset by going through the hands-on tutorials from the Zero Trust Thinking (ZTT) series. ZTT is brought to you by ASPSecurityKit, the first true security framework for ASP.NET and ServiceStack built from scratch on the Zero Trust model.
Leave your email below to receive a notification of new ZTT articles and videos right in your inbox, once every two weeks or so.
Need help?
Looking for an expert team to build a reliable and secure software product? Or, seeking expert security guidance, security review of your source code or penetration testing of your application, or part-time/full-time assistance in implementation of the complete web application and/or its security subsystem?
Just send an email to [email protected] with the details or call us on +918886333058.