A few days ago, I gained admin access to the ERP system of a German-based international online retailer1 operating a number of e-commerce websites. The ERP system included sensitive employee data, customer data, and over 160k invoices. They quickly addressed the issues and the overall communication went very well.
When I noticed that https://███████24.de/.git/config returned an actual git config file, I started investigating further. The file content itself only revealed the repository URL, which wasn’t publicly accessible. But the mere fact that the file was accessible gave away that the .git directory was not properly secured on the web server.
The .git directory exists in every git repository and contains all its information, including branches, commit history, etc. With access to the files within this directory, all that information can be downloaded piece by piece, for example using tools like gitjacker. Directory listing on the web server is not required for this to work.
After restoring the downloaded git repository to a somewhat usable state, I had access to most of the repositories files and history and started looking around. The first thing I noticed were temporary files and backup files that shouldn’t have existed inside the webroot anyway, but were additionally added to the repository – perhaps by an incautious git add .
I moved on loooking through files and found some .json configuration files in the repository that contained credentials:
{
"...": {
"url": "http://█████████████████████████████",
"username": "admin",
"password": "123secret███",
"database": "█████████████████████",
// ...
}
}
Even worse, the files being .json files, their content was – unlike .php files – publicly accessible from the web server, without even requiring any access to the git repository.
The URL led to the company’s web based ERP system where I could simply log in with a web browser using the credentials from the JSON files.
This gave me access to a lot of data and functionality, most of which was PII or company secrets. Some of these were:
- Email messaging
- Employee’s calendars, including private data such as medical appointments, birthday parties, etc.
- Employee’s paid and unpaid leave requests, leave reason and approval status
- Internal issue tracker
- Warehouse / Inventory details
- Cost price and public price of products
- Over 160k customer invoices
As I was logged in as admin, it was also possible to create, modify or delete any or all of this information. (I did not try this)
Due to the large amount of customer data being at risk, I notified the retailer that same night. They replied the next day, were thankful and addressed the security issues in a quick and responsible manner, which I find quite noteworthy. Thanks!
Discussion
Accidentally exposed .git directories are very common, but they remain an oversight like any other. It is hard to prevent all oversights from happening. However, storing credentials in (supposedly private) source code is much more negligent and can be easily avoided. In this case, it led to a much worse outcome of a comparatively harmless issue. Website operators should be careful not to include files in the webroot that shouldn’t be publicly accessible, or ensure the web server is properly configured to deny access to them.
To prevent credentials in your source code, you can replace sensitive data with environment variables, or you can place configuration files outside your repository and webroot.
Disclosure timeline
| I gained access to the ERP system. | |
| I notified the retailer about the issues. | |
| The retailer replied that they have started fixing and intend to complete fixes by end of the day. | |
| The retailer notified me that fixes have been completed and decided to notify the data protection authority about the issues the same day. | |
| I confirmed the most critical issues have been fixed (.git no longer accessible, ERP password changed), pointed out some remaining smaller issues and gave additional advice. I also asked if a bug bounty is possible. | |
| The retailed replied that the remaining issues have been addressed and told me they will offer a bug bounty. | |
| Some emails about handling the bug bounty and publication followed. | |
| Publication of this article. |
I received a bug bounty of 500 €, half of which was donated to my local hacker space.
-
I intended to identify the retailer as to give them some kudos for their commendable reaction. However, the retailer was concerned this might actually drive away some unsavvy customers and do harm to their business, which I can empathize with and therefore decided not to identify them. ↩