Sisense develops business intelligence software that allows users to analyze big data. They are known for their user-friendly interface, which enables users to create and share interactive dashboards.
What Happened?
On April 11, 2024, CISA reported a data breach at Sisense. The company has yet to make a public statement.
According to Brian Krebs, attackers gained access to an internal GitLab repository containing AWS Access and Secret Keys, which granted internal AWS S3 Buckets access. On April 10th, Brian made his first post on Mastodon regarding the breach.
The breach implies attackers accessed Sisense’s 1,000+ customers’ credentials for connectors like internal warehouses. All connectors can be found here.
Both sources said the attackers used the S3 access to copy and exfiltrate several terabytes worth of Sisense customer data, which apparently included millions of access tokens, email account passwords, and even SSL certificates.
Who’s affected?
As of right now, it appears that all customers have been affected, although it’s unclear whether or not on-premise deployments were affected. According to Censys, the majority of Sisense customers are US-based.
How do we Remediate?
Sisense’s CISO, Sangram Dash, has sent several messages to customers regarding remediation, rotation, and securing your instance:
Out of an abundance of caution, and while we continue to investigate, we urge you to promptly rotate any credentials that you use within your Sisense application.
The extent of the remediation steps implies that this breach was very serious and could have widespread consequences for customers. Like what we saw with the xz-utils compromise, supply-chain attacks have an exponential impact.
Hypothetical Response
Defenders could respond to a breach like this in several ways, such as collecting and analyzing AWS logs. API calls to S3 Buckets can be monitored with AWS CloudTrail and AWS S3 Server Access logs, which answer questions about which objects were accessed by whom and when. The former is best for internal monitoring, such as from web applications or IAM users accessing buckets, whereas the latter is more of an HTTP-style traffic access log.
If CloudTrail was configured to collect logs from the internal S3 bucket, defenders could run a query like this to review access during the attack window:
SELECT * FROM aws_cloudtrail
WHERE userIdentity:accessKeyId = 'ACCESS-KEY-HERE'
AND eventTime BETWEEN '2024-04-05 00:00:00Z' AND '2024-04-14 23:59:59Z'
LIMIT 10;
CloudTrail could also be generically queried for all s3 API calls, ignoring internal userAgent strings.
SELECT *
FROM aws_cloudtrail
WHERE eventSource = 's3.amazonaws.com'
AND NOT userAgent LIKE '%.amazonaws.com' # Ignore internal API calls
AND eventTime BETWEEN '2024-04-05 00:00:00Z' AND '2024-04-14 23:59:59Z'
LIMIT 50;
AWS S3 Server Access Logs could also be queried for traffic in and out of a particular bucket:
SELECT * FROM aws_s3serveraccess
WHERE bucket LIKE 'name-goes-here-%'
LIMIT 50;
The moral of the story is that you should always monitor access to and from your crown jewels!