Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data

Qubole's Platform Vulnerability

Qubole, a data lake platform owned by Idera, operates by assuming IAM roles within its customers' AWS accounts. This mechanism, while designed for seamless integration, became the primary vector for a recent breach. Customers configure an IAM role with specific permissions, and a trust policy allows Qubole's AWS account (specifically, account ID 805246085872) to assume this role. A crucial component of this trust relationship is the 'External ID,' a code that must accompany each AssumeRole request from Qubole. The vulnerability arose because, according to Wiz researchers, the attacker gained access to Qubole's AWS account credentials, enabling them to initiate AssumeRole requests with the correct External ID, thereby bypassing security controls and gaining access to customer environments.

This attack underscores a fundamental challenge in cloud security: managing third-party access. Even organizations that no longer actively used Qubole but had not revoked its IAM roles remained vulnerable. The attacker successfully exploited these dormant trust relationships, demonstrating that unmonitored or excessive permissions granted to third-party vendors can pose a significant and persistent risk. The incident highlights the importance of a least-privilege approach, not just for internal users but critically for external integrations, and the necessity of regularly auditing and revoking unnecessary vendor access.

External ID Mechanism

The External ID is intended to prevent the 'confused deputy' problem, ensuring that only the intended third party can assume a role. However, the article notes that AWS's guidance states the External ID is not treated as a secret and can be viewed by anyone with access to the role. In this breach, the attacker, having compromised Qubole's credentials, was able to supply the correct External ID with every AssumeRole request, rendering this control ineffective as a standalone security measure. This suggests a potential misunderstanding or misapplication of the External ID's security properties, where it was perhaps implicitly relied upon as a secret rather than a unique identifier.

The attacker's ability to successfully use the External ID, combined with compromised Qubole credentials, allowed them to enumerate and exfiltrate sensitive data. They specifically targeted environment variables for Lambda functions, secrets from Secrets Manager, and values from the SSM Parameter Store. Furthermore, the attacker copied entire S3 buckets, indicating a broad data exfiltration strategy rather than targeted searches. This method of operation, coupled with the use of tools like TruffleHog to test discovered credentials, points to a sophisticated and methodical approach to data theft and credential harvesting within the compromised customer environments.

CloudTrail Forensics and Remediation

Cloud security company Wiz provided detailed hunting guidance for affected organizations, recommending a review of CloudTrail logs from October 1 onward. Key indicators of compromise include AssumeRole requests from Qubole's account ID (805246085872) originating from non-AWS IP addresses, specific IAM principal IDs (AIDA3W7DIFLYOLTK63SFS and AIDAJYRRH5Y3A7AAJM2HW from external IPs), and suspicious IP addresses associated with OVH and Mullvad VPNs. The presence of 'TruffleHog' in user agent strings during GetCallerIdentity calls also serves as a strong indicator of attacker activity. This forensic detail is crucial for victims to identify if and how they were impacted.

For remediation, the researchers recommend several critical steps. Organizations must rotate all secrets, parameters, and Lambda environment variables that the compromised Qubole role had access to, and revoke active sessions. Crucially, any Qubole role no longer needed should be removed or its trust policy updated to exclude Qubole's account. Implementing aws:SourceIp or aws:SourceVpce conditions to limit AssumeRole requests to documented vendor network ranges is highlighted as a highly effective preventative measure, as it would have blocked all observed role assumptions in this attack. Finally, changing the External ID to a different value for each role and treating it as a non-secret control is advised, reinforcing the principle of defense in depth rather than relying on a single, potentially exposed identifier.