Una vulnerabilidad de secuencias de comandos entre sitios (XSS) almacenada en el sistema de administración de contenido (CMS) Directus ampliamente utilizado podría comprometer la cuenta en la aplicación de administración del servicio si no se mitiga rápidamente, según un nuevo aviso del Centro de Investigación de Seguridad Cibernética de Synopsys (CyRC) .
Descubierto y marcado por el investigador de CyRC, David Johansson, CVE-2022-24814 afecta la versión 9.6.0 y anteriores de Directus, que es un marco basado en web de código abierto que se utiliza para administrar bases de datos basadas en SQL y conectar su contenido a través de una interfaz de programación de aplicaciones. (API) en varios clientes o sitios web.
CVE-2022-24814 es similar a dos problemas informados anteriormente, CVE-2022-22116 y CVE-2022-22117, y omite una mitigación anterior implementada para estos errores en Directus 9.4.2. Se le ha asignado un puntaje base CVSS de 5.4, lo que lo convierte en un impacto medio.
En última instancia, permite que un usuario autenticado con acceso a Directus abuse de su funcionalidad de carga de archivos para crear un ataque XSS almacenado que se ejecuta automáticamente cuando otros usuarios ven colecciones o archivos en Directus.
“Debido a la naturaleza de los ataques XSS, el daño potencial depende en gran medida de los privilegios del usuario objetivo”, dijo Johansson. “En el caso general, le daría al atacante la capacidad de comprometer la cuenta de otro usuario y realizar acciones, como agregar o modificar datos, que se atribuyen a ese usuario sin su conocimiento o consentimiento.
“En el peor de los casos, donde un usuario administrador se ve afectado, el actor malicioso podría robar cualquier información contenida en el sistema Directus, además de causar interrupciones al eliminar datos o cambiar la configuración del sistema”.
Johansson le dijo a Computer Weekly que no había visto ninguna evidencia de explotación activa de la vulnerabilidad, pero que no podía descartarse. “Los atacantes pueden comenzar a apuntar a instalaciones que aún no se han actualizado, por lo que siempre es recomendable actualizar lo antes posible, incluso si no hay evidencia firme de explotación activa”, dijo.
La vulnerabilidad se reveló inicialmente el 28 de enero de 2022 y se confirmó el 7 de marzo. El 18 de marzo, Directus lanzó la versión 3.7.0, que incorpora una corrección para CVE-2022-24814. Los usuarios que aún no hayan actualizado a esta versión deben hacerlo. Synopsys dijo que Directus había actuado de manera receptiva en todo momento y había abordado la vulnerabilidad de manera oportuna.
Si bien de ninguna manera fue tan impactante como Log4Shell, que catapultó los problemas relacionados con las herramientas de código abierto y su uso dentro de las organizaciones a la prominencia a fines de 2021, CVE-2022-24814 finalmente surge de una fuente similar.
La última revelación de un error en un recurso de código abierto ampliamente utilizado que sustenta los componentes esenciales del trabajo de muchas organizaciones destaca la necesidad de que los equipos de seguridad comprendan con precisión qué utilizan los equipos de TI y de desarrollo que tienen la tarea de proteger.
“Ha habido mucha discusión en la industria sobre si las herramientas de código abierto o propietarias son más seguras o propensas a vulnerabilidades, pero ese debate pierde el punto”, dijo Greg Fitzgerald, cofundador del especialista en gestión de activos de TI Sevco Security.
“Independientemente del tipo de herramientas que utilice, el mayor riesgo para las organizaciones es perder el control de su inventario de activos de TI. Las empresas están llenas de implementaciones olvidadas o abandonadas, y ya sea de código abierto o patentado, una sola instancia sin parches puede ser suficiente para que los actores malintencionados se afiancen en su red.
“Para proteger la totalidad de su superficie de ataque, la prioridad de los equipos de seguridad debe ser crear y mantener un inventario completo de cada activo de TI que entra en contacto con la red”.
Johansson agregó: “Antes de usar cualquier componente de software nuevo, debe pasar por algún tipo de evaluación de riesgos. Por ejemplo, si se trata de un componente de software de código abierto, podría observar qué tan activamente se mantiene y revisar los cronogramas y las respuestas a divulgaciones de vulnerabilidades anteriores, si las hay.
“Para obtener una mejor imagen de las posibles vulnerabilidades, puede ser apropiado realizar algunas pruebas de seguridad del software. En general, la cantidad y la profundidad de las pruebas necesarias deben depender del impacto potencial. Por ejemplo, si el componente de software se usa en una aplicación crítica para el negocio, entonces podría justificar una revisión de seguridad más completa.
“Finalmente, también es importante realizar un seguimiento de todos los componentes y versiones de software utilizados dentro de una organización, de modo que tenga la capacidad de reaccionar rápidamente cuando se revele una nueva vulnerabilidad. Las herramientas de análisis de composición de software (SCA) pueden ayudar con ese esfuerzo”.