Sin duda tenemos que arrojar algo de luz sobre la vulnerabilidad CVE-2022-35914 htmLawedTest de GLPI.
La semana pasada empecé a recopilar información para escribir este post. Sólo ahora, una vez pasada la tormenta (al menos la oleada inicial), he tenido tiempo de terminar.
Lo primero que me vino a la mente fue la famosa cita de Oscar Wild:
Como las traducciones suelen ser pésimas, en español, esta frase ha evolucionado a algo así como:
Deja que hablen de ti, aunque sea mal
Más adelante hablaremos de esto, pero empecemos por el principio.
Lo que ha ocurrido
[box type=»warning»] Descargo de responsabilidad: No soy un experto en seguridad, así que no esperes un informe exhaustivo, sino más bien un archivo con información para que la consideres y alguna conclusión personal al final.[/box]
Si estás leyendo esto, puede que al menos te hayas enterado de algo, pero por si acaso, vamos a dejarlo claro.
Se han descubierto un par de vulnerabilidades críticas en GLPI, y todas las versiones anteriores están afectadas:
Este no es nuestro campo de experiencia, pero a grandes rasgos GLPI tuvo un problema con la biblioteca de terceros htmlLawed y una vulnerabilidad relacionada con la API.
Una puntuación base de CVSS de 9,8 da bastante miedo.
¿Es la primera vulnerabilidad grave de GLPI?
No, en absoluto.
Durante el verano, CVE-2022-31061 afectaban a versiones anteriores de GLPI, parcheadas mediante la actualización a 9.5.8 y 10.0.2, respectivamente.
Pero, la vulnerabilidad htmLawed( CVE-2022-35914) fue la que se explotó intensamente desde principios de mes. El resultado fue una cantidad masiva de instancias GLPI, que no estaban parcheadas correctamente, afectadas.
Repasemos cómo se produjeron los hechos a partir de nuestra información:
Cronología de los acontecimientos
2022-07-13 CVE se notifica
2022-07-13 CVE se parchea
2022-09-14 Se publican las versiones parcheadas de GLPI
(9.5.9 & 10.0.3)
2022-09-19 TICGAL notifica a sus contactos en su boletín de noticias
2022-09-19 TICGAL empieza a arreglar nuestros sistemas y se pone en contacto con los clientes contratados para programar el parcheos
2022-09-20 Algunos clientes preocupados (¿como tú?) abrieron un ticket para programar intervenciones en sus sistemas.
Algunas informaciones sobre los ataques que hemos encontrado. Probablemente, mientras escribo esto, hay varios adicionales.
Acceso web al fichero vulnerable
Si ves entradas de acceso similares en tu apache (o en tu servidor web de elección), lo más probable es que tu GLPI esté comprometido.
Picos de CPU
Excesivo consumo de ancho de banda / agotamiento del ancho de banda
Hemos tenido algunas instancias de prueba afectadas. Esta fue la notificación que recibimos el 4 de octubre:
Subscription:XXXXXXX- 1024 MB High Frequency – 208.76.222.133 (glpi10rc1): 149.8% used
[…]
Please note: Your bandwidth usage cap will reset on the 1st of every month.
Acciones automáticas que no funcionan
Debido a que el cronjob fue sustituido por uno malicioso, el cronjob necesario para que las acciones automáticas de GLPI funcionen ha desaparecido. Así que es más un efecto secundario que otra cosa.
Procesos extraños en ejecución
Acceso a /etc/passwd
Uno de nuestros clientes detectó este comportamiento anormal confirmando un servidor no limpiado a fondo. Nos costó mucho resolverlo.
No se ha detectado ninguna exfiltración de datos
Para que la DPO esté en reposo. No se ha detectado ningún signo de extracción de fecha. Eso no significa que no vaya a ocurrir en el futuro.
Buscando el verdadero impacto
¿Te ha afectado? Sé que esto no mejora las cosas, pero no estás solo.
Twitter es una gran fuente de (des)información. Ya sabes, manéjalo con cuidado. En mi opinión, a pesar de todo, no conozco una forma mejor de obtener información casi en tiempo real sobre cualquier tema al azar. Aquí tienes un ejemplo:
1/ The CVE-2022-35914 is already actively exploited. Combine available PoC on Github + Shodan dork for GLPI and you get webshells all over the place and cryptominers deployed. https://t.co/52xhVk60GY
¿Aún no estás convencido? Bien, compruebe que nuestro servidor de producción ha bloqueado intentos de ataque de fail2ban hasta hoy:
¿EDR en un servidor Linux?
Tuvimos la suerte de tener EL MEJOR -Bitdefender Endpoint Security Tools- para Linux instalado en nuestro servidor de producción. No bloqueó el ataque en sí, sino sus acciones sospechosas.
Tenemos conocimiento de primera mano de que Microsoft Defender para Endpoint en Linux (¿sabías que esta herramienta existía?), no bloquea ningún hilo. Sin embargo, reportó el acceso a /etc/passwd.
¿Tu EDR detectó el ataque? Por favor, compártelo en los comentarios.
¿Tú también, Gapp, hijo mío?
¿Tú también Gapp? 😉 Sí, Gapp también.
Incluso el peligroso bug relacionado con la API (CVE-2022-35947) no se aplica aquí porque está relacionado con la autenticación por token, y Gapp utiliza la autenticación por usuario/contraseña; teníamos que hacer algo para detener esta pesadilla.
Una de nuestras recientes determinaciones fue forzar a los usuarios de alguna manera a actualizar. No tenemos ese poder, pero se podría aplicar alguna influencia a nuestra creciente comunidad de Gapp.
¿Cómo? Sólo soportamos las versiones 9.5.9, 10.0.3 y superiores. De lo contrario, verás un mensaje como este:
Gapp Essentials (gratuito) y Gapp eXtended (White Label) obligan a actualizar a las versiones más seguras de GLPI.
Reflexiones
En mi opinión, todos estos datos anteriores significan:
Hay un número más significativo de instancias de GLPI en todo el mundo de lo que sabíamos. (Esto es bueno, ¿no?).
Muchos de ellos no están perfectamente mantenidos. (No tan bueno).
A partir de ahora, GLPI será un nuevo objetivo. (Sabíamos que este día llegaría, y finalmente lo hemos presenciado).
Como escribirlo me ha llevado tanto tiempo, he decidido añadir algunos ejemplos aterradores de mis búsquedas recientes:
Por si no lo sabías, Shodan Search Engine es una herramienta que puedes utilizar para buscar cualquier servicio expuesto, por ejemplo, localizar servidores GLPI. ¿Puedes ver lo peligroso que puede ser esta automatización?
Otra. ¿Puedes detectar la vulnerabilidad GLPI entre algunos problemas similares de software bien conocidos?
Así pues, GLPI ha alcanzado la mayoría de edad. Sé que el año pasado se cumplieron 18 años, y de ahí que haya empezado el post mencionando al Sr. Wilde.
Todos hemos aprendido la lección por las malas. Como equipo, estas son nuestras conclusiones:
Mejorar nuestros/tus procesos. (Actualmente se está trabajando en ello)
La comunicación es un elemento clave. No te bombardeamos con correos inútiles. Un correo electrónico al mes (hemos enviado siete este año) no es demasiado para mantenerle al tanto de una herramienta fundamental en tu departamento de TI. Por favor, lee la información pertinente. No serán más de 5 minutos.
GLPI es ahora un producto bien conocido. Y un posible objetivo de ataque. PoC como este demuestra que vendrán más ataques indiscriminados
Gracias al resto del equipo TICGAL por su duro trabajo en esta compleja situación.
Actualizado. Preguntas traducidas.
Nos estamos preparando para el lanzamiento de Gapp 1.1 y mientras necesitábamos hacer algo, entrentenido y útil. Pensando,... read more
...bueno, un poco sí, la verdad.
Siguiendo las recomendaciones de prevención del contagio del coronavirus COVID-19, inicialmente, y desde el sábado... read more
TICGAL, reconocida por su compromiso con la Responsabilidad Social Empresarial (RSE), ha sido recientemente galardonada con la certificación Empresa Responsabilízate,... read more
¿Te has fijado en UXÍA? Te presento a nuestra última incorporación virtual al #EquipoTICGAL, pero...un momento, empecemos por el principio.
Algunas... read more
Deja una respuesta