Sisense Breach – Stealing a Valet Lockbox

by | Apr 19, 2024

Why break into a single company to get access to their data, when you can break into one aggregator to gain access to hundreds? The breach of Sisense last week represents one of the most dangerous breaches of this year, and potentially longer. It’s not because of what data was exfiltrated directly from Sisense, but instead because the exfiltration involved the credentials of their customers in their applications. We are going to see downstream impacts and SEC reports from dozens of companies in the coming weeks disclosing that data was stolen from their environments using the credentials taken from Sisense. Let’s figure out how we got here.

Sisense is an analytics platform designed to allow teams to ingest their business data and build dashboards, charts, and graphs that can be used to drive improvements in the business. To utilize these capabilities, businesses must connect the relevant data sources to Sisense. This can be cloud providers, databases, data warehouses, SaaS applications, or even servers directly. Once connected users can analyze the data using Sisense’s models, draw advanced charts, or intelligently merge disparate data.

Sisense Breach Stealing a Valet

Gaining access to all of these data sources can be an attacker’s dream. Instead of working to breach an organization, slowly working their way around, probing, and moving laterally, until they eventually reach a data source, they can instead just crack open Sisense and find all the critical data for the business in one place. It’s a proverbial gold mine of information. It is the metaphorical equivalent of popping open the lockbox at a car valet. You can grab the keys to any car you would like and have instant access.

How did this happen?

Initial reports indicate an elevated account with privileged access to Sisense’s corporate Gitlab repositories was breached. The attackers used the access to Gitlab to search for sensitive information embedded in the source code of the Sisense application and discovered plain text tokens to the Sisense AWS S3 buckets. Sisense seems to be using the AWS S3 service to store both the credentials customers used in their dashboards as well as the customer data. Sources close to the investigation indicate that attackers exfiltrated terabytes of customer data and credentials such as access tokens, email account passwords, and certificates.

Due to the nature of providing a persistent dashboard of these data sources the credentials customers provide and that have been stolen are long-living credentials. This further complicates the remediation efforts as it provides attackers with non-expiring access to customer systems and data that Sisense is not centrally in control of. It will be up to each customer to go through all the applications that they connected to Sisense and revoke the credentials.

What could’ve been done to prevent this attack?

This attack is a shining example of the often thrown-around phrase “identity is the new perimeter”. The initial breach did not happen by physically breaking into a data center or hacking a firewall, instead, the compromised perimeter was a single user account. That’s all it takes to expose a company to broad exploitation, is a single account being taken over.

All privileged accounts must have MFA enabled. This is no longer in dispute, dozens of vendors provide this service and it should be set up using an authenticator app instead of SMS. We’ve seen story after story of SIM swapping and how poorly this is regulated in the telecommunications industry. To make MFA truly secure, authenticator applications are a must.

Companies should also be proactively monitoring the permissions of accounts where sensitive information is stored. Using software platforms like Zilla Security to understand what permissions people have, be alerted when they gain access to sensitive applications, and audit that access regularly with processes such as user access reviews to ensure that access is still needed. We don’t know the finer details of the Gitlab permission that was compromised but it is safe to assume all of these controls were not in place.

Beyond the initial breach, there were cascading failures that allowed this attacker to continue the attack. The next failure occured in the data security practices at Sisense where the S3 keys were stored in the Gitlab repositories in plain text. This is a major security best practice violation for just this reason. Gaining access to your source code should not provide further access to your systems. The Sisense team should have used encryption to store the keys or stored the keys in an external security vault outside of the source code.

Continuing down the failure chain, once the attackers were able to use the AWS keys to gain access to the S3 environment they were able to directly access customer data and credentials. None of this data was encrypted, representing a massive security failure and breaking the trust of Sisense customers who have entrusted highly sensitive business information with this provider.

In a broader sense, Sisense needs to enact a security program to educate the development and infrastructure teams on security best practices and developing secure software. This is critical to avoid these types of failures in the future.

What should Sisense customers do now?

Immediately customers should revoke and disable every account, credential, token, and certificate provided to Sisense. In a email from the SIsense CISO this week they specifically call out the following remediation steps as soon as possible.

Our customers must reset any keys, tokens, or other credentials in their environment used within the Sisense application.

Specifically, you should:

Change Your Password: Change all Sisense-related passwords on http://my.sisense.com

Non-SSO:

  • Replace the Secret in the Base Configuration Security section with your GUID/UUID.
  • Reset passwords for all users in the Sisense application.
  • Logout all users by running GET /api/v1/authentication/logout_all under Admin user.

Single Sign-On (SSO):

  • If you use SSO JWT for the user’s authentication in Sisense, you will need to update sso.shared_secret in Sisense and then use the newly generated value on the side of the SSO handler.
  • We strongly recommend rotating the x.509 certificate for your SSO SAML identity provider.
  • If you utilize OpenID, it’s imperative to rotate the client secret as well.
  • Following these adjustments, update the SSO settings in Sisense with the revised values.
  • Logout all users by running GET /api/v1/authentication/logout_all under Admin user.
  • Customer Database Credentials: Reset credentials in your database that were used in the Sisense application to ensure continuity of connection between the systems.
  • Data Models: Change all usernames and passwords in the database connection string in the data models.
  • User Params: If you are using the User Params feature, reset them.
  • Active Directory/LDAP: Change the username and user password of users whose authorization is used for AD synchronization.
  • HTTP Authentication for GIT: Rotate the credentials in every GIT project.
  • B2D Customers: Use the following API PATCH api/v2/b2d-connection in the admin section to update the B2D connection.
  • Infusion Apps: Rotate the associated keys.
  • Web Access Token: Rotate all tokens.
  • Custom Email Server: Rotate associated credentials.
  • Custom Code: Reset any secrets that appear in custom code Notebooks

Author

  • ZILLA FINALS 32

    Adam St. Onge is the Regional Director of Sales for Zilla Security, leading a team of sales professionals. He is passionate about solving complex problems and driving results that help internal and external teams reach their goals.

    Before joining Zilla Security, Adam held technical and leadership positions in organizations ranging from Fortune 500 to disruptive start-ups. These roles included responsibilities for technical architecture, engineering, IT operations, and technical sales.

    Adam holds a Bachelor's degree in Computer Science from Mount Saint Mary College and a Master's degree in Networking from Rochester Institute of Technology.

    Connect with Adam via LinkedIn.

    View all posts

Recent Posts

Key Takeaways from a Discussion on Modern Identity Governance

Highlights of Zilla’s discussion on the need to modernize identity governance strategies. IGA experts covered the complex nature of IGA, the importance of automation and AI in a modern IGA strategy, and how to address the challenge of non-human identities.

Leveraging AI to Identify Birthright Access

AI Profiles take the pain out of onboarding, using machine learning to leverage Zilla’s existing knowledge of your applications and permissions to recommend user access profiles.