This month, Mercedes Benz left 580 source code repositories open and available for anyone to access on the Web. These repositories not only contained valuable source code for vehicle components which could be used for attack, they also contained passwords and tokens that unlocked access to other Mercedes private servers.
Was this a product of a sophisticated hacking cartel who targeted Mercedes Benz? Hardly. It was simply a misconfiguration of GitLab that allowed anyone to create an account and download the code.
This breach goes to show that code is a valuable target for hacking, and that common misconfigurations in Git are to blame for many security breaches.
As the Mercedes example shows us, code is not only IP that needs protection—it’s also mined every day for secrets, tokens, passwords, and other credentials. As important information increasingly finds its way into source code in the form of Terraform scripts, ML models, and even security policies themselves, code becomes an even greater threat vector.
Here are three common misconfigurations in Git that can lead to security breaches:
Leaving a .git folder in a publicly accessible computer/server.
Because Git users pull code (clones) to their native machines, the code proliferates. Companies today have little to no idea who has actually cloned their code on what machines. It’s then very easy for a backup file to find its way into an unprotected server or for the web developer to mis-configure the webserver and leave it open and available in the website directory.
Recently, the official GDPR advice site left their .git folder on a web server. Hackers proactively scan the web looking for this type of folder. In the GDPR case, a hacker found a MYSQL password that could have been used to potentially access and modify the site itself without notice.
According to Threat Post, “Open .git directories are a common problem – a scan of more than 230 million web domains worldwide in 2018, in fact, uncovered 390,000 web pages that were vulnerable due to the issue.”
Code is inadvertently marked public.
This misconfiguration is very common, which makes sense when you take into account GitHub’s history in open source, where the default is always public and the access is very permissive. Companies who use GitHub for closed source need to be vigilant to ensure these defaults are not applied to proprietary source code.
An example with far reaching implications comes from Samsung where the company left dozens of critical code repositories on GitLab marked as public. According to the security researcher quoted in the article, one repository contained credentials that allowed access to an entire AWS account that held several employees’ private GitLab tokens stored in plaintext.
Companies need a way to audit and view code settings and developer actions in concert, so they can be alerted on these vulnerabilities. By helping companies find who has cloned their important code or even who may have publicly posted it, we make sure the risks from this type of vulnerability are lowered. BluBracket CodeInsights helps you find passwords and tokens, and also generates alerts when critical code is made public.
Unauthorized webhooks or application access to all code repositories.
Developers frequently use applications or services to provide data, complete a function or provide a service that enhances their own work. This saves time and increases productivity, but it can also expose companies to both IP theft and hacker attacks into critical systems via credential leaks.
When a developer gives an application access to the code, it generally gives access to all repositories she has access to. Token authorization is mapped to the user, not the repo. And currently there is no easy way for managers or security personnel to audit and view the applications or webhooks used in code. Once the app has access, it can be a trojan horse into the code, and thus into other infrastructure or applications.
Most companies have lists of authorized applications and webhooks, as well as configuration settings that are required to keep things safe, but having a security policy in a document is much different than deploying a system (like ours) that actually enforces and alerts on these policies. As coding becomes ever more componetized, understanding the linkage and permissions for these types of applications and webhooks is crucial for true security.
How to Git it right.
The truth is while Git-based systems like GitHub, Gitlab and Bitbucket are fantastic for developer collaboration, speed and productivity, they just aren’t instrumented for security. They’re platforms that rely on other companies to augment critical functionality.
By adding a security tool like BluBracket, companies gain the advantages of Git-based development, while mitigating the security risks and helping developers shift security left. If you’re interested in learning more about our vision for security at the speed of code, please contact us to learn more or download our Top 5 Security Risks from Code white paper to dive deeper.