Lessons Learned About Secrets Protection After the Sisense Breach

Sisense is a popular monitoring tool that enables users to monitor business metrics from multiple third-party sources in a single dashboard. On April 10, the company informed customers that the sensitive information they entrusted with Sisense may have been compromised and urged them to reset their password and rotate their secrets.

According to KrebsOnSecurity, the attackers were allegedly able to access GitLab repositories hosted by Sisense, where hard-coded secrets may have been found. Those secrets were the keys to access sensitive customer data in AWS S3 buckets said to have contained access tokens, email passwords and SSL certificates.

This scenario, if it turns out to be accurate, is yet another example of malicious actors exploiting a chain of security issues — from accessing the GitLab repositories to the customer data through hard-coded tokens. If the method used to access the repositories is not public, and may have been sophisticated (therefore being hard to stop), hard-coded tokens are rather easy to discover with the proper tools and processes in place.

The Root of the Breach: Hard-Coded Secrets

Secrets contain the information that hackers need, like passwords, API keys and encryption keys,to gain access to sensitive data like credit card numbers, social security information and health care records. This is why they are supposed to be stored in a secure vault and only retrieved ad hoc at runtime. They should never be stored in plain text in the source code, which can be found by anyone with access to the repository, or passed as environment variables.

In the recent Sisense breach, the current speculation is that hackers somehow gained access to Sisense’s self-hosted GitLab repositories and found secrets hardcoded in some repositories that gave them access to a bucket containing customer data. That said, hard-coded secrets can also be discovered in multiple places, including in databases, log files and more.

These secrets would enable the hackers to access AWS S3 buckets storing sensitive customer information, which were meant to be monitored by customers using Sisense dashboards and nobody else.

So, what can you do to prevent this kind of attack?

How to Prevent Hackers from Accessing Your Secrets

There are plenty of best practices for secret management to prevent them from falling into the wrong hands.

At the most basic level, developers should either leverage secret management systems provided by commercial vendors or the ones hosted directly by cloud providers. Secrets should then be pulled ad hoc by the service that needs them rather than passed as environment variables, which could be compromised. Also, only services that need to retrieve those values need access to them (least privilege access), in order to reduce the blast radius of a potential breach.

Most developers know this. Hard-coded secrets fall through the cracks for the same reasons most product vulnerabilities make their way to production — developers are crunched for time and constantly pressured to deliver new features faster, which can lead to errors like adding hard-coded secrets to repositories.

Mistakes happen to every software development team in the world, so how can we prevent them from introducing real business risks?

Great open source tools like Gitleaks and TruffleHog can automatically scan your code for hard-coded secrets. Thus, you can scan your repos and catch secrets before your code is merged into production. Even better, if you integrate them in your IDE and couple them with some pre-commit hook, you can ensure that those sensitive values won’t be committed at all.

By continuously maintaining a dictionary of regular expressions of specific patterns and strings in common source code, these tools let developers know if a secret is exposed before pushing code to production. For example, if these tools see a 16-character string in your code that starts with AKIA or ASIA, they will use one of their many detectors to determine that you have an AWS secret exposed.

Using Gitleaks, you can scan your existing repos using the detect command to find hard-coded secrets:

gitleaksdetect --source <path to local cloned repo> --report-path=report.json

gitleaksprotect --source <path to local cloned repo>

This will create a file called .pre-commit-config.yaml in the in the repository’s root directory. This file must be placed in the root directory for the hook to be active.

While these tools are a great start for catching vulnerabilities before production, they’re focused solely on hard-coded secrets, which are just a fraction of the potential product vulnerabilities that could ultimately expose sensitive data to malicious actors.

There are many other security controls that find other types of vulnerabilities, including static application security testing (SAST) for code issues like injections, software composition analysis (SCA) for open source vulnerabilities, Infrastructure as Code (IaC) scanning for cloud infrastructure vulnerabilities and many more.

Implementing all of these tools into your CI/CD pipeline can be time-consuming. They also have separate data formats and UXes, which can make them difficult for developers to adopt. Developers would rather be working on their next pull request (PR) than bouncing across UIs to prioritize and solve security issues.

In the example below, you’ll see an example of surfacing a hard-coded secret within a PR, so it can be swiftly resolved before production.



This makes it easy for developers to catch hard-coded secrets early on.

Takeaways from the Recent Breach at Sisense

The pressure to deliver new features quickly is unrelenting, which will inevitably result in coding errors that could expose sensitive information to attackers. While it’s easy to point blame in hindsight, coding errors are inevitable — some will be exploited, and most never will.

To eliminate the business impact of such errors, companies can take steps to empower their developers to deliver more secure code without compromising on speed. Below are some takeaways to harden applications in production against these kinds of attacks:

• Tools like Gitleaks and TruffleHog offer easy and effective ways to scan code for hard-coded secrets, which reminds developers to store the secrets in secret management systems
• To unify secrets detection alongside other product security scanners that surface other kinds of vulnerabilities, consider platforms like Jit that provide a one-stop-shop that can be easily adopted by developers.
• Consider automation to help developers secure their code before production without slowing them down. By integrating product security scanning with PR creation or pre-commit hooks, developers can detect and resolve vulnerabilities before they become business risks.

Beyond having an efficient prevention method, you need to think about what will happen when security incidents occur — the question not being if, but when — in order to reduce the blast radius and quickly plug the hole that was exploited. Therefore, having a proper incident response from Day 1 is essential to your cybersecurity hygiene.