I'm testing some servers with OpenVAS and I run into some SCM files that are remotely accessible:
.git/config
.git//info/exclude
.git/description
.git/HEAD that contains refs/heads/master
and
.git/refs/heads/master that contains a hash
I'm new to git and my experience with it is pretty basic. My question is what can an attacker do with the information inside these files and the hash I've found inside .git/refs/heads/master?
For my answer I presume that this is the git repository of the application that the server is running, that it contains the full git repository, and that you are able to download the whole thing. This is both surprisingly common and surprisingly dangerous. The git repo contains not just all the code actively deployed on the server, but also every line of code ever written (deployed or not) for the application. There are a few things to do with that:
A common refrain is that you shouldn't store passwords/keys/credentials in git. This incident is one big reason why. When attackers find them it can end very badly.. Finding the git repo publicly available on the website means that it is time to go treasure hunting. Every key you can find is basically a treasure map, and you never know what you'll find! There are even tools out there that try to automatically find credentials in git repos for you.
As an example, the best case (for you) scenario is if the database password and host are stored in code. If the database accepts remote connections and isn't properly firewalled, you may end up easily upgrading yourself to full database access too.
Whitebox testing can be much more effective than blackbox testing because you have more information to aid in your search. With full access to the source code, you're basically now a whitebox tester for this site. You can spend a few hours getting to know the way their application is put together and organized (which is obviously easier if you happen to be familiar with their technology). From there you have substantially more information available for bug finding. Of course you don't have infinite amounts of time for reading their code, so I'd start simple. I would Check their routing tables for very juicy looking endpoints (admin/users, admin/orders, admin/reset_user_password), and check those endpoints for holes in access control that you can exploit. Similarly, I'd pick some "high impact" pages that I already know about and dive through their source code, looking for any vulnerabilities that might be hard to find while trying to blindly exploit things from the outside.
This one is a bit much for your typical bug bounty scenario, but I thought I'd mention it anyway. git records not just all code every written, but who wrote it. It requires both a name and email address to be attached to every commit (although it doesn't check that an actual email address was provided). This means that you have also gained access to a list of the names and email addresses of everyone who has ever done any programming for this system. This could lead to many opportunities for more informed social engineering attacks, which increases the odds of success.
Finding someones git repo is definitely bad and a reportable bug in-and-of itself. This can also lead to the discovery of even bigger vulnerabilities. However, like anything else in penetration testing, doing so can still take some effort and isn't guaranteed results. If they don't keep keys in their repo, if they have good application security overall, then their git repo may not practically benefit you in the slightest. Of course, allowing the repo to be publicly accessible is a big security blunder in the first place, so I'd be surprised if there aren't more mistakes waiting to be found.
Also, to answer your last question: the hash you found won't help with penetration testing. git uses hashes as ids for both files and commits. That is just the hash (aka the id) of the commit which is the HEAD of the active branch. In other words, that hash just tells git which code is currently "active", since git keeps around the full code history. It is built from data that is otherwise easily accessible in the git repo in plain-text format.
