Get best of the week

Por qué las nubes se convierten en nubes de tormenta: fallas en la implementación de la nube

imagen

Una implementación en la nube en una organización grande generalmente incluye muchos servicios de varios proveedores, cada uno de los cuales tiene sus propias reglas para la interacción, la configuración e incluso los protocolos. Como resultado, la configuración de seguridad se vuelve tan compleja que es difícil de rastrear y aún más difícil de entender. En nuestro nuevo estudio, recopilamos los errores más comunes al implementar una infraestructura en la nube utilizando Amazon Web Services como ejemplo, y compartiremos algunos de ellos en esta publicación.

Los proveedores de la nube ofrecen hoy servicios que van más allá de la trivial "dedicación" o almacenamiento de archivos. Cada aspecto de cada servicio puede ser programado. Esto brinda a los desarrolladores y operadores más control sobre la seguridad que un centro de datos tradicional. Sin embargo, la gran cantidad de funciones y sus herramientas de configuración conducen al hecho de que puede configurar desde varias interfaces y, y esto es importante, los parámetros predeterminados son diferentes para diferentes métodos.

Para los usuarios experimentados, esto no es un problema; por el contrario, utilizarán la herramienta más adecuada para la tarea. Sin embargo, para otros, el resultado puede no estar a la altura de sus expectativas.

Almacenamiento de Amazon S3


Amazon Simple Storage Services o Amazon S3 es uno de los servicios en la nube más buscados que utilizan muchos clientes, desde pequeñas empresas hasta grandes corporaciones. La popularidad ha convertido a S3 en un objetivo favorito para los atacantes que buscan fallas en la implementación de servicios y errores en su configuración.

Los vectores de ataque más comunes de Amazon S3 utilizados por los cibercriminales son:

  • instalaciones de almacenamiento público para grabación;
  • intercepción de cuentas;
  • abuso de privilegios.

Grabación compartida


En febrero de 2018, el minero de criptomonedas Monero fue descubierto en el sitio de uno de los periódicos estadounidenses más grandes. Cada lector que visitó el sitio extrajo monedas para delincuentes que agregaron código malicioso a los archivos JavaScript de la publicación.

El sitio del periódico fue alojado por Amazon y almacenó todas las imágenes, scripts y archivos de estilo en el repositorio S3. El acceso a este repositorio estaba limitado solo por la lectura, por lo que la piratería fue una completa sorpresa para los administradores del sitio. Simplemente no podían entender cómo fueron pirateados hasta que los especialistas en servicios en la nube explicaron que la razón eran los derechos de acceso incorrectos.

Los repositorios de Amazon S3 se pueden usar a través de http / https, y en esta parte, los administradores del sitio hicieron todo bien, restringiendo el acceso solo a la lectura. Sin embargo, también se puede acceder a S3 a través del protocolo nativo de AWS a través de la línea de comando, y los derechos de acceso para tales llamadas deben establecerse por separado, y de forma predeterminada, el acceso al almacenamiento a través de AWS CLI está permitido para todos los usuarios autorizados de AWS.

imagen
El resultado de ejecutar el comando de consola aws s3api get-bucket-acl --bucket <BUCKET_NAME> para la bóveda predeterminada

para los nuevos usuarios de Amazon S3, la necesidad de restringir dos veces sus permisos de bóveda está lejos de ser obvio, lo que provocó numerosos incidentes.

A finales de 2018, AWS redefinió la política de seguridad al prohibir el acceso público desde la consola a los nuevos repositorios S3, pero esta política no se aplicó al usar la línea de comandos. El acceso todavía tenía que estar limitado a un equipo separado.

En 2018-2019, el compromiso del almacenamiento S3 se generalizó. Algunos profesionales de seguridad y piratas informáticos amigables buscaron específicamente recursos de AWS que estaban abiertos para escribir y dejaron allí archivos de advertencia.

imagen
Advertencia anónima sobre una configuración insegura de AWS S3

Alguien incluso ofreció sus servicios para configurar parámetros de almacenamiento seguro:

imagen
Advertencia y oferta de servicios del Pentester Random Robbie

Random Robbie es el seudónimo de Robbie Wiggins pentester, quien en 2018 dejó su advertencia sobre los miles de almacenamiento S3 abiertos para la grabación.

Los piratas informáticos aprovecharon de inmediato la capacidad de modificar libremente los sitios alojados en repositorios S3. El grupo Magecart introdujo masivamente código malicioso para robar datos de tarjetas bancarias e información de cuenta de usuario. Después de todo, todo lo que se requería era encontrar un sitio que aceptara pagos y utilizara AWS. Como resultado, los delincuentes lograron robar los datos de cientos de miles de visitantes a dichos recursos.

imagen
Ejemplo de datos que un skimmer pasó a los delincuentes

Entre las víctimas de las acciones de Magecart se encuentran cientos de tiendas en línea, incluidas marcas conocidas.

En el curso del estudio, descubrimos que, a pesar de las numerosas publicaciones y recomendaciones sobre la configuración segura de los servicios de AWS, al menos cinco tiendas en línea comprometidas continúan utilizando las tiendas S3 que se pueden escribir. Hasta la fecha, sus sitios no contienen skimmers, pero se pueden agregar en cualquier momento, ya que los cibercriminales tienen herramientas convenientes a su disposición para facilitar la búsqueda de recursos vulnerables.

Herramientas de búsqueda de almacenamiento abierto S3


Las herramientas Slurp, Bucket Stream y s3scanner lo ayudan a encontrar almacenamiento legible y grabable.

Slurp lo ayuda a encontrar posibles nombres de almacenamiento para un dominio determinado y verificar los permisos de escritura en ellos:

imagen
ejemplo de salida de Slurp. El acceso por http está cerrado.

Para verificar la disponibilidad del almacenamiento encontrado a través de la CLI de AWS, puede usar el comando get-bucket-acl:

imagen
también se cierra el acceso al recurso a través de la API de AWS.

La utilidad s3scanner escrita en Python utiliza una heurística simple para encontrar posibles nombres de almacenamiento y verifica el acceso a ellos.

imagen
Buscar y verificar la disponibilidad de almacenamiento S3 usando s3scanner

La utilidad Bucket Stream busca tiendas S3 potencialmente vulnerables en fuentes públicas, por ejemplo, en Certificate Transparency y otras.

La utilidad AWSBucketDump enumera los archivos del repositorio cuyos nombres contienen palabras clave específicas:

imagen
resultado de la utilidad AWSBucketDump

Utilizando estas utilidades, de diciembre de 2018 a enero de 2019 encontramos más de 5200 almacenes S3 únicos. Alrededor de 4.400 de estos estaban disponibles para las utilidades de línea de comandos estándar de AWS. Solo 79 de ellos estaban disponibles para leer y 40 para escribir. Para acceder a parte de ellos, simplemente era necesario asignar los derechos necesarios.

Cómo se filtran las cuentas


Los derechos de acceso a los recursos son una fuente de dolor de cabeza para los desarrolladores. Y en el caso de los fondos en la nube, el problema se agudiza aún más. Los procesos deben autenticarse para obtener acceso a los recursos; de lo contrario, existe el riesgo de robo o compromiso de datos. Toda la pregunta es cómo hacer esto sin arriesgarse a comprometer los datos al publicar el código en el repositorio, como lo hizo el autor del siguiente fragmento publicado en Pastebin:

imagen
Un fragmento del código publicado en Pastebin con ID y clave de API de AWS válidas

Al usar estos datos, el atacante puede obtener todos los derechos que son proporcionados por la cuenta de esta aplicación.

Otra fuente de filtraciones de credenciales son los certificados de cliente API de Kubernetes. Por un lado, en la configuración predeterminada, este sistema de orquestación de contenedores requiere protección obligatoria en forma de certificado de cliente. Por otro lado, los desarrolladores con sorprendente ingenuidad publican certificados junto con código en GitHub, Pastebin y otros servicios.

Solo en Pastebin logramos encontrar unos cincuenta certificados de clientes diferentes colocados con scripts de configuración.

Si publicar certificados en texto claro en cualquier lugar es una mala idea, publicarlo en GitHub es simplemente desagradable, porque:

  • Para eliminar un certificado, debe eliminarlo de todas las versiones guardadas en el repositorio;
  • - , , ;
  • , , , .

Las claves y certificados API comprometidos pueden convertirse en una fuente de daños financieros graves, como una empresa rusa que le debía a Amazon $ 12 mil por un día : pirateó un sitio web en Bitrix, que, entre otras cosas, indicaba una clave API para acceder al almacenamiento S3.

imagen
Captura de pantalla del panel de facturación de una empresa rusa, cuya clave API robada se utilizó para crear muchas máquinas virtuales y minería de criptomonedas. Fuente: habr.com/en/post/357764

La filtración de datos de clientes puede ser no menos dolorosa, como en Imperva en 2019 . Imperva también robó la clave API y fusionó todos los datos del cliente.

Los delincuentes cibernéticos pueden utilizar las cuentas robadas para intercambiar ilegalmente servidores dedicados de AWS, que deberán pagar los propietarios reales. En el foro de lolzteam, encontramos más de 250 anuncios que ofrecen "puro cero Dedicos".

imagen
Anuncio en el foro lolzteam. ¿Quién pagará a Amazon al final?

Una tercera fuente de fugas de claves API es una variedad de cursos de capacitación para programadores.

Al tratar de explicar el proceso de conexión a los servicios de AWS a los principiantes de la manera más simple posible, los autores replican las malas prácticas, lo que en el futuro conduce a nuevos y nuevos casos de compromiso.

imagen
Un fragmento de un curso de Python que explica cómo trabajar con los servicios de Amazon S3. Se ofrecen claves para codificar en el programa

Los autores del curso sobre el lenguaje Java progresivo y seguro demuestran una actitud tan descuidada con respecto a la seguridad de las claves API:

imagen
el lenguaje es diferente, pero el consejo es el mismo: las claves están en el texto del programa.

Nuestras recomendaciones


La configuración incorrecta de los servicios en la nube plantea muchos riesgos por el uso ilegal de recursos informáticos arrendados para la minería de criptomonedas al robo de datos y la introducción de skimmers en línea. En este sentido, recomendamos que el personal de seguridad analice los escenarios de implementación en la nube para identificar posibles vulnerabilidades antes de que se complete el proceso. Los scripts de validación en la nube como AWS CloudFormation proporcionan información sobre cómo funcionará la infraestructura resultante, dónde buscar configuraciones o registros de seguridad incorrectos o faltantes. Entre las herramientas de seguridad desarrolladas por Trend Micro, hay un producto destinado a proteger los entornos de la nube: Deep Security para instancias de Amazon EC2.Y la herramienta Cloud Conformity permite que el entorno en la nube de la empresa tenga configuraciones inseguras.

Para los programadores que usan claves API de AWS para interactuar con los repositorios S3, sugerimos cambiar a trabajar a través de AWS Secrets Manager, Docker Secrets, Blackbox, git-secrets y otras herramientas similares que permitirán evitar el uso comprometido y malicioso de las credenciales almacenadas junto con el original textos de solicitud

More articles:


All Articles