Exposed Gits: 10 Years on

Nearly 10 years ago my colleague wrote a cracking post on exposed Git repositories. 10 years is a long time in cyber security, but you’d be surprised how many things you thought should have gone extinct that haven’t.

A prime example is a recent finding of a handful of exposed .git repositories. As a refresher, Git is a richly featured code repository tool. It tracks versioning so allows for collaboration and helps ensure consistency across the codebase.

This hints at why finding an accessible one on an internet facing server is not good. There may be some hidden gems in the repository, such as passwords, API keys, private SSH keys and so on.

This redacted screenshot shows some of the useful information extracted from the exposed Git:

Did (g)it all go away?

Well, no, otherwise I wouldn’t be writing this blog post. We recently stumbled upon a number of open .git repositories linked to something we use in house (no, I’m not telling you what that is).

A number of other websites use some code libraries served from the affected hosts, but they aren’t services we use. We found four in total, one of which was their corporate site.

Whilst the service we use wasn’t directly exposed, it used code from a Git repository on an exposed host. Depending on what was exposed and what could potentially be accessed, it could be possible to modify the library used by the website. Proving it would have meant breaking the Computer Misuse Act (CMA) so obviously we didn’t do that. Modifying the library could have led to all sorts of issues such as credential theft, data modification, and so on. Not ideal.

Disclosure timeline

The following lists the timeline from initial discovery to most of the sites being fixed:

• 25/04/2023: Initial discovery of exposed .git on the website. Search begins for a security contact to inform them of the issue. It was discovered that they aren’t using a security.txt. There’s more information on security.txt here. Also our @TheKenMunroShow  is a bit of a bloodhound when it comes to sniffing out the right people to talk to.
• 17/05/2023: Email sent to a contact address at the main website.
• 22/05/2023: Email received to say the issue has been resolved. Except it hasn’t been completely fixed, they still have an exposed git on their main site…

It should be noted that we didn’t look at all of the subdomains that they had, but it did seem that they cloned a standard repository and then used it for the subdomains with the necessary changes made for each one.

Unfortunately, it took a fairly long time for them to respond. We didn’t do a deep dive into what was in the repositories but there were some config files. Leaving something like that exposed for a long time could potentially lead to a compromise that may not be discovered. That could mean reputational and financial damage.

Conclusion

External infrastructure security management isn’t a fully solved problem, but it is almost there. The solutions are usually easier to implement and more generic than custom services like APIs and web applications.

However, there’s always something new that comes along and throws a spanner in the works (or drops a service onto the Internet). Anything useful like Git repositories that allow collaboration will be seen as a boon and not a security issue by those who need to collaborate. We, being the paranoid security professionals that we are, see things differently.

If you need something sensitive to be accessed:

• Put it behind a VPN
• Use access control lists (ACL) to limit who can get access
• Use multi-factor authentication

No single security measure is perfect, but a defence-in-depth approach will help deter all but the most determined and well-resourced attackers.