La plataforma CMS de código abierto Directus corrige el error XSS

La plataforma CMS de código abierto Directus corrige el error XSS


De acuerdo con una nueva recomendación del Synopsys Cybersecurity Research Center (CyRC), 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 es subsanado inmediatamente. .

CVE-2022-24814 fue descubierto e informado por el investigador de CyRC David Johansson y afecta a la versión 9.6.0 y anteriores de Directus, un marco 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 diferentes 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 de referencia CVSS de 5.4, lo que le otorga un impacto medio.

En última instancia, permite que un usuario autenticado con acceso a Directus abuse de su función 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 atacado», dijo Johansson. «En general, le daría al atacante la capacidad de comprometer la cuenta de otro usuario y realizar acciones como: B. Agregar o cambiar datos atribuidos 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 toda la información almacenada en el sistema Directus y 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 podrían comenzar a atacar instalaciones que aún no se han actualizado, por lo que siempre es recomendable actualizar lo antes posible, incluso si no hay evidencia clara de explotación activa”, dijo.

La vulnerabilidad se reveló originalmente 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 contiene 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 respondió constantemente y solucionó la vulnerabilidad de manera oportuna.

Si bien CVE-2022-24814 no es tan impactante como Log4Shell, que catapultó los problemas con las herramientas de código abierto y el uso empresarial a fines de 2021, finalmente provino de una fuente similar.

La reciente revelación de una falla en un recurso de código abierto ampliamente utilizado que sustenta los componentes esenciales del trabajo de muchas organizaciones subraya la necesidad de que los equipos de seguridad entiendan exactamente qué utilizan los equipos de TI y de desarrollo que tienen la tarea de proteger.

«Ha habido mucho debate en la industria sobre si las herramientas de código abierto o propietarias son más seguras o más vulnerables a las vulnerabilidades, pero este debate pierde el punto», dijo Greg Fitzgerald, cofundador del especialista en administración de activos de TI Sevco Security.

“Independientemente del tipo de herramientas que utilice, el mayor riesgo al que se enfrentan las empresas es perder el control de su inventario de activos de TI. Las empresas están plagadas de implementaciones olvidadas o abandonadas, y ya sea de código abierto o propietario, una sola instancia sin parches puede ser suficiente para que los actores malintencionados invadan su red.

«Para proteger toda su superficie de ataque, la prioridad de los equipos de seguridad debe ser crear y mantener un inventario completo de todos los activos de TI que tocan la red».

Johansson agregó: “Antes de utilizar un nuevo componente de software, debe someterse a una evaluación de riesgos. Por ejemplo, si el componente de software es de código abierto, puede ver qué tan activamente se mantiene y revisar los plazos y las respuestas a las divulgaciones de vulnerabilidades anteriores, si corresponde.

“Para obtener una mejor imagen de las posibles vulnerabilidades, puede ser apropiado ejecutar algunas pruebas de seguridad en el software. En general, el impacto potencial debe determinar el alcance y la profundidad de las pruebas requeridas. Por ejemplo, si el componente de software se usa en una aplicación de misión crítica, se puede 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 para que pueda reaccionar rápidamente cuando se conozca una nueva vulnerabilidad. Las herramientas de análisis de composición de software (SCA) pueden ayudar”.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esta wen utiliza cookies, puedes ver la política de cookies aquí.    Configurar y más información
Privacidad