Non hai dúbida de que necesitamos botar luz sobre a vulnerabilidade de GLPI CVE-2022-35914 htmLawedTest. A semana pasada comecei a recoller información para escribir este artigo. Só agora, despois de que pasase a tormenta (polo menos a primeira onda), tiven tempo para rematar. O primeiro que me veu á mente foi a famosa cita de Oscar Wilde: “Se hai algo máis molesto no mundo que ter xente falando de ti, é certamente non ter a ninguén falando de ti”. Como as traducións adoitan ser malas, en español, esta frase evolucionou a algo así:
Falen de ti, aínda que sexa mal
Máis sobre isto máis adiante, pero empecemos desde o principio.
Qué aconteceu
[box type=”warning”] Aviso legal: 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 consideres e algunhas conclusións persoais ao final.[/box] Se estás lendo isto, polo menos oíches falar algo, pero por se acaso, aclaremos. Descubríronse un par de vulnerabilidades críticas en GLPI, e todas as versións anteriores están afectadas:
Non é o noso campo de experiencia, pero en resumo, GLPI tiña un problema cunha biblioteca de terceiros htmlLawed e unha vulnerabilidade relacionada coa API. Unha puntuación base CVSS de 9.8 é bastante aterradora.
¿Foi esta a primeira vulnerabilidade importante de GLPI?
Non, non o foi. Durante o verán, CVE-2022-31061 afectou a versións anteriores de GLPI, solucionadas 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 gran cantidade de instancias de GLPI non parcheadas correctamente afectadas. Revisemos como ocorreron os eventos baseados na nosa información:
Cronoloxía de eventos
2022-07-13 Notifícase o CVE
2022-07-13 Párchese o CVE
2022-09-14 Lánzanse versións parcheadas de GLPI (9.5.9 e 10.0.3)
2022-09-19 TICGAL notifica aos seus contactos no seu boletín
2022-09-19 TICGAL comeza a arranxar os nosos sistemas e contacta a clientes con contrato para programar o parcheado
2022-09-20 Algúns clientes preocupados (¿como ti?) abriron un ticket para programar intervencións nos seus sistemas.
Algunha información sobre os ataques que atopamos. Probablemente mentres escribo isto, hai varios adicionais.
Acceso ao arquivo ofensivo
Se ves entradas de acceso similares no teu apache (ou o teu servidor web de elección), é moi probable que o teu GLPI estea comprometido.
Picos de CPU
Consumo excesivo 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:
Suscripción:XXXXXXX- 1024 MB Alta Frecuencia – 208.76.222.133 (glpi10rc1): 149.8% usado […] Ten en conta: O teu límite de uso de ancho de banda restablecerase o 1 de cada mes.
Accións automáticas non funcionando
Debido a que o cronjob foi substituído por un malicioso, o cronjob necesario para que funcionen as accións automáticas de GLPI desapareceu. Así que máis que un efecto secundario que outra cousa.
Procesos estraños en execución
Accedendo a /etc/passwd
Un dos nosos clientes detectou este comportamento anormal confirmando un servidor non completamente limpo. Tivemos dificultades para resolver este problema.
Non se detectou exfiltración de datos
Para que o DPO descanse. Non se detectou ningunha sinal de extracción de datos. Dito isto, non significa que non suceda no futuro.
Buscando o impacto real
Fuches afectado? Sei que non mellora as cousas, pero non estás só. Twitter é unha excelente fonte de (des)información. Xa sabes, manéxao con coidado. A pesar de todo, non coñezo unha mellor maneira de obter información case en tempo real sobre calquera tema aleatorio. Aquí tes un exemplo: https://twitter.com/luminouw/status/1577069579637071882. Despois de ler o fío, busquei pola rede, cheguei a Vulmon.com e descubrín que a vulnerabilidade CVE-2022-35914 de GLPI estaba tendencia mundial! Estamos falando dun Ataque Mundial aquí! Observa a liña cian: GLPI é unha ferramenta de nicho, pero hai máis instalacións do que poderiamos imaxinar.
Ademais, temos información extraoficial que indica que algúns provedores teñen a maioría das súas instancias de GLPI hospedadas afectadas. Aínda non estás convencido? OK, mira os intentos de ataque bloqueados polo noso servidor de produción ata hoxe por fail2ban:
EDR nun servidor Linux?
Tivemos sorte de ter BEST – Bitdefender Endpoint Security Tools – para Linux instalado no noso servidor de produción. Non bloqueou o ataque en si, pero si as súas accións sospeitosas. Temos coñecemento de primeira man de Microsoft Defender for Endpoint en Linux (sabías que esta ferramenta existía?), que non bloqueou ningún fío. Con todo, informou do acceso a /etc/passwd. Detectou o teu EDR o ataque? Comparte nos comentarios.
Ti tamén, Gapp? 😉 Si, Gapp tamén. Aínda o erro perigoso relacionado coa API (CVE-2022-35947) non se aplica aquí porque está relacionado coa autenticación por token, e Gapp usa autenticación usuario/contrasinal; tivemos que facer algo para parar este pesadelo. Unha das nosas recentes determinacións foi forzar aos usuarios a actualizar dunha maneira ou outra. Non temos tal poder, pero pode que se aplique algo de influencia na nosa crecente comunidade de Gapp. Como? Só estamos a dar soporte ás versións 9.5.9 e 10.0.3 e superiores. Do contrario, verás unha mensaxe así: Gapp Essentials (Free) e Gapp eXtended (White Label) están forzando a actualización ás versións máis seguras de GLPI.
Pensamentos aleatorios
Na miña opinión, todos estes datos anteriores significan:
Hai un número maior de instancias de GLPI no mundo do que sabiamos. (Isto é bo, non é?)
Moitas delas non están perfectamente mantidas. (Non tan bo)
GLPI será un novo destino obxectivo a partir de agora. (Sabiamos que este día chegaría, e finalmente presenciamolo)
Como escribir isto levou tanto tempo, decidín engadir algúns exemplos aterradores das miñas recentes buscas: No caso de que non o saibas, Shodan Search Engine é unha ferramenta que podes usar para buscar calquera servizo exposto, por exemplo, localizando servidores GLPI. Ves o perigoso que pode ser esta automatización? Outro exemplo. Podes identificar a vulnerabilidade de GLPI entre algúns problemas semellantes de software coñecidos? Outras ligazóns relevantes:
Así, GLPI alcanzou a maioría de idade. Sei que o ano pasado foi o seu 18º aniversario, polo que comecei a publicación mencionando ao Sr. Wilde. Todos aprendemos unha lección do xeito difícil. Como equipo, estas son as nosas conclusións:
Mellorar os nosos/os teus procesos. (Actualmente traballando nisto)
A comunicación é un xogador clave. Non estamos a bombardearte con correos electrónicos inútiles. Un correo electrónico ao mes (enviamos sete este ano) non é demasiado para manterche informado sobre unha ferramenta crítica no teu departamento de TI. Por favor, le 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 como este demostra que virán máis ataques indiscriminados.
Grazas á Equipa de Soporte de TICGAL pola axuda para realizar este artigo.
Dende que comezamos a traballar con Signaturit enviamos todos os nosos orzamentos a través desta plataforma de firma electrónica avanzada.... read more
Non tivemos tempo de traducir esta entrada, mais podes atopar unha versión automática aquí: https://www.translatetheweb.com/?ref=TVert&from=en&to=es&a=https%3A%2F%2Ftic.gal%2Fgapp-1-3-is-live%2F read more
TICGAL, recoñecida polo seu compromiso coa Responsabilidade Social Corporativa (RSC), foi recentemente honrada coa certificación Empresa Responsabilízate, un recoñecemento prestixioso... read more
Outro exemplo. Podes identificar a vulnerabilidade de GLPI entre algúns problemas semellantes de software coñecidos? Outras ligazóns relevantes:
Deixa unha resposta