VULNpocalypse
MediumSupply chainMonitoring

Wiz says attacker abused Qubole AWS role access in customer breaches

Wiz says an attacker used a Qubole AWS account to access customer AWS accounts; Qubole users should check CloudTrail logs from October 1 onward.

Published
Ecosystem
Cloud
Exploitation
Yes, according to Wiz as reported by The Hacker News; not independently verified and not confirmed by Qubole or Idera

What happened

According to The Hacker News, citing cloud security company Wiz, an attacker broke into AWS accounts belonging to multiple Qubole customers between October 14 and October 26 and stole stored secrets and data. The Hacker News This is Wiz’s account as relayed by one outlet. Neither Qubole nor Idera had posted a statement on their websites when The Hacker News checked, so the incident is not confirmed by the vendor. The Hacker News

The Hacker News reports that the attacker used credentials for an AWS account that Qubole’s platform uses to reach customers. How the attacker obtained those credentials has not been disclosed. The Hacker News

How the access works, per The Hacker News:

  • Qubole, a data lake platform owned by Idera, operates inside customers’ AWS accounts. A customer creates an IAM role whose trust policy lets Qubole’s AWS account assume it. Each AssumeRole request must include an External ID from Qubole. The Hacker News
  • Wiz’s researchers say most of the roles the attacker assumed were unused, but each still trusted Qubole’s account, so the requests worked. The Hacker News
  • Every AssumeRole request tied to the attacker carried an External ID and was accepted, the researchers said. The article notes, citing AWS guidance, that the External ID is not treated as a secret. The Hacker News

What Wiz says the attacker did in the accounts it examined:

  • It read Lambda environment variables, pulled secrets from Secrets Manager and read values from SSM Parameter Store. The Hacker News
  • It tested the credentials it found with TruffleHog. These were victims’ own AWS access keys, Entra ID client secrets and Okta client credentials. The Hacker News
  • It copied data out of S3, taking data from any bucket a role could access and sometimes downloading a whole bucket in one session. The Hacker News

Sentra spotted the activity in several of its customers’ environments and alerted the researchers. The Hacker News

What is not confirmed: the number of victims, the volume of data taken, and how the credentials were obtained. The researchers did not say whether the credentials have since been disabled or whether the activity has stopped. They have not linked the campaign to other publicly reported activity, and say the targeting does not match what state-backed groups usually go after. The Hacker News

Separately, The Hacker News reports that from October 8 to October 11 an attacker used customers’ own AWS access keys, which the researchers believe had been set up for Qubole, and compromised a few victims’ cloud environments. This has not been linked to the AssumeRole abuse. The Hacker News

Am I affected?

The Hacker News advises that any organization that has connected Qubole to AWS, even one that no longer uses it, should check its CloudTrail logs from October 1 onward. The Hacker News Separately, Wiz’s researchers are reported as saying that most of the roles the attacker assumed were unused but still trusted Qubole’s account. The Hacker News If you never created a Qubole IAM role or access key, the source gives no indication that you are in scope.

Indicators listed by Wiz, as reported by The Hacker News (search CloudTrail from October 1 onward in every AWS account that holds a Qubole role): The Hacker News

  • AssumeRole requests where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address. The researchers saw Qubole’s real traffic come only from AWS.
  • IAM principal ID AIDA3W7DIFLYOLTK63SFS: any activity should be investigated, as only the attacker used it in the accounts examined.
  • IAM principal ID AIDAJYRRH5Y3A7AAJM2HW when the source address is outside AWS. Qubole’s normal traffic also uses it, so the source address matters.
  • OVH-hosted IPs 57.129.54[.]120 and 2001:41d0:70d[:]7800::.
  • Mullvad VPN IPs 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175. Other VPN users share them, so a match alone is not proof.
  • Role session names starting with quiam-, such as quiam-enum.
  • TruffleHog as the user agent on GetCallerIdentity calls from the IPs above, and the same user agent in identity provider sign-in logs.

The Hacker News also notes that CloudTrail management events do not show which S3 objects were read. That needs S3 data events or server access logs, and several victims lacked them, so responders could not tell which objects were read. The Hacker News

What to do now

The steps below are the recommendations Wiz’s researchers gave, as reported by The Hacker News. No vendor patch or official advisory is cited in the sources. The Hacker News

  1. Search CloudTrail from October 1 onward in every AWS account with a Qubole role, using the indicators above. For each suspicious session, review everything it did afterward, especially in Secrets Manager, SSM Parameter Store, Lambda and S3.
  2. If the attacker assumed one of your Qubole roles, rotate all secrets, parameters and Lambda environment variables that the role could reach, and revoke the role’s active sessions. Rotating a credential does not end sessions already issued.
  3. Remove any Qubole role you no longer need, or remove Qubole’s account from its trust policy.
  4. Where Qubole supports it, replace the account-wide :root principal in the trust policy with the specific IAM principal Qubole uses.
  5. Add an aws:SourceIp or aws:SourceVpce condition limiting AssumeRole to the vendor’s documented network ranges. The researchers said a source IP condition alone would have blocked every role assumption they observed.
  6. Treat the External ID as visible to others, since it is logged in plain text in CloudTrail. Change it, and use a different value per role where possible. Do not rely on it as your only control.
  7. Review what each vendor role can reach. The researchers say vendor roles are often granted access to Lambda settings, Secrets Manager, SSM parameters and broad S3 read permissions for convenience. The Hacker News notes that Qubole’s setup guide includes a sample S3 policy that lets the role read every bucket in the account.
  8. Alert on AssumeRole requests from a vendor account that arrive through a VPN or a hosting company the vendor has not used before.
  9. Log all accounts and regions with an organization trail, and enable S3 data events or server access logs for buckets holding sensitive data.

Sources