CVE-2022-35914 e como podería verse afectado o ecosistema GLPI

Sen dúbida temos que arroxar algo de luz sobre a vulnerabilidade CVE-2022-35914 htmLawedTest de GLPI.

A semana pasada empecei a recompilar información para escribir este post. Só agora, unha vez pasada a treboada (polo menos a onda inicial), tiven tempo de terminar.

O primeiro que me veu á mente foi a famosa cita de Oscar Wild:

Como as traducións adoitan ser pésimas, en español, esta frase evolucionou a algo así como:

Deixa que falen de ti, aínda que sexa mal

Máis adiante falaremos disto, pero empecemos polo principio.

O que ocorreu

[box type=”warning”] Descargo de responsabilidade: Non son un experto en seguridade, así que non esperes un informe exhaustivo, senón máis ben un arquivo con información para que a consideres e algunha conclusión persoal ao final.[/box]

Se estás a ler isto, poida que polo menos decatárasche de algo, pero por se acaso, imos deixalo claro.

Descubríronse un par de vulnerabilidades críticas en GLPI, e todas as versións anteriores están afectadas:

Este non é o noso campo de experiencia, pero a grandes trazos GLPI tivo un problema coa biblioteca de terceiros htmlLawed e unha vulnerabilidade relacionada coa API.

Unha puntuación base de CVSS de 9,8 dá bastante medo.

Foi esta a primeira vulnerabilidade significativa de GLPI?

Non, non o foi.

Durante o verán, CVE-2022-31061 afectaban a versións anteriores de GLPI, parcheadas mediante a actualización a 9.5.8 e 10.0.2, respectivamente.

Pero, a vulnerabilidade htmLawed( CVE-2022-35914) foi a que se explotou intensamente desde principios de mes. O resultado foi unha cantidade masiva de instancias GLPI, que non estaban parcheadas correctamente, afectadas.

Repasemos como se produciron os feitos a partir da nosa información:

Cronoloxía dos acontecementos

2022-07-13 CVE notifícase
2022-07-13 CVE parchéase
2022-09-14 Publícanse as versións parcheadas de GLPI
(9.5.9 & 10.0.3)
2022-09-19 TICGAL notifica aos seus contactos no seu boletín de noticias
2022-09-19 TICGAL empeza a arranxar os nosos sistemas e ponse en contacto cos clientes contratados para programar o parcheo
2022-09-20 Algúns clientes preocupados (¿como ti?) abriron un ticket para programar intervencións nos seus sistemas
2022-10-01 O primeiro PoC aparece en Github
2022-10-03 A CVE divúlgase
2022-10-03 Un cliente de CyberSec notifica que se está explotando a vulnerabilidade
2022-10-03 Comezou a revisión de servidores
2022-10-04 Comienza la pesadilla
2022-10-07 O INCIBE-CERT español reporta as vulnerabilidades nos seus avisos de seguridade de alerta temperá (SIC)

TICGAL certifica o seu compromiso coa sostibilidade obtendo o selo Empresa Responsabilizate

Algúns indicios de ser comprometido

Algunhas informacións sobre os ataques que atopamos. Probablemente, mentres escribo isto, hai varios adicionais.

Acceso ao ficheiro infractor

Se ves entradas de acceso similares no teu apache (ou no teu servidor web de elección), o máis probable é que o teu GLPI estea comprometido.

Picos de CPU

Excesivo consumo de ancho de banda / esgotamento do ancho de banda

Tivemos algunhas instancias de proba afectadas. Esta foi a notificación que recibimos o 4 de outubro:

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.

Accións automáticas que non funcionan

Debido a que o cronjob foi substituído por un malicioso, o cronjob necesario para que as accións automáticas de GLPI funcionen desapareceu. Así que é máis un efecto secundario que outra cousa.

Procesos estraños en execución

Acceso a /etc/passwd

Un dos nosos clientes detectou este comportamento anormal confirmando un servidor non limpado a fondo. Custounos moito resolvelo.

Non se detectou ningunha exfiltración de datos

Para que a DPO estea en repouso. Non se detectou ningún signo de extracción de data. Iso non significa que non vaia a ocorrer no futuro.

Buscando o verdadeiro impacto

Afectouche? Sei que isto non mellora as cousas, pero non estás só.

Twitter é unha gran fonte de (des)información. Xa sabes, manéxao con coidado. Na miña opinión, a pesar de todo, non coñezo unha forma mellor de obter información case en tempo real sobre calquera tema ao azar. Aquí tes un exemplo:

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

— Julien P. (@luminouw) October 3, 2022

Despois de ler o fío, busquei na rede, acabei en Vulmon.com e descubrín que a vulnerabilidade CVE-2022-35914 GLPI era tendencia en todo o mundo.

Estamos a falar dun ataque a nivel mundial! Observa a liña cian:

GLPI é unha ferramenta de nicho, pero hai máis instalacións das que poderiamos imaxinar.

Ademais, temos información extraoficial que apunta a que algúns provedores teñen a maioría das súas instancias aloxadas en GLPI afectadas.

A evolución do control de tempos: unha ollada ás novas funcionalidades de ActualTime 2.2

Aínda non estás convencido? Ben, comproba que o noso servidor de produción bloqueou intentos de ataque de fail2ban ata hoxe:

EDR nun servidor Linux?

Tivemos a sorte de ter O MELLOR -Bitdefender Endpoint Security Tools- para Linux instalado no noso servidor de produción. Non bloqueou o ataque en si, senón as súas accións sospeitosas

Temos coñecemento de primeira man de que Microsoft Defender para Endpoint en Linux (sabías que esta ferramenta existía?), non bloquea ningún fío. Con todo, reportou o acceso a /etc/passwd.

O teu EDR detectou o ataque? Por favor, compárteo nos comentarios.

Ti tamén, Gapp, fillo meu?

Ti tamén Gapp? 😉 Si, Gapp tamén.

Incluso o perigoso bug relacionado coa API (CVE-2022-35947) non se aplica aquí porque está relacionado coa autenticación por token, e Gapp utiliza a autenticación por usuario/contrasinal; tiñamos que facer algo para deter este pesadelo.

Unha das nosas recentes determinacións foi forzar aos usuarios dalgunha maneira para actualizar. Non temos ese poder, pero poderíase aplicar algunha influencia á nosa crecente comunidade de Gapp.

Como? Só soportamos as versións 9.5.9, 10.0.3 e superiores. Pola contra, verás unha mensaxe como este:

Gapp Essentials (gratuíto) e Gapp eXtended (White Label) obrigan a actualizar ás versións máis seguras de GLPI.

Reflexións ao azar

Na miña opinión, todos estes datos anteriores significan:

Hai un número máis significativo de instancias de GLPI en todo o mundo do que sabiamos. (Isto é bo, non?).
Moitos deles non están perfectamente mantidos. (Non tan bo).
A partir de agora, GLPI será un novo obxectivo. (Sabiamos que este día chegaría, e finalmente presenciámolo).

Como escribilo levoume tanto tempo, decidín engadir algúns exemplos aterradores das miñas procuras recentes:

Por se non o sabías, Shodan Search Engine é unha ferramenta que podes utilizar para buscar calquera servizo exposto, por exemplo, localizar servidores GLPI. Podes ver o perigoso que pode ser esta automatización?

Outra. Podes detectar a vulnerabilidade GLPI entre algúns problemas similares de software ben coñecidos?

Outras ligazóns relevantes:

Rematando

Así, GLPI cumpriu a maioría de idade. Sei que o ano pasado fixo 18, e por iso comezou a publicación mencionando ao señor Wilde.

Todos aprendemos a lección do xeito difícil. Como equipo, estas son as nosas conclusións:

Mellora os nosos/os teus procesos. (Actualmente traballando niso)
A comunicación é un elemento fundamental. Non te bombardeamos con correos electrónicos inútiles. Un correo electrónico ao mes (enviamos sete este ano) non é demasiado para manterche ao día dunha ferramenta crítica no teu departamento de TI. Lea a información relevante. Non será máis de 5 minutos.
GLPI é agora un produto ben coñecido. E un posible obxectivo de ataque. PoC coma este mostra que están por chegar máis ataques indiscriminados.

Grazas ao equipo de apoio do TICGAL polo seu esforzo nesta complexa solución.