Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Black Hat 2014: Investigador revela vulnerabilidades en la nube de Amazon

Un investigador mostró cómo las fallas de seguridad y malas configuraciones pueden tener consecuencias devastadoras para los clientes de AWS.

LAS VEGAS - Un conocido investigador dice que los profesionales de la seguridad no están prestando suficiente atención a la seguridad de las aplicaciones alojadas en la infraestructura de nube de Amazon Web Services (AWS), y sin un mayor enfoque en la seguridad en la nube de Amazon, los clientes de AWS pueden ser vulnerables a ataques que exponen información privada, se hacen pasar por instancias de EC2 de AWS y mucho peor.

Durante Black Hat 2014 en Estados Unidos, Andrés Riancho, fundador de la consultora Bonsai Information Security con sede en Argentina y jefe de proyecto para el marco de seguridad de código abierto w3af, detalló su experiencia ofreciendo servicios de pruebas de penetration para aplicación web de un cliente que estaba siendo alojado en la infraestructura de AWS .

A pesar de no tener mucha experiencia con los servicios en la nube de Amazon, Riancho aprendió a través de esta participación que existen numerosas vulnerabilidades potenciales y errores de configuración que podrían exponer a las compañías que operan en la nube de AWS al desastre absoluto.

"Si usted está interesado en la seguridad, si de alguna manera es responsable de la seguridad de las aplicaciones, necesita saber sobre esto", dijo Riancho.

Investigación revela potenciales vulnerabilidades y errores de configuración de AWS en la web

En cuanto a lo que él descubrió a través del pen test, Riancho dijo que lo importante es primero entender que todas las instancias de AWS EC2 almacenan metadatos, que pueden incluir detalles sobre Amazon Machine Images –utilizado para crear máquinas virtuales con EC2– así como la región donde se encuentra el centro de datos de Amazon que alberga una instancia, la dirección IP local y más.

Desde que descubrió rápidamente que cada bit de metadatos almacenados era como una ruta de que destaca el sendero hacia otros bits de datos importantes de aplicaciones en la nube, Riancho comenzó su proyecto de investigación mediante la creación de una herramienta de extracción de metadatos llamado nimbostratus, que él utiliza para extraer las huellas digitales de la infraestructura en la nube de AWS que se utiliza por la aplicación web.

Después de descargar los metadatos alojados en el servidor de aplicaciones Web, Riancho dijo que descubrió un grupo de seguridad de AWS que se había configurado a través de una secuencia de comandos de datos de usuario, una de las varias formas en que una instancia EC2 puede configurarse. Estas secuencias de comandos de datos de usuario tienden a contener buena información desde la perspectiva de un atacante, dijo, porque ellos deben saber de dónde recuperar el código fuente de una aplicación web en particular.

Riancho dijo que el script de datos de usuarios para la aplicación web de su cliente reveló un tesoro de detalles útiles, incluyendo el repositorio donde vivía la aplicación web, así como las claves privadas y públicas necesarias para darle acceso al repositorio y descargar las de aplicaciones Web código fuente.

Después, se dedicó a desentrañar el resto de la infraestructura de la aplicación web basada en la nube. Para que las instancias de EC2 accedan a servicios como S3, AWS ofrece perfiles de instancias que comparten credenciales con una instancia EC2 cuando se inicia. A pesar de la poderosa naturaleza de esas credenciales –pues le dan al atacante los mismos permisos que la instancia EC2 de la que son robados– Riancho dijo que se almacenan dentro de los mismos metadatos que originalmente descubrió en el servidor de la aplicación Web.

Con esas valiosas credenciales en la mano, Riancho escribió otra herramienta para probar en cuáles funciones de la API de AWS se podía acceder a través de sus credenciales de reciente adquisición. En este caso, descubrió una función llamada "ListQueues" que, después de algunas investigaciones, descubrió que podrían ser utilizadas para acceder al sistema de colas de mensajes (SQS) del AWS Simple Queue Server.

Investigaciones posteriores le mostraron a Riancho que podía escribir un mensaje a la cola SQS, y que Celery –una cola de tareas y trabajos asincrónico– también estaba en uso en ese ambiente; a pesar de una advertencia en la propia documentación de Celery al respecto de que su capacidad de manejo de problemas en serie es "inherentemente insegura" y ello expone a las aplicaciones de AWS a un ataque potencialmente devastador.

"Volviendo a nuestro sistema objetivo, sabemos que podemos escribir cosas a la cola SQS, y sabemos que [los servidores de trabajo] van a liberar de la serie todo lo que se envía a la cola SQS, y sabemos que está siendo problemático", dijo Riancho. "Así que si escribo algo en un formato personalizado a la cola SQS, y si está en el formato correcto, ejecutará comandos arbitrarios. Fue realmente muy fácil."

A partir de ese punto, Riancho descubrió que las credenciales para el servidor de trabajo fueron codificadas de manera robusta, o hard-coded –una garantía no-no de seguridad– y al realizar el mismo proceso de enumeración con las credenciales del servidor trabajador, él fue capaz de descubrir una base de datos MySQL que su cliente también había desplegado en AWS. Una cierta línea de la configuración de la base de datos MySQL, "1.rds.amazonaws.com", le dijo que la base de datos se encontraba en el Servicio de Bases de Datos Relacionales (RDS) de Amazon.

Riancho no pudo volcar la base de datos MySQL, pero se encontró con una mala configuración que le permitió realizar cualquier acción en la API de Gestión de Accesos e Identidades de AWS, lo que le permitió crear un usuario al azar con los privilegios necesarios para acceder a la base de datos.

Por último, con esos privilegios escalados, Riancho fue capaz de administrar la base de datos MySQL a través de RDS, lo que le permitió tomar una instantánea de la base de datos, restaurar la instantánea en RDS, y después establecer la contraseña de raíz para la instantánea restaurada que contó con toda la misma información que el original. Eso le dio acceso a la información más sensible, aunque un agente malicioso podría cambiar tan fácilmente la contraseña de la instancia RDS original y potencialmente crear una situación de denegación de servicio.

Riancho advirtió que esta situación particular, en gran parte, no fue el resultado de errores por parte de AWS, sino más bien una serie de errores por parte de los desarrolladores de la aplicación Web. Tales errores son fáciles de hacer y es probable que se repitan en el futuro a menos que los investigadores y los profesionales de la seguridad empresarial se ​​involucren más en el aseguramiento de la arquitectura de AWS.

"Los desarrolladores están liderando el camino" en la transición a los servicios en la nube, dijo Riancho, "y tenemos que ayudarles a asegurar la arquitectura Amazon que están utilizando."

La discusión de Riancho planteó algunas preocupaciones sobre la seguridad en la nube de Amazon, pero el reciente hackeo de Espacios Código alojados en AWS fue la realización de tales preocupaciones.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close