Sandbox User Can Inject Rogue CA Certificate into OS Trust Store via Sudo-Allowed deploy-certificates.sh

How it was found

NOTE! Thanks for submitting a report to Amazon Web Services! Please replace all the [square] sections below with the pertinent details. Remember, the more detail you provide, the easier it is for us to triage and respond quickly, so be sure to take your time filling out the report!

Description: The Bedrock AgentCore Code Interpreter sandbox grants the genesis1ptools user passwordless sudo access to /opt/amazon/genesis1p-tools/bin/deploy-certificates.sh. This script reads certificates from /tmp/certificates/ (writable by the sandbox user) and deploys them as root to /etc/pki/ca-trust/source/anchors/, then runs update-ca-trust to make them system-trusted.

An attacker can generate a rogue CA certificate, write it to /tmp/certificates/, and run the sudo-allowed script to inject it into the OS trust store. The rogue CA can then be used to forge certificates for any domain, including AWS internal services like ████████.

Steps To Reproduce:

Prerequisites:

• AWS account with Bedrock AgentCore access (any authenticated user, no special permissions required). The vulnerability exists in every Code Interpreter session.
• bedrock-agentcore SDK installed (pip install bedrock-agentcore) to run the PoC script. The SDK is not required for the vulnerability itself. The same sudo rule and writable /tmp/certificates/ directory are available in any Code Interpreter session, including via the AWS Console.

1. Run the attached PoC script demo-rogue-ca.py:

python3 demo-rogue-ca.py

The script generates a rogue CA certificate, deploys it to the OS trust store via the sudo-allowed script, and then forges a certificate for an internal AWS service to prove MITM capability.

2. Observe the output (see attached recording):

STEP 1: We are NOT root
  User: genesis1ptools
  UID: 992
  Can we write to /etc/pki? NO:
  touch: cannot touch '/etc/pki/ca-trust/source/anchors/test': Permission denied

STEP 3: We can run deploy-certificates.sh as ROOT (no password)
  (root) NOPASSWD: /opt/amazon/genesis1p-tools/bin/deploy-certificates.sh
  This means: we can install ANY certificate into the OS trust store

STEP 4: Generate rogue CA certificate
  Subject: CN=ATTACKER-ROGUE-CA,O=Malicious,C=XX
  CA: TRUE

STEP 5: sudo deploy-certificates.sh -- injects as root
  [INFO] Running as user: root
  [INFO] Deploying to /etc/pki/ca-trust/source/anchors/rogue-ca.pem
  [INFO] update-ca-trust completed successfully
  [INFO] SUCCESS: Certificate deployment finished

STEP 6: Rogue CA is now in the OS trust store
  -rw-r--r-- 1 root root 1139 rogue-ca.pem

STEP 7: Forge cert for ████████
  Subject: CN=████████
  Issuer:  CN=ATTACKER-ROGUE-CA,O=Malicious,C=XX
  Forged cert ACCEPTED by SSL context with rogue CA
  Signature verification: VALID -- forged cert is signed by rogue CA

Attachments:

• demo-rogue-ca.py -- Full PoC script
• Terminal recording showing the complete exploit

Impact

Summary:

1. MITM any TLS connection from the sandbox: The rogue CA is system-trusted after update-ca-trust. Any process in the sandbox that validates certificates against the OS trust store will accept forged certificates signed by the rogue CA.

2. Forge certificates for internal AWS services: Demonstrated by forging a valid certificate for ████████ (the upstream ████████ service that the ████████ proxy connects to via mTLS on port 8443).

3. Combined with AC4 (IMDS Credential Exposure) for full MITM chain: The IMDS tags expose the symmetric signing key used by the ████████ proxy for request authentication (900s max signature age). Combined with a forged certificate for the upstream service, an attacker has both the TLS identity and the request signing capability needed to impersonate or intercept proxy-to-upstream communications.

4. Supply chain attack via pip MITM: After injecting the rogue CA, an attacker can intercept pip install HTTPS connections and serve malicious packages, achieving arbitrary code execution on subsequent package installations in the same session.

Root Cause

The deploy-certificates.sh script is designed to deploy certificates provided by the Data Plane via the /certificates/configure API endpoint on the tools server. However, it reads from /tmp/certificates/ which is writable by the sandbox user. The sudo rule allows the sandbox user to run this script as root with no password, creating a privilege escalation path: unprivileged user writes to /tmp/certificates/, then uses sudo to deploy the contents as root to the OS trust store.

The script should validate that certificates in /tmp/certificates/ were placed there by a trusted process, not by the sandbox user.

Recommended Fix

1. Restrict /tmp/certificates/ ownership: The directory should be owned by root and only writable by the tools server process. The sandbox user should not be able to write to it.
2. Remove the sudo rule: If the tools server already runs the deploy script during certificate configuration, the sandbox user does not need direct sudo access to it.
3. Validate certificate source: The script should verify that certificates were placed by the tools server (e.g., via a signed manifest or a file permission check) before deploying them.
4. Use a dedicated certificate directory: Instead of /tmp/certificates/, use a directory under a root-owned path that the sandbox user cannot write to.

Disclosure

For awareness, we plan to publish a blog post detailing these findings after remediation. We are happy to share a draft ahead of publication and coordinate on timing.