Análisis técnico de la brecha de seguridad de Capital One causada por una configuración incorrecta en la nube

ACTUALIZACIÓN: 26 de agosto de 2019

Desde la publicación de este artículo, AWS hizo algunas declaraciones públicas sobre la filtración que arrojan luz sobre lo que probablemente ocurrió. En su respuesta al senador Ron Wyden, AWS afirmó:

"Como Capital One explicó en su anuncio público, el ataque ocurrió debido a un error de configuración en la capa de aplicación de un firewall instalado por Capital One, agravado por permisos configurados por Capital One que probablemente eran más amplios de lo previsto. Creemos que, después de obtener acceso mediante el firewall mal configurado y contar con permisos más amplios para acceder a los recursos, se utilizó un ataque SSRF (una de las varias formas en que un atacante podría haber accedido potencialmente a los datos después de entrar por el firewall mal configurado)".

"Como se explicó anteriormente, SSRF no fue el factor principal del ataque. No tenemos conocimiento de otros incidentes importantes de SSRF que hayan afectado a clientes de AWS".

Se ha hablado mucho del probable componente SSRF de la filtración, pero, como deja claro AWS, no fue el factor principal del ataque. Lo fueron las configuraciones demasiado permisivas de los recursos en la nube. Esta publicación describe en detalle algunas formas en que esos recursos podrían haberse configurado incorrectamente y cómo se podrían haber aprovechado esos errores.

PUBLICACIÓN ORIGINAL: 1 de agosto de 2019

Este es un análisis técnico de cómo pudo haber ocurrido la filtración de Capital One, basado en la información que tenemos de la denuncia penal. Quiero comenzar diciendo que respeto profundamente al equipo de nube de Capital One y que tengo amigos en él. Han sido líderes en computación en la nube, y lo que les ocurrió podría haberle pasado a casi cualquiera. Tampoco estoy criticando a Amazon Web Services (AWS), mi antiguo empleador. Ofrecen servicios seguros y les tengo el mayor respeto. El propósito de esta publicación es explorar un ataque que combina firewall, IAM y S3 para ilustrar algunos de los peligros de las configuraciones incorrectas en la nube que toda organización que la use debería tener en cuenta.

Para escribir esto, analicé los detalles técnicos de la denuncia del FBI y luego formulé una hipótesis sobre cómo podría haberse llevado a cabo el ataque. Después, simulé el ataque en mi cuenta de desarrollo para poder incluir detalles específicos en esta publicación.

Los hechos que conocemos

Tenemos algunos datos sobre el ataque, tanto de la denuncia del FBI como de las publicaciones en redes sociales de la presunta atacante. Al parecer, la atacante usó Tor e IPredator en combinación para ocultar su identidad y, a través de esos servicios, descubrió un firewall mal configurado en el entorno de AWS de Capital One. No está claro si fue un ataque dirigido contra Capital One o un ataque oportunista que se produjo al descubrir la configuración incorrecta.

Se han escrito muchos artículos sobre las posibles motivaciones y la biografía de la atacante, así que dejaré esos temas de lado para enfocarme en los detalles técnicos. Conocemos cuatro elementos distintos del ataque:

• Firewall mal configurado

• Acceso a una instancia EC2

• Acceso a S3 mediante un rol de IAM

• Descubrimiento y duplicación de buckets de S3.

A continuación, analizaremos cada uno de estos elementos en detalle.

Cómo pudo haber ocurrido el ataque

Tenemos algunos detalles, pero no muchos, por lo que tuve que especular e interpretar bastante los hechos disponibles. A medida que recorramos los pasos del ataque, indicaré claramente cuándo estoy especulando. El diagrama a continuación muestra mi entorno aislado, donde simulé algunos aspectos de la filtración de Capital One.

El entorno contiene:

1. una red VPC básica

2. un grupo de seguridad que permite HTTP(S) y SSH

3. un bucket privado de S3

4. dos roles de IAM: uno con acceso a S3 y otro sin él

5. una instancia EC2 con una dirección IP pública y un rol de IAM sin acceso a S3

Mi objetivo era pasar del acceso al shell de la instancia EC2 a la capacidad de acceder y copiar los datos de S3 en los buckets privados.

Antes de entrar en detalle sobre los distintos pasos, vale la pena señalar que el FBI obtuvo acceso gracias a una pista sobre un archivo alojado en GitHub que contenía la dirección IP de un servidor, junto con tres comandos:

"Capital One determinó que el archivo del 21 de abril contenía código para tres comandos, así como una lista de más de 700 carpetas o buckets de datos". Analizaremos en detalle cada uno de estos comandos, qué podrían haber sido y cuál pudo ser la estrategia de la atacante.

Paso uno: firewall mal configurado

Según la denuncia del FBI, "Una configuración incorrecta del firewall permitió que los comandos llegaran al servidor y se ejecutaran en él, lo que habilitó el acceso a carpetas o buckets... (III.A.10)"

Esto sugiere que el firewall era externo al servidor y no local, aunque no se especifica explícitamente. Si bien AWS ofrece muchos dispositivos virtuales de firewall, lo más habitual sería que se tratara de un grupo de seguridad. Parece que se dejó abierto un puerto peligroso en el tipo de firewall que se estuviera usando, lo que pudo haber sido la brecha inicial del ataque. Es posible que se hubiera abierto un puerto SSH durante una ventana de mantenimiento o que el servidor en cuestión hubiera quedado de trabajos de desarrollo y ya no se usara. Otra posibilidad es que el servidor ejecutara una aplicación como MongoDB o ElasticSearch, que requiere un puerto abierto para funcionar, pero que nunca debería haberse expuesto a Internet a través del firewall. Cualesquiera que fueran los detalles, la atacante encontró una vía para entrar en la infraestructura de computación en la nube de Capital One.

Paso dos: acceso a una instancia EC2

Según la descripción de la entidad comprometida como un “servidor” en la denuncia del FBI, y dado que la atacante pudo extraer credenciales de IAM de ese servidor, parece que después vulneraron una instancia EC2. Esto pudo deberse a una vulnerabilidad de la aplicación o del sistema operativo; simplemente no lo sabemos. Para mi simulación del ataque, supuse que la atacante obtuvo acceso al shell, pero no acceso root a la instancia, ya que para completar los pasos restantes basta con el acceso básico al shell.

Paso tres: acceso a S3 mediante un rol de IAM

..."Capital One determinó que, al ejecutarse, el primer comando obtuvo las credenciales de seguridad de una cuenta conocida como ***-WAF-Role, que a su vez permitía acceder a ciertas carpetas de Capital One en la empresa de computación en la nube. (III.A.11)"

Gran parte de la “acción” en esta filtración se produjo mediante el acceso con un rol de IAM a buckets privados de S3, aparentemente con comandos de AWS CLI ejecutados desde el servidor comprometido. La prensa ha prestado mucha atención al nombre del rol, pero no hay pruebas concluyentes de que ese servidor fuera un WAF. Es común “reutilizar” roles de IAM en entornos dinámicos de AWS (no es una práctica recomendable, pero sí común). Además, como veremos más adelante, las asociaciones de políticas pueden cambiarse y a menudo incluyen “Role” en el nombre, como en el ejemplo a continuación. Quizás este servidor simplemente había quedado olvidado, sin etiquetas que lo mostraran en los paneles de las herramientas de administración. Rara vez he visto una cuenta de AWS grande sin recursos huérfanos dispersos por ahí.

Si el servidor era un WAF y tenía intencionalmente acceso de lectura y escritura a buckets y objetos con datos de identificación personal (PII), esa era una estrategia de defensa ingenua por razones obvias; en particular, porque una sola configuración incorrecta del firewall habría podido sortear todas las defensas arquitectónicas de los datos confidenciales. Sin embargo, esta no es la única explicación de la filtración y sospecho que hubo algo más: el uso de funciones de IAM y EC2 diseñadas para ofrecer flexibilidad, pero que podrían haberse utilizado indebidamente para otorgar privilegios adicionales.

Como describen el “primer comando”, creo que es razonable suponer que se refieren a un script de AWS CLI. Si la instancia EC2 ya tenía acceso a S3, la atacante solo habría tenido que ejecutar algo como esto:

> curl http://169.254.169.254/latest/meta-data/iam/security-credentials/DemonstrationEC2Role

Este comando recupera las credenciales temporales actuales de IAM del rol desde los metadatos de la instancia EC2. El resultado se ve así:

{

  "Code" : "Success",

  "LastUpdated" : "2019-07-31T19:41:16Z",

  "Type" : "AWS-HMAC",

  "AccessKeyId" : "***************",

  "SecretAccessKey" : "**************************",

  "Token" : "AgoJb3JpZ2luX2VjEDQaCXVzLWVhc3QtMiJGMEQCIG9qFNkzROR8KaLKTTxaWYpxuE1J8ogMUWLF6EhddivjAiB84nwhPoUQl4IIWb5oGfXjc3QzRTP7nm/fG8ANqGnrJyrjAwit//////////Hpraage6UuR7XmrrdM09c9thue+fbUjYYGFHtiun96KrcDeZrJXwV/Dj8+pbn2Ivw0UydaC7Jj+XUkr8izWG7h/Hpraage6UuR7XmrrdM09c9thue++IaAjZPsutjIhkDEuggqriQCdA/4QwHgXFAjs0VzgFly9l29EVWMzvIncKQEIGFxofqwhMcOpN4uP7wseMctpqVfUfjumC/EisdYFUo8UaDctYObXBCk8tL/HvvMmJrF0aDYmcsaQ8Geu67X9LQk45xr/Hpraage6UuR7XmrrdM09c9thue+qy0evQBJbqmfrhg1bZktctodqOkngdyFN/CYDu3jVIyiLxH/3PmGedzkjJ+julYzunhj9i8V5ej4UIyGDU2KOORaRosLM+lFDJSZDfiihWvfXYYDDJkLX+tJel9qFYTqDcppVTcIjJO8yJQOYRBAvk32nu1mdkQMmafl+CwxMfppbsrja9c6A/c16tv/WcPrCzmJiu6yqbk+4QwHgXFAjs0VzgFly9l29EVWMzvIncKQEIGFxofqwhMcOpN4uP7wseMctpqVfUfjumC+Hpraage6UuR7XmrrdM09c9thue/9ZmdktOg6HAtI89GOP10OE2gJ0Pq4Er/+hUh/+LOmi3QSoALCitT2d09o/iCcXY/zzCT3ofqBTq1AQ5XbIYPbAZiKVyquo2M6EYqiODBNsSQLiMBJgZldv8LOhYOgIxz302gTBvSr7zl2vWrm5gEr9twKx1ApMkaMY0h1kNTgwTsBHm9hVdvidN3QhBzt3s7u2nvcGx5r+dWDkTQ3BI6fD31tdDKOtm7fZO9ziSgFu8U3o3ncAytioWYGXXtZN2FLzBtqp+mq6E8gc1lZnoCGkGApXltdJVSC2+tkXQJLYyF1Ubd00GH+QV8cxE/zr4=",

  "Expiration" : "2019-08-01T02:17:11Z"

}

Where the access key and secret access key are replaced with *'s and the token corrupted to protect the innocent.

Eso sería todo lo necesario para acceder a los buckets de S3 y su contenido.

Pero hay otra posibilidad sobre lo que hacía ese “primer comando”, y toda persona que use AWS debe conocerla. Si el servidor comprometido no tenía acceso a los buckets privados de S3, pero sí permisos para enumerar y asociar políticas de IAM, la atacante podría haber usado esas capacidades para buscar credenciales que le dieran ese acceso. Como los permisos de IAM suelen no tener relación con los controles de acceso de red basados en IP, y los servicios de AWS se conectan mediante IAM, estos roles y políticas forman una especie de red alternativa que debe protegerse igual que una red tradicional. IAM se convierte en un medio principal de “movimiento lateral” dentro del entorno en la nube.

El siguiente comando, por ejemplo, reemplaza un conjunto de permisos de IAM por otro:

> aws ec2 replace-iam-instance-profile-association --association-id iip-assoc-00facaf2870f3bcc9 --iam-instance-profile Name=DemonstrationEC2Role

Esto devuelve el resultado a continuación y muestra que reemplacé correctamente los permisos de IAM existentes por los de la política DemonstrationEC2Role:

{

    "IamInstanceProfileAssociation": {

        "InstanceId": "i-0f566edb3389ac1f7",

        "State": "associated",

        "AssociationId": "iip-assoc-00facaf2870f3bcc9",

        "IamInstanceProfile": {

            "Id": "AIPA6MYZKKFJL2Y2G5UPO",

            "Arn": "arn:aws:iam::989506195794:instance-profile/DemonstrationEC2Role"

        }

    }

}

Otros comandos útiles para una búsqueda de este tipo incluyen:

> aws iam list-roles

> aws iam list-policies

> aws iam list-instance-profiles

Hacen exactamente lo que indican: enumeran el catálogo de recursos de IAM disponibles que un atacante podría querer usar una vez que obtiene acceso al shell de una instancia EC2.

En este ejemplo, reemplacé un perfil de IAM limitado por otro con permisos adicionales para S3. No podemos descartar que la atacante haya empleado un enfoque similar en la filtración de Capital One. Independientemente de si fue así o no, es fundamental tener presente esta capacidad al configurar roles de IAM para las instancias EC2, sobre todo las de acceso público, ya que los permisos de IAM pueden “saltar” de forma efectiva a los recursos privados del entorno.

En cualquiera de los dos escenarios, el atacante obtuvo las credenciales necesarias para recuperar información de S3 y duplicarla.

Paso cuatro: descubrimiento y duplicación de buckets de S3

"Capital One determinó que, al ejecutarse, el tercer comando (el “comando Sync”) usó ***-WAF-Role para extraer o copiar datos de las carpetas o los buckets del espacio de almacenamiento de Capital One para los que la cuenta ***-WAF-Role tenía los permisos necesarios. (III.A.11)"

Esto sugiere que se usó el comando de AWS CLI `aws s3 sync`, así que creo que es una prueba más de que la atacante obtuvo acceso al shell de la instancia EC2 y usó AWS CLI para ejecutar estos comandos. Según la denuncia del Departamento de Justicia, la atacante enumeró los buckets de S3 con el segundo comando. Esto sugiere que el rol de IAM que usó tenía permisos tanto para enumerar como para leer en S3. Esto pone de relieve el peligro de que un solo rol de IAM tenga permisos tan amplios para S3: incluso en ese punto, sin la capacidad de descubrir los buckets objetivo, probablemente la atacante no habría podido capturar muchos datos, si acaso alguno.

Recomendaciones

1. Monitorea constantemente los grupos de seguridad demasiado permisivos y cualquier otro mecanismo de acceso desde 0.0.0.0/0. Revisar el aprovisionamiento es necesario, pero no basta ni de lejos. La infraestructura en la nube se crea y modifica mediante API, lo que significa que suele desviarse de la configuración prevista con el tiempo, a medida que distintos equipos y personas interactúan con ella.

2. Aplica el principio de privilegio mínimo y limita estrictamente los roles de IAM a lo absolutamente necesario para la función de negocio del recurso que los usa. En el caso de S3, podrías considerar distintos puntos de acceso públicos para las operaciones de lectura y escritura, con diferentes roles de IAM que no puedan realizar la otra función. Elimina todos los casos de uso de producción que permitan enumerar buckets de S3 y opta por secretos compartidos u otros mecanismos.

3. No permitas que las instancias EC2 tengan roles de IAM que permitan asociar o reemplazar políticas de roles en entornos de producción.

4. Elimina rigurosamente los recursos de nube que no se usen, en especial los servidores y buckets de S3 que quedaron de trabajos anteriores de desarrollo o depuración en producción.

5. Incluye las configuraciones incorrectas de la infraestructura en la nube en tus pruebas de penetración. Contrata especialistas externos para estas pruebas y asegúrate de que sepan cómo encontrar y aprovechar las configuraciones incorrectas en la nube.