ACTUALIZACIÓN: Este post ha sido actualizado para reflejar la nueva información aprendida en colaboración con los equipos de AWS S3 Replication, CloudTrail y Security.
Una estrategia integral de copias de seguridad es la piedra angular de cualquier plan de recuperación ante desastres. Pero, ¿cómo distinguir entre una actividad de copia de seguridad legítima y una filtración de datos maliciosa?
Los ciberatacantes tienen cada vez más acceso a los planos de control de cloud , que incluyen capacidades para realizar copias de seguridad cloud. Aquí mostraré cómo se pueden aprovechar estas herramientas para filtrar datos del entorno de producción de una organización.
En este blog, verá de cerca cómo un atacante puede abusar de S3 Replication para migrar eficientemente sus datos fuera de su entorno. Espero que lo encuentres tan entretenido de leer como lo fue crearlo.
Verá cómo se desarrolla este ataque en distintos arcos narrativos desde la perspectiva de cuatro actores diferentes que se enumeran a continuación.
- El servicio de replicación de S3ya que sigue benignamente las órdenes dictadas como reglas de replicación para replicar los datos de S3 entre buckets.
- El malvado servicio de replicación S3ya que se abusa de sus poderes para copiar datos a ubicaciones externas.
- El atacante que se hace con el control del Servicio de Replicación S3, cooptando el servicio para el mal y utilizando su falta de registro para pasar desapercibido.
- Miembros del equipo SOC (centros de operaciones de seguridad) que se enteran de que están parcialmente ciegos al movimiento de datos a través del Servicio de Replicación S3, pero que ahora pueden cambiar su estrategia de detección para compensar.
Presentación del Servicio de Replicación S3, sus capacidades y casos de uso para bien
El servicio AWS S3 ya no es el "Simple Storage Service" que se presentó como tal. Con docenas de características e integraciones, se ha convertido en el almacén de datos preferido por los clientes empresariales de AWS. Además, es tan complicado que resulta difícil comprender y, por tanto, asegurar todas sus capacidades. Una de las numerosas características de S3 es la capacidad de copiar datos entre regiones y cuentas creando copias de seguridad activas de tus datos.
Como puedes ver en este post, esta función es propicia para el abuso y puede ser difícil de controlar.
El Servicio de Replicación en AWS hace exactamente lo que podrías pensar, cuando se dirige con reglas, copiará datos de S3 entre buckets.
El servicio recibe órdenes de las reglas de replicación. Puede configurar Reglas para indicar al servicio que copie datos en varios buckets, creando varias réplicas del mismo objeto de origen.
Los cubos de destino ni siquiera tienen que estar en la misma región o la misma cuenta que el cubo de origen.
Sus capacidades de replicación de datos sólo son posibles si al Servicio se le conceden permisos para ello. Para habilitar el Servicio de replicación de S3, debe configurarlo para que asuma un rol de IAM al que se le concedan permisos de IAM para acceder a los buckets de origen y de destino.
¿Cuáles son las consecuencias si un atacante obtiene la capacidad de utilizar S3 Replication en AWS?
La replicación entre cuentas puede ayudar a las organizaciones a recuperarse de una pérdida de datos. Sin embargo, en las manos equivocadas, el servicio de replicación permite a los actores de amenazas desviar datos a ubicaciones no fiables.
El Servicio de Replicación S3 tiene un alto potencial de abuso y, como resultado, es un objetivo principal para los atacantes.
Si un atacante obtuviera la capacidad de crear reglas de replicación, podría dirigir el servicio de replicación de S3 para copiar datos a su cubo externo controlado por el atacante. Incluso uno que resida fuera de la organización de AWS de las víctimas.
¿Qué permisos IAM son necesarios para replicar externamente?
El servicio de replicación de S3 requiere permisos en los objetos de S3 tanto para obtener el objeto del bucket de origen como para replicar el objeto en el bucket externo controlado por el atacante.
A continuación se muestra un ejemplo de una política de IAM que define las acciones necesarias para la replicación, pero se olvida de alcance de los permisos a un recurso, dejando el campo de recursos como "*". Esta política es tan permisiva que permitiría al Servicio de Replicación S3 copiar objetos en cualquier bucket, incluso fuera de su cuenta.
Dada una política excesivamente permisiva, un atacante necesitaría la capacidad de actualizar las reglas de replicación, ordenando al Servicio de Replicación que copie los datos a un bucket controlado por el atacante. No se requieren permisos sobre los objetos en sí, sólo la capacidad de actualizar las reglas.
En resumen: en lugar de copiar o mover datos directamente desde una cuenta, un atacante puede aprovechar el servicio de replicación de S3 para realizar esas mismas acciones en su nombre, como resultado de una regla de replicación maliciosa. No se trata de un error que pueda remediarse, sino de un tipo de vulnerabilidad cloud denominada "abuso de funciones".
¿Cómo registra sus actividades el Servicio de Replicación S3? Y cómo ayuda eso a un atacante a pasar desapercibido?
El movimiento autorizado de datos a través del servicio de replicación S3 es poco transparente, lo que dificulta especialmente la caza de la exfiltración de datos, permitiendo a un atacante ocultar su actividad a plena vista dentro de su entorno cloud .
Veamos cuándo y dónde el Servicio de Replicación escribe eventos en CloudTrail basándose en las configuraciones de su plano de datos.
Para obtener visibilidad de los eventos que afectan a los objetos de S3, es necesario optar por la recopilación de eventos de datos de S3. El alcance de estos eventos puede configurarse para incluir "Todos los buckets de S3 actuales y futuros" o pueden enumerarse buckets individuales. Esta configuración de CloudTrail sirve como mecanismo de filtrado para incluir cubos específicos en el registro del plano de datos de S3.
Cuando los datos son copiados por el Servicio de Replicación S3 se produce un evento GetObject ya que el servicio coge el objeto al replicar. Este evento se escribe en el CloudTrail de la cuenta de origen.
Tras el evento GetObject, el evento PutObject, que revela el bucket de destino, se registra tanto en la Cuenta de Destino Externa como en la Cuenta de Origen.
¿Cuál es el comportamiento del registro en el plano de datos de CloudTrail S3 si los registros están limitados a buckets específicos?
Para controlar los costes, las organizaciones suelen habilitar los registros del plano de datos de S3 únicamente en sus buckets de alto valor, en lugar de pagar por el registro en "todos los buckets actuales y futuros". Cómo cambia esta configuración de registro la visibilidad del servicio de replicación de S3?
Tras el evento GetObject , podría registrarse un evento PutObject en la cuenta de destino de acuerdo con la configuración de CloudTrail de la cuenta de destino. En particular, no se registrará ningún evento PutObject en la cuenta de origen.
Lo que esto significa en la práctica es que, a medida que los datos son copiados por el Servicio de Replicación, no hay ningún registro en el CloudTrail de la Cuenta de Origen que revele el bucket de destino externo.
Cuando CloudTrail está configurado para capturar eventos del plano de datos de S3 desde buckets específicos de la cuenta de origen, existe una brecha en el registro, lo que permite la copia de datos sin registrar el evento del plano de datos, PutObject, en la cuenta de origen.
Sin el alcance de los registros de los planos de datos para incluir los registros de todos los buckets actuales y futuros, un atacante podría actualizar las reglas de replicación para replicar objetos en su bucket externo: siéntese y relájese mientras el servicio de replicación mueve silenciosamente los datos fuera de una organización.
Afortunadamente, los controles preventivos son claros.
Como siempre, cuando defina las políticas de identidad de AWS IAM, no deje el campo de recurso en blanco permitiendo que los permisos de la política se apliquen a cualquier política. Asegúrese de que la función de IAM que asume el servicio de replicación enumera explícitamente los buckets en los que puede operar.
¿Cuáles son las consecuencias para los defensores de cloud ?
Los cazadores de amenazas pueden utilizar la actualización maliciosa de las reglas de replicación como una pista de que la exfiltración de datos puede estar ocurriendo silenciosamente en su entorno.
Teniendo en cuenta lo prevenible que es el abuso del servicio de replicación S3 y por qué esta falta de visibilidad importa a los cazadores de amenazas y defensores de cloud del mundo?
Para ver por qué son importantes estas incoherencias de registro, tenemos que hablar de la misión del defensor en una organización. Los defensores de Cloud cloud están continuamente haciendo preguntas sobre el entorno de cloud en busca de indicadores de compromiso. Su trabajo consiste en detectar cuándo las cosas se tuercen, a pesar de los esfuerzos de las medidas preventivas.
El pan de cada día de los defensores son los registros que utilizan para elaborar detecciones que proporcionen señales de alerta temprana de que los datos se están moviendo desde el perímetro. Los registros del plano de datos disponibles para los defensores pueden limitarse únicamente a los buckets conocidos y de alto valor para abordar los problemas de costes y reducir el enorme volumen de registros del plano de datos que pueden generarse al capturarlos todos.
Si los datos pueden copiarse sin que se registre el bucket de destino, los defensores no pueden alertar de forma exhaustiva ni buscar la exfiltración de datos buscando buckets defectuosos en eventos del plano de datos como los eventos CopyObject o PutObject.
Los defensores necesitan ampliar los eventos que supervisan para incluir la actualización de las reglas de replicación, de modo que puedan asegurarse de que están supervisando exhaustivamente su perímetro de datos.
Si un SOC no puede imponer el registro en el plano de datos de S3 en "todos los buckets actuales y futuros", la supervisión y alerta del evento PutBucketReplication es el único lugar en el que un defensor tendrá visibilidad de los buckets de destino externos. Este evento no indica que se hayan copiado datos, sino que el servicio de replicación tiene una regla configurada para copiar datos.
Lecciones aprendidas al abusar del Servicio de Replicación
El servicio de replicación de S3 puede utilizarse para ayudar a las organizaciones a ser más resistentes al ransomware, pero es importante que, al construir nuestro modelo de amenazas, elaboremos historias de usuarios malvados que nos ayuden a ver las capacidades de cloud desde el punto de vista de un atacante.
Debido al coste, una organización típica podría dudar en habilitar el registro en el plano de datos de S3 en todos los buckets de una cuenta, prefiriendo capturar selectivamente los registros solo en los buckets de alto valor. Como hemos visto, esa estrategia dará lugar a una brecha en la visibilidad de la exfiltración de S3, ya que el evento PutObject no se escribirá en la cuenta de origen.
En agosto de 2022, AWS se había negado a solucionar el problema de registro con el servicio S3 Replication. Al tratar este asunto con AWS, se han propuesto las siguientes soluciones o "solicitudes de funciones".
- Incluir el cubo de destino en el evento GetObject
- Preferiblemente, considere los eventos GetObject y PutObject como pares - escribiendo estos dos eventos en la cuenta de origen como resultado del filtro de ámbito del bucket de origen en lugar de considerar el ámbito de registro del plano de datos del bucket de destino.
Calendario de presentación de informes
10/19/21
[Vectra]: Informe inicial de vulnerabilidad enviado, y acuse de recibo el mismo día.
10/20/21
[AWS]: Respondieron indicando que no creen que se trate de una vulnerabilidad:
"No creemos que el comportamiento que describe en este informe suponga un problema de seguridad, más bien se trata de un comportamiento esperado. Ofrecemos alarmas CloudWatch que registrarán cualquier cambio realizado en la política de replicación de un bucket [1], lo que daría visibilidad sobre el destino de los datos para el modelo de amenaza descrito. Véase la sección que detalla "S3BucketChangesAlarm".
10/20/21
[Vectra]: Solicito confirmación de que AWS no considera la falta de registro como una vulnerabilidad. Indicado que describiré la respuesta de AWS a este informe como "no se solucionará" en cualquier divulgación pública.
10/26/21
[AWS]: AWS preguntó dónde publicaría la divulgación y si podían tener una copia anticipada del texto.
10/26/21
[Vectra]: Reconocieron que podían recibir una copia anticipada de cualquier divulgación pública.
2/2/22
[Vectra]: Reenviado el informe de vulnerabilidad original a un contacto interno del equipo de Seguridad de AWS sugiriendo que soliciten un registro mejorado en el servicio de replicación S3.
2/3/22
[AWS]: Reconoció que pusieron el ticket internamente.
7/20/22
[Vectra]: Publicada la investigación inicial sobre el tema que describía el problema de registro como algo que sólo ocurría cuando el Control de Tiempo de Replicación (RTC) estaba activado.
7/25/22
[Vectra]: Comprobados de nuevo los hallazgos para descubrir una falta de registro que ocurre con o sin RTC activado.
7/26/22
[Vectra]: Resultados presentados en fwd:cloudSec
8/18/22
[Vectra y AWS]: Reunión para discutir los resultados. En esta reunión se entendió que el filtro de alcance del plano de datos de CloudTrail S3 es el mecanismo que controla si un evento PutObject se escribe o no en la cuenta de origen.
[1] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf