Hello dear visitor,
the reason you are visiting this site is you probably received my security notice. Just for clarification, I didn’t hack your site. I’m a security researcher/white hat/ethical hacker and I only detected a security problem on your website. No sensitive data was downloaded from your site except for your e-mail address which will be forgotten after the research. I won’t store it or use it for any other purposes.
- 230 000 000 sites scanned 🔍
- 390 000 sites affected 😥
- 100 000 mail send to the developers 📧
- 150 000+ sites fixed 👍
- 8 affected sites with security.txt 🎱
- 100 abuses received during scan 📄
- 40 false positive notification ❌
- 3 spammer/scammer accusations 🖕
- 1 threat to call the Canadian police 👮
- 1 complaint to the Czech Office for Personal Data Protection 👩⚖️
- 100+ possitive comments 🗨️
- 3500+ thankyou mails ❤️
- Thousands and thousands sites with another serious issue found 😑
As I have said, I’m a security researcher and computer security is my hobby. I found your site while scanning the Internet for some particular vulnerabilities. So you are just one from many I notified – nothing personal here. I started with the scan of the Czech Internet and when I realized how big the problem is, I decided to repeat it on a global scale. These scans are non-commercial activities, but you can make a small donation for the future scans if you consider them helpful.
Details of the Vulnerability
The problem is you have a publicly available git repository on your website. You can check it by visiting /.git/HEAD. When you visit the directory /.git you usually get 403 error because there is no index.html/.php file and you don’t allow to show the directory listing/autoindex (if you can see the directory structure you have a misconfigured webserver – it is another type of vulnerability). Despite 403 it is possible to access the files directly. This is the way I found your e-mail address – from the /.git/logs/HEAD – it is the list of commits with details about commiteers. The structure of git repository is well known, so it is possible to found references to the objects/packs in the repository, download them via direct requests and reconstruct the repository and obtain your files – not only the current ones, but also the past files. There are tools which enable to automate the download.
It is a bad idea to store DB credentials and various API tokens in the repository, but many developers don’t follow the best practices and the vulnerability is really serious in this case.
It is not always possible to download the complete repo, but there are many other interesting information still, e.g. /.git/index – it is a binary file and it reveals the structure of your application, libs used, endpoints, inernal files etc. Sometimes you can find the address of unsecured WYSIWYG editors with the file uploader – unfortunatelly it is really common. You can see readable paths strings in the index file or you can use GIN to extract them to human readable format.
It is a good practice to disallow the access to all files and folders with dot at the beginning, except for .well-known folder (it is used for certificates verification and for security.txt file).
For Apache and Nginx you can use the following rules:
Even better way to mitigate this problem is to change your deployment workflow and don’t have .git in the same folder with your public files, of course. If you don’t use the repository anymore, you can safely delete it. Some deployment workflow tips:
There were around 150 000 sites fixed after 2 months.
This site was modified for purposes of my recent scan – you can find other posts here.