Tips for securing Bitbucket Server

[#1]

(A few sensible practices compiled by the Soteri team, creators of Security for Bitbucket. Enjoy!)

Veteran hacker Kevin Mitnick said, “Companies spend millions of dollars on firewalls, encryption and secure access devices, and it’s money wasted.” The reason?  “None of these measures address the weakest link in the security chain.”

Let’s see how just a few smart decisions can shut the gates on legions of both casual and weapons-grade hackers looking for an easy way in.

Scanning for third-party vulnerabilities

Getting to market quickly with a competitive software application nearly always means leveraging third-party code. Open source code from multiple sources is routinely used as building blocks, and a vulnerability in any single component puts the whole application at risk.

Dependency scanning evaluates all software components in your development stack, and flags risks before they become problems.

A recognized leader in this space is Snyk. Their solution can flag vulnerabilities in code and other build assets, including those in containers. OWASP Dependency check is a free open-source alternative, although with less convenient integrations than Snyk.

Scanning for committed credentials

Bitbucket has a long memory, much longer than all your developers combined, and while they might forget the occasional test password or API access key they left in a source file, Bitbucket will not. A carelessly-committed password, SSH key, or an API key can be a boon to attackers who have breached the perimeter and are looking to escalate access to other highly secured systems.

Credentials scanning solutions comb through git repositories and flag anything sensitive that was committed in error.

Tools that specifically integrate with Bitbucket, such as Security for Bitbucket, streamline this process: scans can be performed, reviewed, and dispositioned without scripting or setting up an external service. Security for Bitbucket also integrates with Bitbucket’s hook architecture to block any dangerous incoming commits. Without such integration, committed secrets can only be caught after the fact, and must be considered compromised and rotated out.

We know we can’t put passwords and API keys in code, so where to they go? Vault by HashiCorp is a great option for storing secrets at scale, while still maintaining programmatic access to them.

SSO and permissions management

In Bitbucket, managing role-based and project-specific access can be tricky.

Developers will notify you when you don’t configure access to every repo they need, but Bitbucket won’t say a thing when you delete or modify a user’s access and unknowingly leave dangerous settings behind.

It’s not unusual for a few scattered remnants of a user's permissions to persist even after they’re removed from sensitive projects, or transferred to another role. When those records are reallocated, that can risk inadvertently elevating another user’s access.

To mitigate the risk, synchronize your Bitbucket logins with SSO to minimize the the surface area for access misconfiguration. Also, make a habit of granting permissions based on group membership rather than individual accounts; that makes it easier to manage and, when appropriate, roll back permissions.

As a step further, you could programmatically audit repository and project permissions using the Bitbucket REST API for projects and repositories to verify permissions granted to key assets.

Sensible authentication practices

For all the sophistication of security tools, nothing beats the simplicity of following basic best practices.

2-factor authentication is widely adopted, not least because it foils account takeovers by layering security. Ensure Bitbucket implements 2FA either through SSO integration or via one of the apps available on the Atlassian Marketplace.

Alongside 2FA, make it effortless for your users to use strong passwords with a low-friction company password manager like 1Password. Without a password manager, users can’t be expected to use truly strong unique passwords – not without recording them somewhere insecure.

Disabling public repositories

The need for collaboration, pair programming, and drop-in consulting all drive the desire to create a low friction experience for developers, making it all too tempting to just open access to shared repos.

If public repositories are enabled, any user can fork a sensitive repository and then make the fork public (since users have administrative privileges over their own forks).

But public repos are, obviously, wide open – they’re vulnerable even to intruders who haven’t breached Bitbucket security or user credentials.

In Bitbucket, the simple fix is to disable public repos.

To disable public access globally for all repos:

1. Open the bitbucket.properties file in the home directory of your Bitbucket instance. 
2. Locate the feature.public.access property, and set it to “false”.
3. Restart Bitbucket

Conclusion

None of the solutions to the risks presented here are either complicated or expensive, and certainly not compared to the potential alternative. 

The ROI of addressing vulnerabilities is high, and as Richard Clarke put it, “If you spend more on coffee than on IT security, you will be hacked. What’s more, you deserve to be hacked.”

Stay safe.

[Mohammed Davoodi _Soteri_]

Nice work George!