Descripción del Sherlock:
As a fast-growing startup, Forela has been utilising a business management platform. Unfortunately, our documentation is scarce, and our administrators aren’t the most security aware. As our new security provider we’d like you to have a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.
Nos dan un .zip que contiene dos cosas:
| |
Un .pcap (captura de paquetes), que podemos abrir con Wireshark, y un .json con “alertas”.
1. Aplicación#
Nos preguntan “We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?”.
Para saber qué aplicación está ejecutándose podemos echar un vistazo al .pcap, y veremos mensajes HTTP de dicha aplicación. Si bajamos un poco veremos esto:
Vemos una solicitud a /bonita/portal/homepage. Si buscamos en Google qué aplicaciones pueden tener dicha ruta, daremos con Bonitasoft, la respuesta a esta primera pregunta.
Bonitasoft es una empresa y plataforma de automatización de procesos de negocio. Su producto principal es Bonita, una plataforma que permite diseñar, ejecutar y monitorizar procesos empresariales.
2. Ataque Bruteforcing#
La segunda pregunta es: “We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out?
Si bajamos un poco, veremos varias solicitudes a /bonita/loginservice, que parece tener que ver con lo que nos preguntan. Podemos filtrar el contenido poniendo http contains "/bonita/loginservice":
Aquí vemos todas las solicitudes de inicio de sesión. Si vamos mirándolas de una en una veremos que ni los emails se repiten, ni las contraseñas se repiten. Se intenta iniciar sesión con una gran variedad de emails, pero por cada email hay una contraseña única. P.ej
| |
Esto apunta a que las contraseñas usadas provienen de algún sitio en el que ya estaban asociadas a los usuarios con los que se intenta iniciar sesión, por ejemplo de una filtración. Este tipo de ataque se conoce como Credential Stuffing.
Si bajamos algo más, hasta el paquete nº3550, veremos que las credenciales con las que el atacante consigue iniciar sesión son seb.broom@forela.co.uk:g0vernm3nt
3, 4. CVE y Exploit#
Nos dicen “Does the vulnerability exploited have a CVE assigned - and if so, which one?”. Para resolver esto tenemos que encontrar dónde está esa vulnerabilidad.
Filtramos por http sin más, y vemos que justo después de iniciar sesión, el atacante manda esto al servidor:
Intenta interactuar con el endpoint pageUpload de la API, pero le añade ;i18ntranslation?action=add al final (posiblemente ?action=add sí sea de la API).
Como el ;i18ntranslation parece llamativo, probamos a buscarlo. Al hacerlo daremos con el CVE-2022-25237: Authorization Bypass & RCE.
Respuesta: CVE-2022-25237
La pregunta 4 dice “Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit?”. Esto ya lo hemos visto, es (sin caracteres especiales, como piden): i18ntranslation.
5. Combinaciones#
Nos preguntan “How many combinations of usernames and passwords were used in the credential stuffing attack?”.
Para responder esto filtramos de nuevo por http contains "/bonita/loginservice".
Hay que tener en cuenta que probar la misma combinación dos veces no cuenta doble, y en bastantes intentos de inicio de sesión el atacante prueba install:install (porque son las credenciales por defecto de Bonita). Para solucionar esto vamos a filtrar todos los mensajes HTTP que contengan “install”, y luego le sumaremos 1 al total. Usamos el filtro ! http contains "install".
Además, filtramos por la IP del atacante, ip.addr == 156.146.62.213.
Esto queda:
| |
Y si seleccionamos todos los paquetes, veremos Selected: 56 (0.7%), así que ahí tenemos la respuesta, 56 combinaciones. (Al final parece que no ha hecho falta sumar el 1 de install porque no cuenta como credential stuffing.)
6. Credenciales#
Preguntan “Which username and password combination was successful?”.
Esto ya lo tenemos de antes, la combinación es seb.broom@forela.co.uk:g0vernm3nt
7. Sitio web de texto#
La pregunta es “If any, which text sharing site did the attacker utilise?”.
Si el atacante usa un sitio web para alojar archivos de texto, es probable que sea para que el servidor los descargue o ejecute (mediante RCE), así que tenemos que fijarnos en lo que pasa justo después de que este haya iniciado sesión.
Poco después de haber iniciado sesión, si nos fijamos, el atacante hace que el servidor solicite esto con wget:
Ahí vemos que la página solicitada es pastes.io, y el archivo solicitado es https://pastes.io/raw/bx5gcr0et8.
8, 9. Pubkey#
Nos piden “Please provide the filename of the public key used by the attacker to gain persistence on our host.”.
Si miramos qué el enlace que el atacante solicitaba con wget:
| |
Vemos que es un script de bash que copia una clave pública al authorized_keys de la cuenta ubuntu, e inmediatamente después reinicia el servicio. La clave es esta:
| |
En cualquier caso, el nombre del archivo de la clave pública es el que tenía en pastes.io, es decir, hffgra4unv.
La pregunta 9 dice: “Can you confirm the file modified by the attacker to gain persistence?”
Podemos ver fácilmente que el archivo modificado por el script es /home/ubuntu/.ssh/authorized_keys.
10. MITRE ID#
La última pregunta dice: “Can you confirm the MITRE technique ID of this type of persistence mechanism?”
Si hacemos una búsqueda como “MITRE ID SSH Pubkey Persistence”, daremos con que el ID de la técnica es T1098.004.
Y con esto hemos acabado el Sherlock.
