La seguridad de los sistemas de información es una preocupación creciente para las empresas mexicanas. Con el objetivo de proteger sus activos y garantizar la confidencialidad, integridad y disponibilidad de la información, cada vez más compañías están optando por realizar pruebas de penetración estándar. Estas pruebas, que buscan identificar las vulnerabilidades de los sistemas informáticos, permiten a las empresas tomar medidas para mejorar su seguridad y protegerse contra posibles amenazas.
Las empresas de Chile y todo LATAM se enfrentan cada vez a una mayor cantidad de ciberataques, lo que hace que la seguridad informática sea una prioridad para muchos negocios.
Si eres principiante, este artículo te ayudará a conocer qué es una Prueba de Penetración, también conocida con otros nombres como Prueba de Intrusión o Pentest. Esta sirve para evaluar la seguridad de una red. Se trata de un análisis exhaustivo de la infraestructura de la red para detectar puntos débiles en los que los atacantes externos podrían aprovecharse para obtener acceso no autorizado a la información almacenada. Estas pruebas no se limitan a la seguridad de la red, sino que también se pueden aplicar a aplicaciones, sistemas operativos, teléfonos inteligentes y otros dispositivos.
AWS (Amazon Web Services) es un servicio que ofrece un método sencillo para obtener acceso a servidores, almacenamiento, bases de datos y una amplia gama de servicios de aplicaciones a través de Internet.
Cada vez es más utilizado por pequeñas, medianas y grandes empresas para alojar aplicaciones, guardar imágenes, documentos o crear sus propias redes de una manera bastante sencilla, otorgando un gran nivel de escalabilidad para el usuario. La seguridad en las redes de AWS es crucial a la hora de desarrollar aplicaciones, ya que existen varias vulnerabilidades que podrían exponer información sensible que son esenciales para que un atacante pueda comprometer una red empresarial en la nube.
Este post no explicará en profundidad el uso de la herramienta AWS-CLI, no pretende servir de guía para la gestión de los diferentes servicios que componen AWS, sino que se encargará de detallar ciertos puntos de interés. La información adjunta (imágenes, comandos), corresponde a un caso real, que por motivos de privacidad será censurado para salvaguardar la identidad del cliente.
¿Qué necesito para empezar?
Existen diferentes formas por las que un atacante podría acceder a la infraestructura en la nube, pero todas ellas requieren obtener las credenciales del usuario IAM, que secompone de dos partes: la primera parte es la access_key que es un identificador del usuario y la segunda parte es la secret_access_key que corresponde a la contraseña necesaria para autenticarse en AWS.
Un atacante podría obtener las claves de sesión a través de la explotación de vulnerabilidades como SSRF (Server-Side Request Forgery), SQL Injection, Full Source Disclosure, RFI, etc. A continuación, explicaremos cómo fue posible obtener ambas claves a través de una de las vulnerabilidades mencionadas anteriormente.
Verificación rápida
Una de las muchas maneras de identificar si una aplicación está siendo alojada en AWS es hacer una resolución DNS inversa a la IP del servidor.
La dirección IP apunta al dominio de amazon AWS ec2-52-*-*-*.compute-1.amazonaws.com.
Durante las pruebas, se comprobó la existencia de una vulnerabilidad de Blind SQL Injection en una de las funcionalidades de la aplicación y a través de ella, se obtuvo las claves de usuario IAM correspondientes al área de producción. Las claves estaban almacenadas en texto plano dentro de una tabla de la base de datos.
Más allá de obtener las claves
Normalmente en un Penetration Test, un auditor se conformaría con solo incluir las claves obtenidas dentro del informe, es información que puede ser demasiado valiosa para el cliente y que puede tener un efecto devastador si se explota la vulnerabilidad. Sin embargo, quisimos ir más allá y tomar control de una de las instancias EC2 donde corría la aplicación utilizando las credenciales filtradas.
Para ello, se realizaron los siguientes pasos para conseguir acceder por SSH al servidor de producción objetivo. En la siguiente imagen se puede ver un resumen de la metodología utilizada para ello.
Haciendo uso de AWS-CLI
AWS-CLI es un cliente para consola escrito en python que permite al usuario interactuar con los diferentes servicios que ofrece AWS. Entre ellos, la posibilidad de operar sobre las instancias EC2, con AWS-CLI es posible crear imágenes AMI de una instancia concreta, arrancar y parar instancias, crear reglas de firewall, grupos de seguridad, entre otras cosas.
Así que lo primero para interactuar cómodamente con AWS es instalar la herramienta.
Una vez completada la instalación, se configuran las credenciales que se obtuvieron previamente a través de la vulnerabilidad SQL Injection.
Después de añadir las claves del usuario, se ejecutó el siguiente comando, para verificar que las credenciales eran válidas y no se trataba de datos que habían caducado hacía tiempo.
Esto dio una lista de los servidores S3 que componían la empresa. En este punto, se ha tomado el control sobre toda la Red EC2 de la Empresa, y para probar los privilegios, se decidió utilizar estos accesos para acceder a la instancia EC2 de producción donde se ejecutaba el sistema principal.
Escalada de privilegios
Después de verificar que las credenciales obtenidas funcionaban correctamente, hay que enumerar los privilegios del usuario IAM. Para ello, se utilizó la herramienta nimbostratus.
Nimbostratus es una herramienta de fingerprinting y explotación en redes AWS que entre sus funcionalidades permite crear usuarios IAM, comprobar privilegios, extraer información de la instancia de metadatos, etc.
Lo primero, fue verificar cuáles eran los privilegios del usuario que estaba utilizando.
Como se ve en la imagen de salida, el usuario tenía permiso para ejecutar algunas acciones limitadas en el servicio EC2.
Después de esta acción, se procedió a crear un nuevo usuario con todos los privilegios, esto fue posible debido a que el usuario IAM “produccion”, tenía los permisos de iam:CreateUser.
Accediendo a EC2
En este punto, se había logrado crear un usuario con TODOS LOS PRIVILEGIOS en la red de AWS. Ahora, se podría autenticar y cómodamente empezar a manipular al servicio de EC2.
El siguiente paso fue identificar en qué instancia corría la aplicación, para ello tenía que listar todas las instancias que había en EC2.
Mediante el comando anterior, se pudo listar todas las instancias pertenecientes al cliente. Para identificar en qué instancia se ejecutaba la aplicación, sólo tenía que consultar el valor de la clave PublicIpAddress e identificar la que contenía la IP pública del objetivo, así de sencillo.
Una vez identificada la instancia, se obtuvo su InstanceId correspondiente. El siguiente comando devuelve la instancia de destino, haciendo un filtro sobre el InstanceId.
