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:

If there is anything more annoying in the world than having people talk about you, it is certainly having no one talk about you. - Oscar Wilde

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

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.

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.

cvss30-basescore9.8-nist-nvd

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)
->  Formación Zabbix na nosa terra. Maio de 2018

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.
htmlawed-apache-access-logs

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

strange-processes-CVE-2022-35914

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:

Twitter

By loading the tweet, you agree to Twitter’s privacy policy.
Learn more

Load tweet

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.

cve-2022-35914-htmlawedtest-trending-on-vulndb.org

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

CVE-2022-35914-Vulnerability-Trends

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índa non estás convencido? Ben, comproba que o noso servidor de produción bloqueou intentos de ataque de fail2ban ata hoxe:

blocked-attack-attempts-htmlawed

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

->  Chegoume un documento desde Signaturit. Que fago?

bitdefender-endpoint-security-tools-linux-threats-xplorer

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?
Gapp Logo

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-SelfService-Forces-Secure-GLPI-Versions

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:

  1. Hai un número máis significativo de instancias de GLPI en todo o mundo do que sabiamos. (Isto é bo, non?).
  2. Moitos deles non están perfectamente mantidos. (Non tan bo).
  3. 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?GLPI-PoC-CVE-2022_35914-Shodan

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

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.