Dropbox Sign Security Breach

Overview of The Breach

On May 2, 2024, Dropbox disclosed a significant breach involving its digital signature service, Dropbox Sign (formerly HelloSign). The breach was discovered on April 24, with unauthorized access traced back to a compromised service account within Dropbox Sign’s backend infrastructure. This allowed attackers to exploit elevated privileges and access a customer database, affecting all Dropbox Sign users.

Details of Compromised Data

The breach led to the exposure of sensitive information, including emails, usernames, general account settings, and for some users, phone numbers, hashed passwords, and critical authentication data like API keys, OAuth tokens, and multi-factor authentication (MFA) details. Notably, the breach also affected individuals who interacted with Dropbox Sign documents but did not create an account. This caused the exposure of their names and email addresses.

Potential Impacts and Dropbox’s Response

Dropbox has initiated several remedial actions in response to the breach. These include resetting user passwords, logging out users from connected devices, and rotating all compromised API keys and OAuth tokens. The company is currently reaching out to all affected users with specific guidance to secure their information. Dropbox is also cooperating with law enforcement and regulatory authorities.

The ultimate impact of this breach is unknown, but it is likely to be significant. Now that the attackers have critical authentication data, they can hop between customers’ accounts, retrieve more data, and put more customers in danger.

The Role of Suridata in Enhancing Security

The Dropbox Sign breach highlights the essential role of Suridata in both preventing and responding to similar cybersecurity incidents. With its capabilities in managing and securing third-party apps and APIs, Suridata is particularly valuable, especially as it integrates Dropbox as a core business SaaS application within its management framework. As the breach occurred in Dropbox Sign, which is an integral part of Dropbox’s suite of services, leveraging Suridata enables organizations to gain precise insights into their Dropbox account activities. This includes detailed tracking of account movements, connected plugins, and both human and non-human account interactions, along with the specific times each element was accessed. Moreover, Suridata provides a comprehensive risk analysis, identifying misconfigurations that could lead to unauthorized access.

Additionally, Dropbox serves as a third-party application used in various business applications. Suridata can identify on what applications Dropbox is being authorized, and point out where it should be isolated or where credentials should rotate.

For example, Suridata can assist with:

  • Isolating sensitive integrations: Detecting and managing which third-party applications, like Dropbox Sign, are authorized to integrate with core business applications, recommending isolation or restricted access where necessary.
  • Rotating and managing credentials: Identifying and implementing automated workflows for credential rotation for services connected to Dropbox Sign to prevent unauthorized access from compromised credentials.
  • Enhanced view of account activities: Ensuring that all users and API activities within Dropbox Sign are monitored with alerts for any unauthorized access attempts or anomalous behaviors.
  • Applying access controls: For example, enforcing policies that require multi-factor authentication for all accesses to Dropbox Sign.
  • Regular risk assessment: Regularly scanning and assessing Dropbox Sign configurations and usage to identify potential security misconfigurations or vulnerabilities that could lead to breaches.

This proactive and detailed approach empowers organizations to enhance their security postures effectively, ensuring that their data remains secure while protecting sensitive data, against evolving cyber threats and maintaining trust with users.

Potential Attack Path


Shiran Rachman

Product Lead

Back to list

Security Breach at Sisense: A Comprehensive Overview 

Breach Details

In April 2024, Sisense, established in 2004 to offer business intelligence and data analytics software, suffered a significant data breach. The breach involved unauthorized access to Sisense’s GitLab code repository, which led to the exfiltration of data from Sisense’s Amazon S3 accounts. This breach has been described as one of the most severe in recent times, potentially affecting millions of credentials. 

Implications 

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has taken an active role in addressing this breach due to its potential to initiate a massive supply chain attack that could affect thousands of companies globally. The breach highlights critical vulnerabilities in software products and the growing interest of attackers in targeting such infrastructure. 

Call to Action 

In response to the breach, Sisense’s CISO has issued urgent recommendations for all customers to rotate any credentials used within their Sisense applications immediately (see the original message) 

Customers should also reset API keys and look for unusual activity starting from April 5th, 2024. Users must act quickly to mitigate further risks. 

How Suridata Could Have Helped 

In this incident, Suridata could have mitigated the risk significantly by:  

  • Securing access to Gitlab using IP based controls 
  • Ensuring that all users access requires MFA and that there are no exceptions 
  • Configuring and scanning to confirm that there is no committing of credentials into code  
  • Restrict AWS API key usage by IP Address 
  • Making sure that client information is encrypted at rest 
  • Detect Sisense as a shadow SaaS / third-party app connected to core business applications.

Conclusion 

The Sisense data breach serves as a critical reminder of the importance of enhanced SaaS security practices, especially in safeguarding interconnected applications and third parties. Companies must stay proactive in their security strategies to protect their data and maintain trust with their customers and partners. 


Shiran Rachman

Product Lead

Back to list

The Inside Story of Cloudflare’s Battle Against an Auth Token Breach and How It Could Have Been Prevented

Last October, Okta, the $1.8 billion identity and access management (IAM) giant, revealed that it had been targeted in a complex and multifaceted cybersecurity attack that exposed vulnerabilities in the company’s digital identity security. The attack highlights the risks associated with managing sensitive user data. It also demonstrates the necessity of robust digital SaaS identity security measures, along with the importance of rapid detection, communication, and response to those kinds of threats. This article looks at what happened, and how it could have been prevented.

First, to truly understand the Cloudflare breach, we need to see the timeline of events:

October 2023: Okta  Breach

Early October: Okta’s breach occurred, resulting in the compromise of various customer credentials, including those belonging to Cloudflare.

The breach began with an attack that exploited a stolen cookie from Okta’s support system, leading to unauthorized access to Okta’s support case management system. This system, separate from the main Okta service, is used for managing customer support tickets and related data, which includes sensitive HTTP Archive (HAR) files containing cookies and session tokens crucial for maintaining user sessions.

The breach led Okta to revoke session tokens embedded in shared HAR files, disable the compromised service account, and implement measures to prevent employees from signing into personal accounts on Okta-managed devices. These steps were part of Okta’s broader effort to enhance security and combat the threat of session token theft against administrators. Those crucial measurements can be performed through a centralized SaaS Security platform, such as Suridata.

October 18, 2023: Cloudflare’s Okta instance was specifically breached using the authentication token stolen from Okta’s support system, affecting files belonging to 134 customers, including Cloudflare.


November 2023: The Cloudflare Attack & Response

November 14, 2023: Attackers first gained unauthorized access to Cloudflare’s self-hosted Atlassian server, marking the beginning of the direct attack on Cloudflare.

November 22, 2023: The attackers established persistent access through ScriptRunner for Jira, accessing the source code management system, and attempting to access a console server linked to an undeveloped data center in São Paulo, Brazil.

November 23, 2023: Cloudflare detected malicious activity within its systems.


Post-Attack Actions

November 26, 2023: Cloudflare’s cybersecurity forensics team initiated a detailed investigation into the incident.

In the following weeks: Cloudflare undertook extensive remediation efforts, including credential rotation, system segmentation, forensic triage, and a comprehensive reboot of systems across its global network.

January 5, 2024: Formal remediation efforts were concluded, although Cloudflare maintains ongoing efforts in software hardening and security improvements.


Insights and Summary:

The Cloudflare breach was initiated through the exploitation of stolen authentication tokens and service account credentials from a prior Okta breach. Attackers targeted Cloudflare’s self-hosted Atlassian server, gaining unauthorized access to its Confluence, Jira, and Bitbucket systems. Despite the attackers’ efforts, the breach did not affect customer data or systems. Cloudflare undertook extensive remediation efforts, including credential rotation, to prevent future intrusions.


How Could have Suridata Prevented this Attack?

  1. The breach highlights the complex challenge of managing and securing authentication tokens and service account credentials in a landscape where sophisticated attackers continuously seek to exploit any vulnerabilities. Suridata protects tokens and API keys by proactively monitoring those digital assets, revoking their access, deleting them, setting expiration dates, granting specific scopes, and alerting for the need for rotation of tokens and credentials. In this case, Suridata could have detected the access permissions granted through the token, its usage, and who granted and used the token. Suridata could have then alerted the relevant admins or the security team regarding the suspicious activities and high-risk score, thus preventing the misuse of the tokens.
  2. Suridata, which integrates with critical systems such as Okta, Confluence, Jira, and Bitbucket, could offer substantial benefits in the early detection and mitigation of cybersecurity risks. Suridata’s capability to connect with these systems means it can continuously monitor for new risks, anomalies, or changes in user or token behavior, providing a proactive stance against potential security threats.
    This means that any unusual behavior or deviation from the norm, such as the misuse of authentication tokens or unexpected changes in user privileges, could be quickly identified. This level of surveillance is crucial for early detection of security incidents, potentially even before any data compromise occurs.

Conclusion

A breach of this magnitude is a serious problem for any business. For a company like Okta, whose brand is largely based on its reputation for guarding identity credentials, this breach proved to be a major embarrassment—and a significant distraction and resource drain in the remediation process. No system is ever completely bulletproof, but an examination of the attack chain suggests that certain countermeasures, such as those provided by Suridata, could have mitigated the threat.


Shiran Rachman

Product Lead

Back to list

Triple Threat: Third-Party Apps Lead to Breaches at Three Finance Leaders  

Introduction

In the ever-evolving landscape of cyber threats, the financial services sector has recently encountered a series of sophisticated attacks. This article delves into three notable incidents, underscoring the pivotal role of third-party applications in these breaches. 


First American’s System Shutdown

The cyberattack on First American, a leading title insurance provider, led to a significant system shutdown. Following a 2019 data breach, attackers exploited vulnerabilities in a third-party application, accessing sensitive customer documents and credentials without authentication. Suridata’s SSPM solution, with its advanced discovery and alert capabilities, could have been instrumental in averting such risks. 


Fidelity National Financial’s Disrupted Services

Fidelity National Financial experienced service disruptions due to a cyberattack that implicated the AlphV/BlackCat group. The attackers capitalized on the CitrixBleed vulnerability, extracting valid session tokens to bypass authentication and gain unauthorized access. This incident highlighted the necessity of vigilant security measures, particularly against sophisticated third-party app exploits. Suridata’s expertise in detecting unauthorized plugin access could have been crucial in preventing such breaches. 


Mr. Cooper’s Massive Data Breach

Mr. Cooper, a mortgage servicing firm, reported a breach affecting 14.7 million individuals. An unauthorized third party accessed technology systems, underlining the significance of enhanced security in third-party collaborations. Suridata’s comprehensive risk management approach could ensure high security standards among partners, preserving the integrity of customer banking information. 


Conclusion

The financial sector’s recent cyberattacks demonstrate the urgent need for dynamic and proactive security solutions focused on third-party application threats. 

Suridata’s SaaS Security solution provides any organization with knowledge about the third-party applications that are connected to its core applications, with full coverage of existing risks, users’ data, permissions, and the ability to perform actions in order to remediate risk. Suridata’s approach ensures business continuity and the safeguarding of customer trust. 

Shiran Rachman

Product Lead

Back to list

ServiceNow Potential Misconfiguration Risk: A Wake-Up Call

Introduction- What is ServiceNow?

ServiceNow, uniquely positioned as both a Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS), offers a versatile digital workflow platform.

Key applications include IT Service Management (ITSM) for automating IT services, IT Operations Management (ITOM) for infrastructure optimization, IT Asset Management (ITAM) for asset tracking, Service Desk and Customer Support for efficient issue resolution, and an Employee Self-Service portal.

This multifunctionality makes ServiceNow a repository for a vast array of valuable organizational data, attracting attention in the realm of cybersecurity.


Security Alert: ServiceNow’s ACL Vulnerability Explained

ServiceNow experienced a data exposure flaw. This vulnerability, involving the default configurations of access control lists (ACLs) in ServiceNow’s widgets, particularly the ‘Simple List’ widget, enabled unauthenticated access to sensitive data stored in the ServiceNow platform​​​​.


What Led to This Situation?

The flaw stemmed from the way ServiceNow’s widgets, which act as APIs for the Service Portal, were configured. These widgets, by default, were set to public, allowing unauthenticated access to specified data. The vulnerability existed because the access control for these widgets was not governed by Access Control Lists (ACLs) but by fields on the individual widget record itself​​​​.


What Is the Risk?

Potentially, the leak could affect thousands of companies that use the platform. Attackers could steal personally identifiable information (PII) such as names, email addresses, customer records, financial information, and intellectual property.

There was a risk of unauthorized access to sensitive data, which could have severe implications for data privacy and security for the organizations using ServiceNow​​.


How Would Suridata Make the Difference?

Suridata focuses on SaaS security, pinpointing misconfigurations and safeguarding sensitive data across applications. Using its advanced monitoring and automated remediation features, the platform can detect configurations like ‘Widgets with Public Access’ early on, preventing unauthorized data access.


How to Address and Mitigate the Risk?

Remediation steps include reviewing and securing ACLs with roles or addressing the underlying access control issues. In addition, implementing temporary mitigations such as inbound IP address restrictions and disabling public widgets.

Organizations are advised to take the security of their data into their own hands, thoroughly reviewing both customer-made configurations and the vendor’s product default configuration.

Implementing Suridata as a security measure for misconfiguration drift monitoring would have prevented the potential loss of data.


Shiran Rachman

Product Lead

Back to list