Servidores Amazon AWS podran ser retenidos por rescate similar a MongoDB

Los servidores de almacenamiento en la nube Amazon AWS S3 pronto podrían ser víctimas de ataques de rescate, similar a la forma en que los grupos hacker retuvieron decenas de miles de bases de datos MongoDB a lo largo de 2017

La declaración, hecha en las redes sociales por el experto en infosec Kevin Beaumont, es nada menos que una profecía de lo que vendrá.

Se sabe que Amazon AWS S3 pierde datos

Los servidores de almacenamiento AWS S3 de Amazon han estado filtrando datos todo el año 2017, estando detrás de algunas de las filtraciones de datos más notables del año pasado, incluidas violaciones en la NSA, el ejército de EE. UU. , Proveedores de análisis y más.

Esos incidentes ocurrieron porque las compañías dejaron datos en contenedores S3 de lectura pública ("cubo" es un término usado para describir una unidad de almacenamiento S3). En la mayoría de los casos, esos datos fueron encontrados por investigadores de seguridad que ayudaron a las compañías a proteger sus sistemas, pero los hackers también pudieron acceder a estos archivos primero.

También hay una categoría de contenedores S3 que son incluso más peligrosos que los servidores de lectura pública. Esos son paquetes de escritura pública que permiten a cualquier usuario, con o sin una cuenta de Amazon S3, escribir o eliminar datos en la instancia de AWS S3. Un informe de Skyhigh Networks de septiembre de 2017 encontró que el 7% de todos los contenedores de Amazon AWS S3 eran de escritura pública.

Amazon AWS S3 puede seguir el camino de MongoDB y amigos

Los expertos creen que los grupos de hackers que han estado ocupados con los servidores MongoDB , ElasticSearch , Hadoop, CouchDB , Cassandra y MySQL para pedir rescate por todo 2017 podrían volverse pronto sus miras a los buckets de escritura pública S3.

Los ataques de rescate de 2017 generalmente siguieron el mismo patrón. Los hackers encontraron un servidor expuesto, borraron datos y dejaron una nota de rescate detrás de pedir un rescate. Algunas víctimas pagaron, esperando recuperar datos, pero la mayoría de los usuarios se quedaron en el altar, ya que los hackers no tenían el espacio de almacenamiento para respaldar todos los servidores rescatados, y nunca devolvieron ninguno de los datos prometidos.

Ahora, es inevitable que ocurra algo como esto en los propietarios de los servidores de Amazon S3.

"Los incidentes de MongoDB mostraron que la estrategia 'rociar y rezar' funciona, incluso sin guardar los datos", dijo el investigador de seguridad Dylan Katz a Bleeping Computer.

Katz cree que los datos S3 serán borrados, y no retenidos en busca de rescate, principalmente porque los segmentos S3 rasgaron grandes cantidades de datos, que un atacante no podría alojarlo todo.

Los ataques de rescate de AWS S3 son técnicamente posibles

El problema, como se dijo anteriormente, depende de los propietarios de cuentas AWS S3 que configuran incorrectamente los servidores, lo que permite el acceso de lectura y escritura a sus máquinas.

"S3 es como el lenguaje de programación C. Hay muchas maneras de pegarse un tiro en el pie", dijo el investigador de seguridad Mike Gualtieri a Bleeping Computer.

Gualtieri llegó incluso a crear un guión de prueba de concepto que aprovecha estos servidores para engañar a las víctimas y hacerles creer que sus datos estaban encriptados.

"Pude escribir un pequeño script que enumeraba el contenido del cubo y también intenté descargar uno de los archivos", nos dijo Gualtieri, "luego almacenó el contenido del archivo como un hash MD5, eliminó el archivo, y re-cargó con la extensión .enc ".

"La eliminación de archivos en masa también parece posible", dijo el experto.

Los investigadores han estado advirtiendo a los clientes de AWS S3 durante meses

Son escenarios como estos que asustan a algunos investigadores de seguridad. Uno de ellos es Robbie Wiggins.

Durante los últimos meses, Wiggins ha estado escaneando la Web en busca de espacios S3 de escritura pública y dejando un archivo de texto con una advertencia para los propietarios del servidor.

"Esta es una advertencia amistosa de que la configuración de su cubo Amazon AWS S3 es incorrecta", escribe Wiggins en estos archivos. "Cualquiera puede escribir en este cubo. Arregle esto antes de que un chico malo lo encuentre".

Ransacking AWS S3 buckets es fácil, pero encontrarlos no es

Pero el número es bajo en comparación con las decenas de miles de servidores MongoDB rescatados en 2017.

"Es cierto que existe la posibilidad de una fusión de estilo Mongo-geddon, pero existen factores atenuantes" , dijo a Bleeping Computer Chris Vickery , Director de Investigación de Riesgo Cibernético en UpGuard. "La cantidad de segmentos de S3 que se pueden escribir (los que alguien podría eliminar) son mucho menores que la cantidad de segmentos de S3 que se pueden leer", señaló Vickery.

El mayor problema, aunque no insuperable, serían las operaciones de escaneo. Para buscar servidores MongoDB, ElasticSearch o Hadoop, un atacante solo necesitaría escanear el espacio de direcciones IPv4 en un puerto en particular.

Pero las direcciones de los depósitos S3 usan nombres detallados, y no son una combinación simple de "IP: puerto".

"La cantidad de nombres de cubos S3 posibles es enorme y la velocidad a la que puedes consultar la existencia de [un posible nombre de cubeta] no es tan alta como la exploración de puertos", dijo Vickery, refiriéndose a las limitaciones en la cantidad de nombres posibles que un atacante podría adivina por segundo.

Dichas restricciones técnicas hacen que los ataques de rescate de cubos S3 sean más difíciles de realizar, principalmente porque el escaneo es mucho más lento, aunque todavía se pueden programar usando ataques de diccionario.

Los servidores AWS S3 aún tienen muchos datos senstive (ransomable)

No obstante, se sabe que los segmentos S3 contienen muchos datos confidenciales, algo que podría tentar a los atacantes a intentarlo.

"Es sorprendente cómo los datos confidenciales todavía están apareciendo en los segmentos S3", dijo Victor Gevers , investigador de seguridad y presidente de la Fundación GDI, a Bleeping Computer.

"Hemos encontrado datos médicos, datos militares, videos corporales de aplicación de la ley, propiedad intelectual [código fuente y casos de negocios], diseños de red, muchos archivos de copia de seguridad, claves privadas, archivos de billetera Bitcoin y documentos con nombres de archivos que claramente no se suponían ser expuesto "públicamente", nos dijo Gevers.

Un nuevo tipo de ataque de rescate se eleva en el horizonte

Pero los servidores AWS S3 no necesitan ser editables para ser intercambiables, según Gevers. El experto le dijo a Bleeping Computer que los servidores legibles -los de los que puede descargar datos, pero no escribir nada en el servidor- también podrían usarse en esquemas de rescate.

Gevers ve otro tipo de ataque de rescate golpeando a los propietarios de AWS S3, y probablemente también a otras tecnologías, comenzando el 25 de mayo, fecha de implementación de la GDPR de la UE.

El experto cree que otra forma de chantajear a los propietarios de servidores desatentos es creando instantáneas de los servidores expuestos y contactando a las empresas después del 25 de mayo pidiendo un rescate de Bitcoin para no denunciar a las autoridades de la UE, donde recibirán una multa considerable.

"Muchas organizaciones no están esperando el GDPR [fecha límite]", dijo Gevers. "GDPR abrirá una nueva lata de gusanos que hará posible una nueva forma de cibercrimen, que no requiere casi ninguna habilidad".

"Una búsqueda de Shodan o un motor de búsqueda de cubos S3 le dará resultados rápidos. Solo necesita saber qué palabras clave buscar [para buscar]", dijo Gevers, aludiendo a las herramientas disponibles que hacen que la búsqueda de datos expuestos a S3 sea un juego de niños. Dichas herramientas incluyen los proyectos de Búsqueda de almacenamiento en la nube pública y BuckHacker.

Fecha actualización el 2021-02-21. Fecha publicación el 2018-02-21. Categoría: amazon. Autor: Oscar olg Mapa del sitio Fuente: bleempingcomputer
Servidores Amazon AWS