cyber.hendryadrian.com
Threat Research · wiz.io

AWS Bedrock API Keys Introduce Long-Lived Bearer Credentials, Wiz Finds

· Original article ↗

Summary

Wiz analyzes Bedrock’s long- and short-term API keys, their creation and logging, and risks from long-lived credentials. AWS says it added the keys to secrets scanning and quarantined previously exposed keys it found.

Key points

  • Long-term Bedrock keys are service-specific credentials associated with IAM Users; console creation also assigns AmazonBedrockLimitedAccess, which the article says grants more permissions than many use cases need.
  • Long-term keys can be configured not to expire, and the article says IAM policy conditions could not enforce their expiration when it was written; an edit notes AWS later added credential-age and service-name conditions.
  • The article describes long-term keys as 132-character bearer tokens sent directly in HTTPS requests, and says leaked keys appeared in public GitHub repositories within two weeks of launch.
  • AWS added Bedrock keys to GitHub secret scanning. AWS says it quarantined previously committed keys where found and will notify customers when scanning identifies exposed credentials.
  • Short-term keys are generated client-side by a library that creates and encodes a presigned URL; their creation is not logged in CloudTrail, but their use is.
  • CloudTrail usage events include callWithBearerToken; the article says IAM User principals indicate long-term keys, while IAM Role principals indicate short-term keys.
  • Wiz recommends blocking IAM User creation and denying bedrock:CallWithBearerToken; AWS says customers can use other existing authentication mechanisms for Bedrock.

Article Details

Attack Vectors
  • Long-term Bedrock API keys may be exposed when committed to public GitHub repositories.
  • Bedrock API keys are sent directly as bearer tokens in HTTPS requests.
  • Long-term keys created through the web console may receive the AmazonBedrockLimitedAccess policy, which the article says grants more privileges than many use cases require.
Defensive Notes
  • Use an SCP to prevent IAM User creation, which also prevents creation of long-term Bedrock API keys through the web console.
  • Deny the bedrock:CallWithBearerToken privilege to prevent use of long- and short-term Bedrock API keys.
  • Use AWS Secrets Scanning to identify exposed Bedrock API keys; AWS says it will quarantine the associated IAM User and notify the customer when a long-term key is committed to a public GitHub repository.
  • Review CloudTrail for iam:CreateServiceSpecificCredential events where requestParameters.service is bedrock.amazonaws.com to identify long-term key creation.
  • Look for additionalEventData.callWithBearerToken set to true to identify use of either key type; IAM Users indicate long-term keys, while IAM Roles indicate short-term keys.

Vendors

Amazon Web ServicesWhen AWS first launched two decades ago, the only way of authenticating applications was through long-lived access keys.

Products

Amazon BedrockAWS can confirm that the Secrets Scanning process has already been updated to include Amazon Bedrock API keys, no action from customers is required. The issue identified in the blog post occurred before the expansion ofCloudTrailprefix it with that string “bedrock-api-key-”.  Because this is making a pre-signed URL, there is no CloudTrail event for the creation of these short-term keys because it is all happening client-side. Therefore,GitHubThese long-term API keys are already showing up in public GitHub repositories. We first observed leaked keys there within two weeks of the launch.IAMBedrock API key choice in AWS consoleCreating a long-term Bedrock API key results in the creation of a new IAM User when done through the web console.  You can also manually create one of these keys by associating it

Related Articles