29 abr 2024

PENTESTING A SERVIDORES EN AMAZON WEB SERVICES Y GOOGLE CLOUD PLATFORM


En la era digital actual, donde la infraestructura en la nube se ha convertido en el pilar fundamental de numerosas empresas, la seguridad cobra un papel protagónico. En este escenario, Amazon Web Services (AWS) y Google Cloud Platform (GCP) emergen como líderes indiscutibles en la provisión de servicios en la nube. Sin embargo, la migración hacia estos entornos virtuales no está exenta de riesgos, y es aquí donde entra en juego el Pentesting (Penetration Testing), una técnica vital para evaluar y fortalecer la seguridad de los sistemas en línea.

En esta entrada basada en el artículo “Pentesting a servidores en Amazon Web Services y Google Cloud Platform” de L. Panesso, y J. A. Piraquive. Se hablará sobre algunas técnicas y herramientas utilizadas en cada fase del Pentesting de estas plataformas.

 

Pentesting a servidores en Amazon Web Services

Limitaciones legales

Los clientes de AWS pueden realizar pruebas de intrusión sin previo aviso en los servicios:

  • Instancias EC2
  • NAT Gateways
  • Balanceadores de carga elásticos
  • Amazon RDS
  • Amazon CloudFront
  • Amazon Aurora
  • Amazon API Gateways
  • AWS Lambda y funciones de Lambda Edge
  • Recursos de Amazon Lightsail
  • Entornos de Amazon Elastic Beanstalk

Actividades prohibidas durante las pruebas:

  • Recorrido de zonas DNS a través de las zonas alojadas de Amazon Route 53
  • Denegación de servicio (DoS), denegación de servicio distribuida (DDoS), DoS simulada, DDoS simulada
  • Saturación de puertos
  • Saturación de protocolos
  • Saturación de solicitudes (de inicio de sesión o de API)

Para realizar pruebas en servicios no incluidos en la lista anterior, se debe completar un formulario y esperar la autorización de AWS.


Reconocimiento

Durante la etapa inicial, se llevará a cabo la recopilación exhaustiva de datos del objetivo a auditar. Este proceso se realizará empleando herramientas y técnicas de fuentes abiertas de inteligencia (OSINT, por sus siglas en inglés). Todos los datos obtenidos en esta fase son de acceso público, lo que implica que pueden ser adquiridos por cualquier persona. Se enfocará la búsqueda en elementos específicos como correos electrónicos, contraseñas filtradas, pares de claves AWS IAM, y servicios AWS que estén expuestos al público. El objetivo es identificar información relevante que pueda ser útil para futuras exploraciones del objetivo.

Reconocimiento Pasivo: El reconocimiento pasivo implica que el auditor recopila información del objetivo sin interactuar directamente con él, sin realizar solicitudes directas. Para obtener acceso a las cuentas de AWS del objetivo, los correos electrónicos del dominio del objetivo son de gran utilidad. Herramientas como hunter.io, phonebook.cz o theHarvester pueden ser utilizadas para este fin.

Además del correo electrónico, se necesita la contraseña asociada. Se pueden buscar credenciales filtradas en bases de datos como intelex.io, bugmenot, pwndb2 o breach-parse para evitar la realización de ataques de fuerza bruta en el portal de login de AWS. Los pares de claves IAM son cruciales para explotar el objetivo, ya que la mayoría de los ataques en entornos AWS ocurren debido a políticas IAM mal configuradas. Estas claves pueden encontrarse en Github, donde los desarrolladores a menudo suben código con claves AWS. Herramientas como truffleHog facilitan la búsqueda de estas credenciales. Es importante identificar los servicios AWS expuestos al público, como Instancias EC2 y Buckets S3. Se pueden utilizar servicios como Shodan, dnsdumpster y crt.sh para enumerar subdominios y descubrir servicios asociados al objetivo, y luego verificar qué servicios pertenecen a AWS mediante un script que utilice nslookup.

Reconocimiento Activo: En el reconocimiento activo, el auditor interactúa con el objetivo para obtener información directamente de él. Este proceso se lleva a cabo principalmente a través de técnicas destinadas a identificar subdominios, ya sea mediante solicitudes al servidor DNS o mediante fuerza bruta.

Para identificar servicios de AWS expuestos al público, existen dos métodos principales:

  1. Peticiones al servidor DNS: Una manera eficiente de obtener los nombres de dominio de todas las máquinas dentro de un dominio es solicitando una transferencia de zona al servidor DNS correspondiente. Esta acción se realiza utilizando herramientas que permiten realizar estas solicitudes, como el comando 'host', comúnmente disponible en distribuciones GNU/Linux. Es importante tener en cuenta que las transferencias de zona pueden no estar autorizadas en algunos casos.
  2. Fuerza bruta: Si no es posible realizar una transferencia de zona, se puede recurrir a la fuerza bruta sobre el servidor DNS para enumerar los subdominios. Esto implica utilizar una wordlist que contenga posibles subdominios, como las disponibles en la colección de Seclists. Herramientas como dnsrecon pueden ser utilizadas para llevar a cabo esta tarea, especificando la opción '-t brt' para indicar el uso de fuerza bruta.

En el caso de los Buckets S3 expuestos al público, estos suelen tener dos nombres de dominio. Uno de ellos es predefinido e inmutable, mientras que el otro sigue la estructura subdominio-arbitrario.s3.amazonaws.com. Debido a esta estructura predecible, los Buckets S3 pueden ser fácilmente enumerados si no se utiliza una aleatorización en los subdominios. Esto significa que a partir de una wordlist, como la aws-s3-bucket-wordlist, es posible enumerar estos Buckets con relativa facilidad. Herramientas como Sandcastle pueden ser empleadas para llevar a cabo esta enumeración de manera efectiva.

 

Escaneo y enumeración

Después de completar el Reconocimiento, se procederá a la etapa de Escaneo y Enumeración. Durante esta fase, el auditor interactuará con el objetivo, explorando y listando los diversos servicios de AWS. No se emplea el mismo enfoque para cada uno de ellos.

1) Escaneo de Puertos en Instancias EC2: Las Instancias EC2 a menudo brindan servicios en varios puertos, como por ejemplo el servicio web en los puertos 80/443. Por esta razón, es necesario realizar un escaneo de puertos para identificar y listar los distintos servicios en funcionamiento en ellos. Normalmente, se emplea la herramienta Nmap para llevar a cabo esta tarea.

Una vez se haya identificado los diferentes puertos abiertos, es crucial analizar cada uno de ellos individualmente para enumerar exhaustivamente todos los servicios alojados en ellos.

2) Enumeración de Permisos IAM: Si se poseen claves IAM del objetivo, se pueden enumerar diversos elementos. La enumeración manual se realiza con AWS-CLI.

A continuación, se muestran algunos comandos básicos para enumerar políticas IAM. El proceso de enumerar políticas asociadas a un usuario o rol se puede automatizar con AWSRecon.

En algunos casos, no se tendrán permisos para listar las políticas, por lo que se deberá realizar una fuerza bruta sobre las llamadas a la API de AWS. Este proceso también se puede automatizar con la herramienta enumerate-iam.

Tabla 1 - Comandos para enumerar información básica del perfil iam

Tabla 2 - Comandos para enumerar políticas de un usuario

Tabla 3 - Comandos para enumerar políticas de un rol

 

Explotación

Una vez completado el escaneo y la enumeración, se avanzará hacia la etapa de Explotación. Durante esta fase, se encargará de identificar posibles vulnerabilidades de seguridad basándose en los datos recopilados anteriormente.

Estas vulnerabilidades pueden variar desde un portal web con una vulnerabilidad de SQL Injection en su función de inicio de sesión, hasta permisos IAM que le posibiliten aumentar sus privilegios en el sistema.

1) Explotación de Instancias EC2: La explotación de Instancias EC2 se basa en gran medida en el aprovechamiento de los servicios disponibles en sus puertos. Esto implica identificar y aprovechar principalmente vulnerabilidades conocidas en servicios desactualizados para obtener acceso a la Instancia EC2. Una manera de encontrar estas vulnerabilidades es mediante bases de datos como exploitdb, que proporcionan información detallada sobre vulnerabilidades específicas y sus exploits asociados.

Si bien no es factible abordar todos los servicios posibles en el alcance de un proyecto, existen recursos adicionales como HackTricks, que se centran en explicar cómo explotar los servicios más comunes de manera más detallada. Estos recursos proporcionan guías y técnicas para comprender y aprovechar las vulnerabilidades presentes en los servicios típicamente encontrados en las Instancias EC2, permitiendo a los usuarios familiarizarse con las mejores prácticas para asegurar sus sistemas frente a posibles ataques.

2) Explotación de Permisos IAM: Hay ciertos permisos que pueden ser aprovechados para adquirir los suficientes privilegios que permitan el control total de la infraestructura de AWS. Estos permisos pueden ser examinados manualmente, pero hay una herramienta llamada aws_escalate.py que realiza esta enumeración de manera automática y también identifica los métodos que pueden ser utilizados para llevar a cabo la explotación.

A continuación, se listan los diferentes permisos de IAM que son susceptibles a explotación, con su respectiva descripción.

Tabla 4 - Permisos iam susceptibles a explotación

Se puede generar una nueva edición de una directiva mediante el uso del permiso iam:CreatePolicyVersion, el cual permite crear una variante actualizada de una directiva existente a la que se tiene acceso. Para que esta nueva edición entre en vigor, es necesario configurarla como la versión predeterminada, lo que requiere además del permiso iam:SetDefaultPolicyVersion. Sin embargo, en algunos casos, no será indispensable este último permiso, ya que se puede establecer la nueva edición como predeterminada al momento de su creación mediante la opción --set-as-default. Una forma de aplicar este enfoque sería a través de un comando similar al siguiente:

aws –profile [PERFIL] iam create-policy-version -policy-arn [ARN_DE_LA_POLITICA] –policy-document file:[PATH_AL_policy.json] –set-as-default

El archivo policy.json debe contener una directiva que permita ejecutar cualquier acción sobre cualquier recurso de la cuenta, como se muestra a continuación:

Imagen 1 - Política IAM con privilegios de administrador

Para cambiar la versión predeterminada de la directiva, se requiere el permiso iam:SetDefaultPolicyVersion, que en algunos casos puede ser utilizado para aumentar los privilegios mediante el uso de versiones de directivas no utilizadas. Un ejemplo de cómo ejecutar este método sería el siguiente:

aws –profile [PERFIL] iam set-default-policy-version –policy-arn [ARN_DE_LA_POLÍTICA] –version-id [VERSIÓN]

Para crear una nueva clave de acceso, el usuario necesita el permiso iam:CreateAccessKey, lo que le permite generar un Access Key ID y un Secret Access Key para otro usuario dentro del entorno AWS. Un ejemplo de aplicación de este método sería el siguiente:

aws –profile [PERFIL] iam create-access-key –user-name [USUARIO]

Para asociar una directiva a un usuario, es esencial tener el permiso iam:AttachUserPolicy, que posibilita aumentar los privilegios al vincular una directiva a la que el usuario tenga acceso, otorgándole así los permisos definidos por dicha directiva. Un comando que ilustra cómo llevar a cabo este proceso sería:

aws –profile [PERFIL] iam attach-user-policy –user-name [USUARIO] –policy-arn [ARN_DE_LA_POLÍTICA]

Este método se puede aplicar de manera similar a grupos (iam:AttachGroupPolicy) y roles (iam:AttachRolePolicy).

Para crear o actualizar directivas asociadas a un usuario, el usuario necesita el permiso iam:PutUserPolicy, lo que le permite aumentar los privilegios al crear o actualizar una directiva a la que tenga acceso, añadiendo así permisos definidos por dicha directiva. Un comando para ejecutar este método sería:

aws –profile [PERFIL] iam put-user-policy –user-name [USUARIO] –policy-name [NOMBRE_DE_LA_POLÍTICA] –policy-document file:[PATH_A_LA_POLÍTICA]

Este proceso se puede extender a grupos (iam:PutGroupPolicy) y roles (iam:PutRolePolicy).

Para asignar un rol IAM existente a una nueva función Lambda y luego invocarla, el usuario necesita los permisos iam:PassRole, lambda:CreateFunction y lambda:InvokeFunction, lo que le permite aumentar los privilegios al asignar un rol IAM a una función Lambda y ejecutarla con los privilegios asociados a ese rol. Un ejemplo de cómo realizar esto sería:

aws –profile [PERFIL] lambda create-function –function-name [NOMBRE_INVENTADO] –runtime python3.6 –role [ARN_DEL_ROL] –handler lambda_function.lambda_handler –code file:[PATH_AL_SCRIPT]

El código utilizado podría ser un script en Python que otorgue privilegios de Administrador a un usuario específico, como se muestra a continuación:

Imagen 2 - Script en Python para función Lambda maliciosa

Luego de crear la función Lambda, el usuario debería invocarla para otorgar los privilegios de Administrador al usuario:

aws lambda invoke –function-name [NOMBRE_DE_LA_FUNCIÓN] response.txt

Para actualizar el código de una función Lambda existente, el usuario necesita el permiso lambda:UpdateFunctionCode, lo que le permite actualizar el código de una función Lambda asociada a un rol IAM, lo que posibilita realizar acciones en nombre de ese rol. Un ejemplo de cómo realizar esto sería:

aws –profile [PERFIL] lambda update-function-code –function-name [FUNCIÓN_OBJETIVO] –zip-file file:[ZIP_CON_EL_SCRIPT]

Se debe tener en cuenta que, si no se poseen los permisos necesarios, se debe esperar a que alguien más invoque la función Lambda.

 

 

Pentesting a servidores en Google Cloud Platform

Limitaciones legales

Los clientes de GCP pueden realizar pruebas de intrusión con previo aviso sobre sus servicios:

  •  AI Platform
  • API Keys
  • App Engine
  • Artifact Registry
  • Bigquery
  • Bigtable
  • Cloud Build
  • Cloud Functions
  • Cloud Run
  • Cloud Shell
  • Cloud SQL
  • Compute
  • Containers, GKE & Composer
  • DNS
  • Filestore
  • Firebase
  • Firestore
  • IAM, Principals & Org Policies
  • KMS
  • Logging
  • Memorystore
  • Monitoring
  • Pub/Sub
  • Secrets Manager
  • Security
  • Source Repositories
  • Spanner
  • Stackdriver
  • Storage

 

Reconocimiento

Durante la etapa inicial, se llevará a cabo la recopilación exhaustiva de datos del objetivo a auditar. Este proceso se realizará empleando herramientas y técnicas de fuentes abiertas de inteligencia (OSINT, por sus siglas en inglés). Todos los datos obtenidos en esta fase son de acceso público, lo que implica que pueden ser adquiridos por cualquier persona. Se enfocará la búsqueda en elementos específicos como credenciales, y servicios GCP que estén expuestos al público. El objetivo es identificar información relevante que pueda ser útil para futuras exploraciones del objetivo.

Reconocimiento Pasivo: El reconocimiento pasivo implica que el auditor recopila información del objetivo sin interactuar directamente con él, sin realizar solicitudes directas. Herramientas como CloudScraper pueden ser utilizadas para este fin.

El código a continuación permite crear una sesión a algún sitio web evitando cualquier protección anti-bots (CloudFlare).

Imagen 3 - Script en Python para CloudScraper

Reconocimiento Activo: En el reconocimiento activo, el auditor interactúa con el objetivo para obtener información directamente de él. Este proceso se lleva a cabo principalmente a través de técnicas destinadas a identificar Buckets, Firebase Realtime Databases, Google App Engine sites, Cloud Functions, y Apps mediante fuerza bruta. Herramientas como cloud_enum o CloudBruteForce pueden ser usadas para este fin, El comando a continuación permite reconocer los servicios de GCP mediante el uso de la herramienta cloud_enum.

./cloud_enum.py -k [NOMBRE_COMPAÑÍA] -k [SITIO_WEB_COMPAÑÍA] -k [NOMBRE_ARCHIVO_RESULTADOS]

 

Escaneo y enumeración

Después de completar el Reconocimiento, se procederá a la etapa de Escaneo y Enumeración. Durante esta fase, el auditor interactuará con el objetivo, explorando y listando los diversos servicios de GCP. No se emplea el mismo enfoque para cada uno de ellos.

Si bien los escaneos se pueden realizar de manera manual; Herramientas como gcp_scanner, gcp_enum, GCP-IAM-Privilege-Escalation pueden realizar estos escaneos de manera automática.

El uso de una de estas herramientas como gcp_scanner permite identificar el nivel de acceso que posee alguna credencial de GCP.

python3 scanner.py -o [CARPETA_PARA_GUARDAR_RESULTADOS] -g –

 

Explotación

Una vez completado el escaneo y la enumeración, se avanzará hacia la etapa de explotación. Durante esta fase, se encargará de identificar posibles vulnerabilidades de seguridad basándose en los datos recopilados anteriormente.

Escalación de privilegios: GCP, al igual que otras plataformas en la nube, define diferentes entidades como usuarios, grupos y cuentas de servicio, para controlar el acceso a estos recursos, GCP utiliza un sistema de roles que permite otorgar permisos específicos a las entidades mencionadas. De esta manera, se define el nivel de acceso que una entidad tiene sobre un recurso determinado, es importante destacar que existen ciertos permisos que pueden permitir a un usuario obtener aún más permisos sobre un recurso o incluso sobre recursos de terceros. Esto se conoce como escalada de privilegios y puede ocurrir por la explotación de vulnerabilidades o por una configuración incorrecta de los permisos.

1) Escalación de Privilegios a Una Entidad: La escalada de privilegios a una entidad en GCP es un tipo de ataque que permite a un actor malicioso suplantar a otra entidad dentro del sistema. Esto significa que el atacante puede obtener todos los permisos y privilegios asociados a la entidad suplantada, permitiéndole realizar acciones no autorizadas en la infraestructura de GCP.

Un ejemplo de este tipo de ataque sería el abuso del permiso getAccessToken. Este permiso permite a un usuario obtener un token de acceso para una cuenta de servicio específica. Si un atacante puede obtener este token, puede utilizarlo para hacerse pasar por la cuenta de servicio y obtener acceso a los recursos que la cuenta tiene permiso para acceder.

2) Escalación de Privilegios a Un Recurso: La escalada de privilegios en un recurso en GCP es un tipo de ataque que permite a un actor malicioso obtener más permisos sobre un recurso específico del que originalmente tenía. Esto puede permitirle realizar acciones no autorizadas en el recurso, como modificar datos sensibles o incluso eliminar el recurso por completo.

Un ejemplo de este tipo de ataque sería el abuso del permiso setIamPolicy sobre Cloud Functions. Este permiso permite a un usuario modificar la política de IAM de una función, lo que le permite otorgarse a sí mismo permisos adicionales para ejecutar la función.

Para realizar este tipo de ataques se cuenta con Herramientas como gcp_privesc_scripts.

El código utilizado para llevar a cabo este tipo de ataques es podría ser un archivo de consola que la herramienta gcp_privesc_scripts provee con el cual únicamente con ejecutarse provee múltiples maneras de escalar privilegios sobre una cuenta.

sh main.sh

Imagen 4 - Opciones de gcp_privesc_scripts

 

 

 @TheHackingDay

 

 

 

No hay comentarios:

Publicar un comentario

Tus Comentarios son Importantes para Nosotros Siéntete Libre De Opinar