Filtraciones de AWS de alto perfil y cómo evitarlas

Unos días antes de Navidad de 2021, los empleados y clientes del servicio de programación de citas Flexbooker se dieron cuenta de que unos atacantes habían robado diez millones de registros de identificación de clientes, incluidas fotos, licencias de conducir y contraseñas cifradas con hash. 

Los atacantes robaron millones de datos de identificación personal (PII) porque Flexbooker había configurado incorrectamente su cuenta de AWS, específicamente un bucket de AWS S3 cuyo contenido quedó expuesto al público. Esta filtración de AWS fue noticia, pero no porque fuera algo nuevo.  Capital One, Twilio, Uber y otras empresas también han sufrido filtraciones relacionadas con AWS. En estos casos, los atacantes no vulneraron AWS en sí, sino que vulneraron a una empresa aprovechando una configuración incorrecta de AWS.

A pesar de la magnitud de estas filtraciones, la causa principal de los problemas de seguridad en la nube suele ser la misma: las configuraciones incorrectas. La seguridad en la nube se basa en un modelo de responsabilidad compartida: el proveedor protege la infraestructura, pero el cliente debe implementar sus aplicaciones de forma segura en todos los entornos, no solo en producción. En la mayoría de los casos, errores de configuración simples en las aplicaciones o servicios implementados dejan brechas lo suficientemente grandes como para que ocurra una filtración.

En este artículo, explicaremos algunas de las filtraciones de seguridad de AWS de alto perfil que ocurrieron en los últimos años debido a configuraciones incorrectas y veremos cómo puedes prevenir las filtraciones con mejores prácticas de seguridad. 

Capital One: un firewall mal configurado afecta a 100 millones de clientes 

En julio de 2019, Capital One, un importante banco y proveedor de servicios financieros, reveló que un exempleado de Amazon había hackeado sus servidores de AWS. 

El hackeo afectó a más de 100 millones de clientes y expuso datos de identificación personal, como números del Seguro Social, números de cuentas bancarias, puntajes crediticios y más. Amazon dejó claro que AWS no tuvo la culpa y que los servicios de nube subyacentes no se vieron comprometidos. En cambio, como admitió Capital One, el atacante obtuvo acceso mediante un firewall de aplicaciones web (WAF) de código abierto mal configurado. 

Los clientes presentaron una demanda colectiva que Capital One resolvió, con un pago de hasta $25,000 por reclamo. Los demandantes argumentaron que Capital One "conocía las vulnerabilidades de seguridad específicas que permitieron la filtración de datos", pero no las corrigió. Capital One no estuvo de acuerdo ni en desacuerdo con la demanda; en su lugar, afirmó que llegaría a un acuerdo "para evitar el tiempo, los gastos y la incertidumbre de continuar con el litigio".

Pegasus Airlines: un bucket S3 desprotegido expone 6.5 terabytes de datos

En mayo de 2022, Pegasus Airlines, una aerolínea turca, descubrió, gracias al trabajo de una empresa de seguridad, que había configurado incorrectamente un bucket de AWS S3. El bucket contenía datos confidenciales de vuelos, como mapas de vuelo, materiales de navegación e información de identificación personal de numerosos empleados. 

El bucket de S3 expuesto también reveló parte del código fuente de la empresa, que contenía contraseñas en texto plano y claves secretas. Los posibles atacantes podrían haber usado ambas para acceder a datos aún más confidenciales. 

En total, la empresa de seguridad encontró casi 23 millones de archivos expuestos, alrededor de 6.5 terabytes de datos. Señaló que “esta exposición podría afectar la seguridad de todos los pasajeros y miembros de la tripulación de Pegasus en todo el mundo”.

La empresa de seguridad notificó a Pegasus Airlines y, según la empresa, “el bucket de AWS S3 se protegió de inmediato y PegasusEFB respondió más tarde para agradecernos la notificación”.

Twilio: un bucket S3 expuesto permite a los atacantes inyectar código malicioso

En julio de 2020, Twilio, una empresa de comunicaciones en la nube, confirmó que unos atacantes habían accedido a un bucket S3 mal configurado y habían modificado el SDK de JavaScript de su herramienta TaskRouter. 

Los atacantes aprovecharon una configuración incorrecta en el bucket S3 que alojaba la biblioteca del SDK de TaskRouter para JS de Twilio (TaskRouter es una herramienta que los clientes de Twilio pueden usar para enrutar tareas). Tras el ataque, la biblioteca modificada hacía que los navegadores cargaran una URL adicional, que más adelante se relacionó con los infames ataques Magecart. 

Twilio explicó en una divulgación que corrigió el incidente en quince minutos y volvió a configurar el bucket S3 una hora después. Además, Twilio afirmó que los atacantes no accedieron a los datos de los clientes ni a los sistemas internos. 

Twilio fue transparente y explicó: “No habíamos configurado correctamente la política de acceso de uno de nuestros buckets de AWS S3”. Twilio implementó esta ruta en particular en 2015 y, en ese momento, no era vulnerable. Sin embargo, unos meses después, la empresa explicó que no había “restablecido correctamente” los permisos tras solucionar un problema. 

Uber: una autenticación débil expuso claves secretas que dieron a los hackers acceso a almacenes de datos de AWS S3 con registros de 600,000 conductores de EE. UU.

En noviembre de 2017, Uber, una empresa de transporte compartido, reveló que unos atacantes habían robado, en 2016, la información personal de más de 50 millones de pasajeros y conductores, además de registros de 600,000 conductores de EE. UU. que incluían sus números de licencia.

Los atacantes pudieron acceder al repositorio de GitHub de Uber porque la empresa no había habilitado la autenticación multifactor. A pesar de la falta de seguridad, estos repositorios contenían credenciales importantes de AWS y, con ellas, los atacantes pudieron acceder a los almacenes de datos de AWS S3 de Uber. 

Uber explicó que protegió los datos, detuvo el acceso no autorizado, convenció a los atacantes de que eliminaran los datos y reforzó los controles de sus cuentas de almacenamiento en la nube. Sin embargo, informes posteriores revelaron que Uber había disfrazado el hackeo inicial como un programa de recompensas por errores exitoso y había pagado $100,000 a los atacantes para que guardaran silencio. 

Imperva: una clave de API de AWS expuesta permite a los atacantes acceder a una base de datos con direcciones de correo electrónico y contraseñas de clientes

En octubre de 2019, Imperva, un proveedor de ciberseguridad, reveló que unos atacantes habían robado datos de clientes al explotar una instancia de AWS mal configurada.

El director ejecutivo de Imperva explicó que los atacantes usaron una clave de API administrativa que encontraron en una de las cuentas de AWS de la empresa para acceder a una instantánea de una base de datos con direcciones de correo electrónico y contraseñas. 

Imperva fue transparente sobre los errores que provocaron la filtración de seguridad de AWS y explicó que cuatro pasos principales llevaron finalmente a la exposición de los datos de clientes:

1. Imperva creó una instantánea de una base de datos para hacer pruebas mientras evaluaba AWS.

2. Imperva dejó una instancia de cómputo interna accesible al público, aunque contenía una clave de API de AWS.

3. Los atacantes vulneraron la instancia de cómputo y robaron la clave de API de AWS.

4. Los atacantes usaron la clave de API de AWS para acceder a la instantánea de la base de datos y a todos los datos que contenía. 

Desde entonces, la empresa ha tomado numerosas medidas correctivas, como reforzar los controles de acceso de seguridad e implementar auditorías de acceso. 

Tres lecciones aprendidas de las filtraciones de datos de AWS

Puedes aplicar algunas lecciones de estas filtraciones de AWS para que tu empresa use AWS de forma más segura:

1. Conoce tu entorno: Muchas filtraciones de AWS ocurren por errores de configuración. Cuanto mejor conozcas y audites tu entorno, menos probable será que haya una configuración incorrecta que los atacantes puedan explotar. 

2. Empodera a tus desarrolladores: Los desarrolladores están en la mejor posición para detectar y corregir errores de configuración. Las empresas pueden prevenir mejor las filtraciones de AWS si les dan a los desarrolladores las herramientas y la orientación para crear entornos seguros. 

3. Prioriza la prevención y el diseño seguro: Muchas de estas filtraciones de AWS podrían haberse evitado si las empresas afectadas se hubieran enfocado más en el diseño seguro. Con herramientas como el análisis de vulnerabilidades de AWS de Snyk, las empresas pueden identificar vulnerabilidades antes que los atacantes. Descubre cómo se integra Snyk con las herramientas de seguridad de AWS aquí.

Si quieres aprender más sobre la seguridad en la nube, descarga nuestro libro electrónico Los cinco fundamentos de la seguridad en la nube. Y si quieres saber más sobre cómo se integran Snyk y AWS, consulta la guía de inicio rápido de AWS.