Vulnerabilidades

SAP Business Objects Web Intelligence: versión 420, permite a un atacante autenticado inyectar código JavaScript en documentos de Web Intelligence que luego se ejecuta en el navegador de la víctima cada vez que se visita la página vulnerable. La explotación exitosa puede llevar a la exposición de los datos a los que tiene acceso el usuario. En el peor de los casos, el atacante podría acceder a datos de bases de datos de informes.

SAP Business Objects Business Intelligence Platform es vulnerable al XSS almacenado, lo que permite a un atacante cargar documentos independientes en el sistema que, cuando los abre cualquier otro usuario, podrían tener un alto impacto en la integridad de la aplicación.

Un atacante no autenticado puede incrustar un acceso oculto a una URL de Biller Direct en un frame que, cuando lo carga el usuario, enviará una solicitud de cross-site scripting al sistema Biller Direct. Esto puede resultar en la divulgación o modificación de información no confidencial.

Una inyección SQL en los usuarios que buscan el endpoint de la API REST en ProLion CryptoSpike 3.0.15P2 permite a atacantes remotos autenticados leer datos de la base de datos mediante comandos SQL inyectados en el parámetro de búsqueda.

La verificación incorrecta de roles de usuario en múltiples endpoints de API REST en ProLion CryptoSpike 3.0.15P2 permite a un atacante remoto con privilegios bajos ejecutar funciones privilegiadas y lograr una escalada de privilegios a través de la invocación del endpoint de API REST.

Uptime Kuma es una herramienta de monitorización autohospedada y fácil de usar. Antes de la versión 1.23.9, la aplicación utiliza WebSocket (con Socket.io), pero no verifica que la fuente de comunicación sea válida. Esto permite que el sitio web de terceros acceda a la aplicación en nombre de su cliente. Al conectarse al servidor usando Socket.IO, el servidor no valida el encabezado "Origin", lo que hace que otro sitio pueda abrir conexiones al servidor y comunicarse con él. Otros sitios web aún necesitan autenticarse para acceder a la mayoría de las funciones; sin embargo, esto se puede usar para eludir las protecciones de firewall implementadas por las personas que implementan la aplicación. Sin la validación del origen, el Javascript ejecutado desde otro origen podría conectarse a la aplicación sin ninguna interacción del usuario. Sin credenciales de inicio de sesión, dicha conexión no puede acceder a endpoints protegidos que contengan datos confidenciales de la aplicación. Sin embargo, dicha conexión puede permitir al atacante explotar aún más vulnerabilidades invisibles de la aplicación. Los usuarios con el modo "Sin autenticación" configurado que dependen de un proxy inverso o un firewall para brindar protección a la aplicación serían especialmente vulnerables ya que otorgarían al atacante acceso completo a la aplicación. En la versión 1.23.9, se agregó verificación adicional del encabezado de origen HTTP al controlador de conexión socket.io. De forma predeterminada, si el encabezado "Origin" está presente, se comparará con el encabezado Host. Se denegaría la conexión si los nombres de host no coinciden, lo que indicaría que la solicitud es de origen cruzado. Se permitirá la conexión si el encabezado "Origin" no está presente. Los usuarios pueden anular este comportamiento configurando la variable de entorno `UPTIME_KUMA_WS_ORIGIN_CHECK=bypass`.

OpenEXR-viewer es un visor de archivos OpenEXR con sondeo detallado de metadatos. Las versiones anteriores a la 0.6.1 tienen una vulnerabilidad de desbordamiento de memoria. Este problema se solucionó en la versión 0.6.1.

@koa/cors npm proporciona Cross-Origin Resource Sharing (CORS) para koa, un framework web para Node.js. Antes de la versión 5.0.0, el middleware funciona de manera que si no se proporciona un origen permitido, devolverá un encabezado "Access-Control-Allow-Origin" con el valor del origen de la solicitud. Este comportamiento desactiva por completo uno de los elementos más importantes de los navegadores: la Política del Mismo Origen (SOP), lo que podría causar una amenaza de seguridad muy grave para los usuarios de este middleware. Si se espera tal comportamiento, por ejemplo, cuando el middleware se utiliza exclusivamente para prototipos y no para aplicaciones de producción, se debe enfatizar mucho en la documentación junto con una indicación de los riesgos asociados con dicho comportamiento, ya que es posible que muchos usuarios no lo sepan. La versión 5.0.0 corrige esta vulnerabilidad.

Uptime Kuma es una herramienta de monitorización autohospedada y fácil de usar. Antes de la versión 1.23.9, cuando un usuario cambia su contraseña de inicio de sesión en Uptime Kuma, un usuario que había iniciado sesión anteriormente conserva el acceso sin cerrar la sesión. Este comportamiento persiste constantemente, incluso después de reiniciar el sistema o el navegador. Esta vulnerabilidad permite el acceso no autorizado a cuentas de usuarios, comprometiendo la seguridad de información confidencial. La misma vulnerabilidad se solucionó parcialmente en CVE-2023-44400, pero se olvidó cerrar la sesión de los usuarios existentes en sus cuentas. Para mitigar los riesgos asociados con esta vulnerabilidad, los mantenedores hicieron que el servidor emitiera un evento de "actualización" (los clientes manejan esto recargando) y luego desconectaron a todos los clientes excepto el que inició el cambio de contraseña. Se recomienda actualizar Uptime Kuma a la versión 1.23.9.

Se descubrió un problema en BeyondTrust Privilege Management para Mac anterior a la versión 5.7. Un usuario autenticado y sin privilegios puede elevar sus privilegios ejecutando un script malicioso (que se ejecuta como raíz desde un directorio temporal) durante el tiempo de instalación. (Esto se aplica a macOS anteriores a 10.15.5 o a la Actualización de seguridad 2020-003 en Mojave y High Sierra. Las versiones posteriores de macOS no son vulnerables).

Se descubrió un problema en BeyondTrust Privilege Management para Windows hasta 5.6. Un atacante puede generar un proceso con múltiples usuarios como parte del token de seguridad (antes de la elevación de Avecto). Cuando Avecto eleva el proceso, elimina al usuario que inicia el proceso, pero no al segundo usuario. Por lo tanto, este segundo usuario aún conserva el acceso y puede otorgar permiso para el proceso al primer usuario.

Cuando se utiliza la implementación predeterminada de Verify para verificar un Captcha, se puede omitir la verificación. Por ejemplo, si el primer parámetro es una identificación inexistente, el segundo parámetro es una cadena vacía y el tercer parámetro es verdadero, la función siempre considerará que el Captcha es correcto.