El gigante del desarrollo de software y las herramientas de colaboración, Atlassian, advierte de un peligroso día cero en su software de colaboración.
No hay ninguna alerta sobre el fallo en la página web principal de la empresa, que presenta las herramientas más conocidas de la empresa, JIRA (un sistema de gestión de tickets de TI) y Trello (un foro de discusión), pero encontrarás el aviso de seguridad 2022-06-02 de Confluence en la web de Confluence.
El número oficial del fallo es CVE-2022-26134.
La existencia del fallo fue revelada por la empresa estadounidense de respuesta a amenazas Volexity, que afirma haber descubierto la vulnerabilidad mientras investigaba un incidente que “incluía la escritura de webshells JSP en el disco”.
Webshells revisados
Sin duda recordarás las webshells, porque estuvieron en todas las noticias hace poco más de un año durante los llamados ataques Hafnium, supuestamente realizados por ciberatacantes chinos contra los servidores de Microsoft Exchange en marzo de 2021.
https://nakedsecurity.sophos.com/2021/03/09/serious-security-webshells-explained-in-the-aftermath-of-hafnium-attacks/
Las webshells son una forma peligrosa de abrir una puerta trasera en una red mediante un ataque que a veces requiere que los atacantes hagan poco más que escribir un pequeño archivo en una parte de un servidor web donde se almacena el contenido.
En los años 90, los ciberatacantescon permiso de escritura en tu web probablemente habrían disfrutado añadiendo calaveras en llamas a tu página de inicio, y llamando la atención del público inmediatamente sobre el hecho de que habían entrado.
Pero añadiendo una página web que incluya lo que se llama un script del lado del servidor, los atacantes de hoy en día pueden acceder a tu red sin llamar la atención en absoluto.
Esto se debe a que muchos servidores web no sólo contienen archivos estáticos que se envían a los usuarios remotos cuando introducen la URL correcta.
En cambio, los servidores web a menudo se basan en archivos que, cuando son solicitados por un usuario, son ejecutados como un programa por un motor de secuencias de comandos dentro del servidor web, y se utilizan para generar el contenido real que se envía de vuelta.
Si esto suena peligroso, lo es, aunque generalmente se considera una característica, no un error.
De hecho, el scripting del lado del servidor es la base de tecnologías como ASP (Active Server Pages ¡el nombre lo dice todo!) de Microsoft y JSP (Jakarta Server Pages) de Java.
Como dice la Wikipedia:
JavaServer Pages (JSP) es una tecnología que ayuda a los desarrolladores de software a crear páginas web dinámicas basadas en HTML y XML, entre otros tipos de documentos.
Las Webshells pueden ser tan simples como una línea de código que realiza un proceso de tres pasos como este:
–> Extrae el texto de la URL o del cuerpo de la petición web entrante
–> Ejecuta el texto extraído como un script
–> Envia la salida del script falso como respuesta
El webshell ni siquiera necesita contener ningún código de malware específico propio que pueda destacarse.
Mientras el atacante pueda controlar (o incluso simplemente adivinar) el nombre del archivo webshell que has implantado, entonces puede simplemente visitar la URL del servidor que corresponde a ese archivo, cuando quiera y cargar nuevo código de malware para su ejecución inmediata cada vez.
Por supuesto, este tipo de “ejecuta lo que quieras en cualquier momento” tiende a dejar rastros que un atacante no puede controlar fácilmente y que un cazador de amenazas puede buscar, como mensajes de error inesperados, conexiones de red inusuales o procesos no relacionados con la web que aparecen en un servidor web.
Pero esos artefactos sólo aparecen como un efecto secundario de la actividad maliciosa que ya ha ocurrido, por lo que los atacantes tienen la ventaja hasta que alguien se da cuenta.
¿Qué ha pasado?
Como puedes imaginar, Atlassian no está dando ninguna información específica sobre el fallo por ahora.
Afortunadamente, aunque Volexity decidió publicar en su blog este agujero de seguridad en lugar de revelarlo en privado a Atlassian y dar a la compañía unos días para solucionarlo discretamente, ambas partes parecen haber mantenido los suficientes detalles en secreto como para que no conozcamos ningún código de muestra de “¡así es como se hace, amigos!” que sea público por el momento.
Atlassian aconseja a los clientes que pueden pre-filtrar los datos web entrantes que busquen URL que contengan ${ afirmando que bloquearlas “puede reducir el riesgo”.
Esto hace que este error suene un poco como el agujero Log4Shell de finales de 2021, donde el texto que se registraba no se registraba literalmente si contenía comandos especiales entre corchetes con caracteres ${….}.
Por lo tanto, suponemos que este exploit se desencadena por la forma en que el código de Atlassian procesa la parte de “consulta” de las URL que no sólo tienen un nombre de servidor y un nombre de archivo, sino que van seguidas de algún tipo de cadena de consulta, normalmente precedida por un signo de interrogación.
Curiosamente, los caracteres { and } no pueden aparecer en las URLs, y se supone que se transmiten como “códigos de escape” especiales en hexadecimal, apareciendo así como %7B y %7D respectivamente.
No está claro si este fallo depende de que los caracteres de la URL se envíen sin escapar, o si deberías comprobar si hay ${ después de que la URL haya sido “desescapada” por tu servidor web.
Por lo tanto, si vas a añadir un filtro de URL temporal, te sugerimos que busques el carácter { tanto en su forma sin formato como escapada, por si acaso.
¿Qué hacer?
Atlassian ha clasificado este error como crítico, y publicó los parches correspondientes el pasado 3 de junio. Por lo tanto os recomendamos que los instales lo antes posible.
Dejar un comentario