AWS Bedrock AgentCore: el usuario del sandbox podía instalar una CA propia en el almacén de confianza del sistema vía sudo

Resumen

El Code Interpreter de Amazon Bedrock AgentCore ejecuta el código del usuario dentro de un sandbox con un usuario sin privilegios, genesis1ptools (UID 992). Ese usuario no puede escribir en /etc/pki, pero tenía una excepción en sudoers: podía ejecutar como root, sin contraseña, este script:

/opt/amazon/genesis1p-tools/bin/deploy-certificates.sh

El script está pensado para instalar los certificados que el plano de datos entrega al servidor de herramientas a través del endpoint /certificates/configure. El problema es de dónde los saca: los lee de /tmp/certificates/, un directorio en el que el propio usuario del sandbox puede escribir. Después los copia como root a /etc/pki/ca-trust/source/anchors/ y ejecuta update-ca-trust, con lo que pasan a ser certificados de confianza para todo el sistema.

La combinación de ambas cosas es una escalada de privilegios acotada pero muy útil para un atacante: cualquiera puede dejar su propia autoridad de certificación (CA) en /tmp/certificates/, lanzar el script con sudo y conseguir que el sistema confíe en ella. A partir de ahí puede firmar certificados válidos para cualquier dominio, incluidos servicios internos de AWS. Según el investigador, el fallo estaba presente en todas las sesiones del Code Interpreter, también en las abiertas desde la consola de AWS, y bastaba con una cuenta de AWS con acceso a Bedrock AgentCore, sin permisos especiales.

La debilidad registrada en HackerOne es validación incorrecta de certificados, con severidad media. El reporte se envió el 28 de marzo de 2026 y se hizo público el 28 de julio de 2026.

Pasos de reproducción

El investigador lo automatizó con un script (demo-rogue-ca.py, adjunto al reporte original) que usa el SDK bedrock-agentcore para abrir una sesión del Code Interpreter:

pip install bedrock-agentcore

El SDK solo sirve para la prueba de concepto; la regla sudo y el directorio escribible existen en cualquier sesión.

1. Lanzar la prueba:

``bash python3 demo-rogue-ca.py ``

El script genera una CA propia, la instala en el almacén de confianza mediante el script permitido por sudo y falsifica un certificado para un servicio interno de AWS.

1. Comprobar que no se es root y que no se puede escribir directamente en el almacén de confianza:

`` 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 ``

1. Ver la regla sudo que permite ejecutar el script como root sin contraseña:

`` 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 ``

1. Generar una CA propia y dejar su certificado en /tmp/certificates/:

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

1. Ejecutar el script con sudo. Corre como root, copia el certificado y actualiza el almacén:

`` 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 ``

1. Verificar que la CA ya está en el almacén de confianza, propiedad de root:

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

1. Firmar con esa CA un certificado para un servicio interno de AWS (el nombre aparece censurado en el reporte) y comprobar que un contexto SSL con la CA falsa lo acepta:

`` 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 ``

Impacto

Con la CA instalada, cualquier proceso del sandbox que valide certificados contra el almacén del sistema acepta los certificados que firme el atacante. El investigador describe estas consecuencias:

• Interceptar cualquier conexión TLS que salga del sandbox (ataque de intermediario, MITM).
• Suplantar servicios internos de AWS: lo demostró con un certificado válido para el servicio upstream al que un proxy interno se conecta por mTLS en el puerto 8443.
• Cadena completa de intercepción al combinarlo con otro hallazgo suyo (exposición de credenciales vía IMDS): las etiquetas de IMDS dejaban ver la clave simétrica con la que ese proxy firma sus peticiones (firmas válidas durante 900 segundos como máximo). Con esa clave y un certificado falso del servicio upstream, el atacante tendría tanto la identidad TLS como la capacidad de firmar peticiones para suplantar o interceptar la comunicación entre el proxy y el servicio.
• Ataque a la cadena de suministro vía pip: interceptando las conexiones HTTPS de pip install se pueden servir paquetes maliciosos y ejecutar código arbitrario en las instalaciones posteriores dentro de la misma sesión.

Remediación

El reporte figura como resuelto, pero no detalla qué cambió AWS. Las medidas que proponía el investigador eran:

• Que /tmp/certificates/ sea de root y solo pueda escribir en él el proceso del servidor de herramientas, nunca el usuario del sandbox.
• Quitar la regla sudo: si el servidor de herramientas ya ejecuta el script al configurar los certificados, el usuario del sandbox no necesita lanzarlo.
• Hacer que el script compruebe el origen de los certificados (por ejemplo, con un manifiesto firmado o revisando los permisos de los ficheros) antes de instalarlos.
• Usar un directorio dentro de una ruta propiedad de root, en la que el usuario del sandbox no pueda escribir, en lugar de /tmp/certificates/.