Securing Bitbucket Server: best practices in the face of the Ukraine cyber warfare
A global cybersecurity crisis has been brewing for years, but with the recent war in Ukraine, hacking has become highly weaponized. Companies publicly supporting Ukraine have been experiencing state-sponsored retaliation attacks. So we figured it’s a good time to review some basic best practices for Bitbucket Server — the most effective security practices are often the simplest.
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.”
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.
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:
- Open the bitbucket.properties file in the home directory of your Bitbucket instance.
- Locate the feature.public.access property, and set it to “false”.
- Restart Bitbucket
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.”