Ataques de ransomware VS seguridad en Amazon S3

El pasado 10 de febrero, Amazon Web Services actualizó su ebook sobre medidas de protección en su servicio de almacenamiento, Amazon S3. Considerando el auge de los ataques de ransomware contra empresas y que cada vez son más las que comienzan a migrar su servicios a la nube, hoy os traemos una publicación en la que analizamos las causas principales de estos ataques y cómo proteger nuestros recursos.

El equipo de seguridad de Orca, en base a los datos de su propia plataforma, indicaba el pasado 2 de marzo que suele tardarse alrededor de 91 días en solventar problemas relacionados con malware en sistemas de almacenamiento en la nube. A pesar de que no se puede ejecutar malware en un bucket, se debe tener en cuenta que un bucket es un tipo de instancia utilizada por un amplio rango de usuarios y recursos, por lo que su impacto se puede ver multiplicado.

Los datos de la plataforma de Orca indican que los tipos de malware detectados principalmente en buckets son troyanos y scripts que tienen como objetivo explotar CVEs, con un porcentaje muy pequeño de webshells.

Según informa el Equipo de Respuesta ante Incidentes de Clientes de AWS (CIRT, por sus siglas en inglés), las prácticas que de manera más común derivan en ataques de ransomware en Amazon S3 son:

Claves de acceso de IAM filtradas accidentalmente.
Vulnerabilidades en aplicaciones desplegadas en Amazon EC2 con credenciales IAM asociadas y el servicio de metadatos IMDSv1 activo. El uso de IMDSv1 puede dar lugar a ataques SSRF, lo cual puede quedar significativamente mitigado haciendo uso de IMDSv2 (aunque bajo ningún concepto se debe pensar que habilitar la segunda versión de IMDS protege nuestros recursos en su totalidad; siempre ha de tenerse en cuenta el modelo de responsabilidad compartida).

Entre las dos causas principales mencionadas, la más frecuente es la filtración de claves de acceso del servicio IAM.

Tras obtener el par de claves IAM, lo primero que un atacante suele hacer es comprobar qué tipo de permisos tiene asociados mediante llamadas a distintas API de AWS. Estas llamadas generan un tipo de actividad que pueden ayudar en la detección del ataque, y en los casos en los que el objetivo del atacante sea utilizar Amazon S3 para ataques de ransomware, dichas llamadas se harán al servicio en cuestión, pudiendo observarse un incremento en las siguientes de manera concreta:

s3:ListBuckets
s3:GetBucketLocation
s3:GetBucketPolicy
s3:GetBucketAcl

Cuando se dan este tipo de ataques, se pueden observar eventos que pueden ser poco comunes en nuestro entorno, como la eliminación de objetos en los buckets o el cifrado de dichos objetos. AWS ofrece diversos servicios que permiten detectar estos incidentes, entre los cuales se encuentran:

AWS CloudTrail
Métricas de AWS CloudWatch para Amazon S3
Métrica «region-DataTransfer-Out-Bytes»

En lo que se refiere a acciones de respuesta, se puede optar por crear un segundo par de claves para reemplazar el uso de aquellas que han sido filtradas para que la producción de los sistemas asociados no se vea interrumpida, pudiendo así desactivar las claves comprometidas. Si las credenciales filtradas son temporales, también será necesario revocar las sesiones activas. Además, es recomendable crear una documentación que sirva de orientación a los equipos involucrados para responder ante este tipo de eventos. Las acciones de respuesta ante incidentes se pueden automatizar en muchos de los casos haciendo uso de servicios como Amazon EventBridge y AWS Lambda.

Junto a dicha documentación sobre los procedimientos de respuesta, AWS recomienda llevar a cabo simulaciones de respuesta ante incidentes que preparen al equipo de cara a un ataque real, de manera que se puedan validar los procesos existentes y saber si es necesario mejorarlos.

Pasando a la recuperación de información, para que un ataque de ransomware tenga éxito, el atacante debe ser capaz no solo de cifrar los datos, sino de bloquear el acceso a los mismos (sin cifrar) al usuario legítimo, por lo que lo primero que tenemos que hacer es proteger nuestra cuenta de AWS asegurándonos de que tenemos la posibilidad de recuperar la información perdida.

No obstante, antes de entrar en detalle sobre cuáles son las soluciones ofrecidas por AWS, se deben tener en cuenta dos aspectos fundamentales. El primero de ellos es que AWS no tiene la capacidad de recuperar la información que ha sido borrada; el segundo, que muchas de estas funcionalidades requieren configuración adicional del bucket cuando éste se crea. Dos opciones de recuperación de datos que destacan son:

Versionado de buckets: esta opción permitirá mantener varias opciones de un objeto en un mismo bucket, lo que nos da la posibilidad de restaurar aquellos elementos que necesitemos. El versionado de los objetos no está habilitado por defecto y puede suponer costes adicionales.
AWS Backup: permite crear y mantener copias separadas de la información almacenada en los buckets, protegidas por credenciales de acceso diferentes. Este servicio proporciona copias de seguridad centralizadas para otros servicios de AWS y de manera concreta para Amazon S3, proporciona la posibilidad de crear copias de seguridad continuas y/o periódicas.

Otra alternativa, esta más enfocada a las operaciones de DR en aplicaciones tanto on-premise como en la nube y no de manera tan específica a ataques de ransomware en Amazon S3, es Elastic Disaster Recovery. Sin entrar en mucho detalle ya que se sale un poco del alcance de esta publicación, de manera muy resumida este servicio de AWS permite aumentar la resiliencia de nuestras aplicaciones, minimizando la pérdida de información ante incidentes. En el apartado de referencias podréis encontrar el enlace a la documentación de este servicio, para quienes estéis más interesados.

Las opciones de protección son un poco más variadas, contando con:

S3 Object Lock: permite almacenar objetos usando el modelo WORM (write-once-read-many).
AWS Backup Vault Lock: habilita el modelo WORM en las copias de seguridad que se almacenan y crean en el servicio.
Amazon S3 Inventory: idealmente se debe utilizar para mantener un inventario de la información que resulte más crítica y/o más sensible. Además de mantener dicho inventario, permite conocer las configuraciones aplicadas, como por ejemplo si el cifrado de datos está habilitado.
MFA delete: se trata de una configuración que hace que al usuario que vaya a eliminar un objeto de un bucket se le solicite un doble factor de autenticación.
Uso de roles IAM para credenciales temporales: se trata de la recomendación de AWS frente a la alternativa consistente en el uso de credenciales de largo plazo. Adicionalmente, es aconsejable realizar un seguimiento de aquellos usuarios con claves de acceso estáticas. También es posible realizar una reestructuración de los procesos de acceso que necesiten credenciales estáticas en lugar de roles. En los casos en los que se necesiten credenciales estáticas, el proceso de autenticación debe estar protegido mediante MFA, además de contar con una política que establezca la rotación de credenciales de manera frecuente.
Cifrado del lado del servidor con claves KMS administradas por el cliente: el uso de este tipo de cifrado implica la aplicación de una política de claves concreta acerca de quién puede cifrar y descifrar información en un bucket, pudiendo además llevar un control sobre quién y cuándo se ha hecho uso de la clave en cuestión.

Al principio de esta publicación también mencionábamos que otra de las causas principales de ataques de ransomware en Amazon S3 es la existencia de vulnerabilidades en aplicaciones desplegadas en instancias EC2. La aplicación de parches que solventen las vulnerabilidades que van apareciendo de forma continua y que pueden afectar a nuestros sistemas puede llegar a ser algo tedioso, dando lugar a que el remediarlas se vaya alargando indefinidamente en el tiempo y otorgando así la posibilidad a un potencial atacante de ganar acceso a nuestra infraestructura.

Este proceso manual lo podemos evitar haciendo uso de AWS Systems Manager, un servicio que nos permite automatizar el proceso tanto en la infraestructura que tengamos en la nube como física. Systems Manager se puede utilizar en conjunto con Amazon Inspector para llevar a cabo dicha automatización; Inspector, por su parte, realizará escaneos continuos sobre los recursos de AWS para detectar vulnerabilidades, y una vez detectadas, Systems Manager desplegará los parches de manera automática sobre los recursos.

Asimismo, para proteger nuestros recursos también puede ayudar el seguir un estándar de seguridad. Esto, además de mejorar el nivel de seguridad de nuestra infraestructura, también mejorará nuestra posición frente a regulaciones nacionales y/o internacionales a las cuales deba acogerse la empresa, como por ejemplo el ENS o PCI DSS. En lo que a protección frente a ataques de ransomware se refiere, AWS recomienda el framework «Ransomware Risk Management: A Cybersecurity Framework Profile» del NIST, sobre lo que encontraréis información más detallada en el apartado de referencias de esta publicación.

Otra forma de proteger nuestra infraestructura en la nube es el uso de un diseño estándar en AWS VPC. Planear y administrar cuidadosamente nuestra infraestructura de red será lo que proporcione el aislamiento y los límites necesarios a nuestras cargas de trabajo para que se vean lo bastante protegidas frente a ataques de ransomware. Por ejemplo, es recomendable usar el mismo número de zonas de disponibilidad (AZ) y subredes públicas y privadas en cada AZ con listas de control de acceso de red (NACL) comunes. Dentro de este paraguas cae el uso de múltiples cuentas de AWS (en lugar de una sola), AWS Firewall Manager, y Route 53 Resolver DNS Firewall (este último para regular el tráfico DNS de salida basado en una lista de dominios administrados que es actualizada de manera periódica con nuevas vulnerabilidades y amenazas emergentes).

Para aquellos usuarios que sean nuevos en los entornos de AWS, o incluso para quienes ya lleven trabajando algún tiempo con infraestructuras en la nube pero les resulte complicada la aplicación de las medidas mencionadas en esta publicación para enfrentarse a ataques de ransomware en Amazon S3, quizás lo más recomendable sea comenzar por una arquitectura básica de seguridad en AWS, para lo que existe una plantilla de AWS CloudFormation para facilitar la tarea. La estructura del flujo de trabajo al desplegar la plantilla se puede observar en el siguiente diagrama:

Guía para una evaluación de seguridad base en AWS
Fuente: documentación oficial de AWS

Los pasos que se siguen en el diagrama anterior son:

El usuario instala la plantilla de AWS CloudFormation. Esta plantilla despliega una función Lambda junto al rol IAM necesario para dicha función.
La función Lambda despliega el recurso personalizado AWS Well-Architected.
Asimismo, la función Lambda comprueba si:
- AWS Secrets Manager se está utilizando para almacenar y administrar el ciclo de vida de los secretos.
- AWS Systems Manager Patch Manager se está usando para aplicar parches.
- Amazon CloudFront se está utilizando para la entrega de contenido estático.
- Amazon VPC está configurado de manera correcta para que las redes sean seguras y estén aisladas.
- AWS Cost Explorer tiene configurada alarmas de facturación.
- AWS Cost Anomaly Detection está configurado.
- Amazon S3 está configurado de manera correcta para evitar el acceso público.
Las cuestiones planteadas por AWS Well-Architected son abordadas por la función Lambda para completar la evaluación automatizada.
El usuario adquiere el reporte de la evaluación en la consola de AWS Well-Architected.

Más información:

La entrada Ataques de ransomware VS seguridad en Amazon S3 se publicó primero en Una al Día.