Author: Shiran Rachman

Recently, the security landscape has been shaken by several high-profile breaches, and the latest incident involving GitHub tokens has once again highlighted the critical importance of Machine-to-Machine security practices. This blog dives deep into the details of The New York Times GitHub token breach that exposed the entire source code of The New York Times, its implications, and what organizations can do to safeguard their systems. 

A Bad Time for The New York Times: Entire Source Code Exposed 

Using a stolen GitHub token, attackers exploited access to The New York Times’ GitHub repositories. 

This token was overprivileged, granting access to all repositories within The New York Times GitHub organization. It is probable that the token was poorly managed, having a long expiry period, being leaked through accidental public exposure, stored on a compromised employee’s device, or used by an ex-employee to access private GitHub content. 

This breach underscores the risks associated with SaaS application tokens, which are often the most vulnerable points and the entry point to the organization’s sensitive data.  

What Happened? 

The breach occurred in January 2024 when attackers used a stolen GitHub token to access The New York Times’ repositories. The attacker leaked data, which included 270GB and over 5,000 repositories, with fewer than 30 being encrypted. The stolen files contained IT documentation, infrastructure tools, and source code, including the viral Wordle game. 

The Impact 

The impact of this breach is far-reaching:

• Repository Access: Attackers could access private repositories, leading to data leaks and exposure of proprietary code. 
• Data Manipulation: With write access, malicious actors could alter or delete critical code, inject malicious code, or disrupt development processes. 

How Could Suridata Help?  

At first, to prevent such breaches, Suridata protects your repositories and data at GitHub, with the following best practices: 

• Token Management: Suridata maintains an inventory of your GitHub tokens, allowing investigation for each one. This includes the latest access, and expiration dates. 
• Regular Token Rotation: Suridata alerts you to rotate tokens frequently to minimize the impact of potential breaches. 
• Implement Least Privilege: Suridata displays the permissions granted to tokens and recommends the minimum necessary for their operation. 
• Breach Detection: Suridata continuously monitors all tokens across the SaaS environments, detecting anomalies in usage and changes in roles and permissions. 

Following a potential breach, Suridata responds as follows: 

• Revoking Tokens: Revoking any compromised tokens to prevent further unauthorized access. 
• User Notification: Promptly notify impacted users, advising them to regenerate their tokens and review repository access logs. 

Conclusion 

Organizations must remain proactive in securing their development environments, especially when they are easily accessed through tokens. By continuously improving defenses, and embracing automated responses, organizations can better protect their valuable assets from evolving threats. 

Not sure if you are using GitHub? Suridata offers free application scanning to help you identify and prevent attacks in your SaaS environments. 

---

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

---

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. 

---

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.

---

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.

---