Qubole Customers Targeted in AWS Account Breach by Hackers

Between October 14 and October 26, an attacker breached AWS accounts belonging to multiple Qubole customers, stealing stored secrets and data, as reported by cloud security company Wiz.

The attacker exploited credentials for an AWS account utilized by Qubole’s platform to access its customers. The method by which the attacker obtained these credentials has not been disclosed.

Qubole, a data lake platform owned by Idera, operates within its customers’ AWS accounts. Customers create an IAM role, which is an AWS identity with specific permissions, to grant access to Qubole.

The role’s trust policy allows Qubole’s AWS account to assume the role, thereby granting the necessary permissions. Each request to do this, known as AssumeRole, must include a matching code from Qubole referred to as an External ID.

Wiz’s researchers noted that most roles assumed by the attacker were unused. However, since each role still trusted Qubole’s account, the attacker’s requests were successful.

Organizations that have connected Qubole to AWS, including those that no longer use it, should review their CloudTrail logs from October 1 onward. They should look for an AssumeRole request from the account used by Qubole’s platform, 805246085872, originating from an address outside AWS.

The researchers did not confirm whether the compromised credentials have been disabled or if the malicious activity has ceased. As of the latest check, neither Qubole nor Idera had issued a statement regarding the attack on their websites.

Details of the Attack

Every AssumeRole request associated with the attacker included an External ID and was accepted, according to the researchers’ technical analysis. AWS accepts an AssumeRole request for such a role when it originates from the trusted account and includes the correct External ID. This code is not treated as a secret, allowing anyone with access to the role to view it.

Sentra detected the activity in several of its customers’ environments and alerted the researchers. In the examined accounts, the attacker sought stored credentials, reading environment variables for Lambda functions, extracting secrets from Secrets Manager, and accessing values from the SSM Parameter Store.

The attacker tested the credentials found using TruffleHog to determine their validity. These included the victims’ AWS access keys, Entra ID client secrets, and Okta client credentials.

Additionally, the attacker copied data from S3, retrieving information from any accessible bucket rather than searching for specific data, and sometimes downloading entire buckets in a single session.

The researchers have not linked this campaign to any other publicly reported activities, noting that the targeting does not align with typical state-backed group behavior.

Qubole also allows customers to connect using AWS access keys instead of roles. From October 8 to October 11, an attacker utilized customers’ AWS access keys, believed to have been set up for Qubole, to compromise several victims’ cloud environments. This activity has not been connected to the AssumeRole abuse.

Recommendations for Affected Accounts

Wiz’s guidance for affected accounts includes reviewing CloudTrail logs from October 1 onward for any suspicious activity. Key indicators to check for include:

• Account: AssumeRole requests where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address.
• IAM principal ID: AIDA3W7DIFLYOLTK63SFS. Any activity from this IAM user should be investigated.
• IAM principal ID: AIDAJYRRH5Y3A7AAJM2HW, when the source address is outside AWS.
• IP addresses: 57.129.54[.]120 and 2001:41d0:70d[:]7800::, which were used by the attacker.
• IP addresses: 45.83.220[.]211, 185.209.199[.]73, and 89.37.63[.]175, associated with Mullvad VPN.
• Session name: role sessions that start with quiam-, such as quiam-enum.
• User agent: TruffleHog on GetCallerIdentity calls from the specified IP addresses.

For each suspicious session, organizations should review all subsequent actions, particularly in Secrets Manager, SSM Parameter Store, Lambda, and S3.

CloudTrail management events log each AssumeRole request and bucket listing, but do not specify which S3 objects were read. This requires S3 data events or server access logs, which several victims lacked, hindering the ability to determine which objects were accessed by the attacker.

Mitigation Steps

To mitigate the risk, the researchers recommend the following actions:

1. Rotate all secrets, parameters, and Lambda environment variables accessible to any compromised Qubole role, and revoke the role’s active sessions.
2. Remove any unnecessary Qubole roles or exclude Qubole’s account from the trust policy.
3. Where applicable, replace the account-wide :root principal in the trust policy with the specific IAM principal used by Qubole.
4. Add an aws:SourceIp or aws:SourceVpce condition to limit AssumeRole requests to documented network ranges.
5. Recognize that the External ID can be viewed in plain text in CloudTrail and should not be the sole control.
6. Review the access permissions of each vendor role.
7. Set alerts for AssumeRole requests from vendor accounts that originate from unfamiliar VPNs or hosting companies.
8. Enable logging for every account and region with an organization trail, and activate S3 data events or server access logs for sensitive data buckets.

 

Source: The Hacker News