Vulnerabilidades

SPID.AspNetCore.Authentication es un Autenticador Remoto AspNetCore para SPID. La autenticación mediante Spid y CIE se basa en el estándar SAML2 que proporciona dos entidades: Proveedor de Identidad (IDP): el sistema que autentica a los usuarios y proporciona información de identidad (afirmación SAML) al Proveedor de Servicios, en esencia, es responsable de la gestión de las credenciales e identidad de los usuarios; Proveedor de Servicios (SP): el sistema que proporciona un servicio al usuario y se basa en el Proveedor de Identidad para autenticar al usuario, recibe aserciones SAML del IdP para otorgar acceso a los recursos. La lógica de validación de la firma es central ya que asegura que no se puede crear una respuesta SAML con aserciones arbitrarias y luego suplantar a otros usuarios. No hay garantía de que la primera firma se refiera al objeto raíz, se deduce que si un atacante inyecta un elemento firmado como primer elemento, todas las demás firmas no serán verificadas. El único requisito es tener un elemento XML firmado legítimamente por el IdP, una condición que se cumple fácilmente utilizando los metadatos públicos del IdP. Un atacante podría crear una respuesta SAML arbitraria que sería aceptada por los SP utilizando SDK vulnerables, lo que le permitiría hacerse pasar por cualquier usuario de Spid y/o CIE. Esta vulnerabilidad se ha solucionado en la versión 3.4.0 y se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

CIE.AspNetCore.Authentication es un Autenticador Remoto AspNetCore para CIE 3.0. La autenticación mediante Spid y CIE se basa en el estándar SAML2 que proporciona dos entidades: 1. Proveedor de Identidad (IDP): el sistema que autentica a los usuarios y proporciona información de identidad (afirmación SAML) al Proveedor de Servicios, en esencia, es responsable de la gestión de las credenciales e identidad de los usuarios; 2. Proveedor de Servicios (SP): el sistema que proporciona un servicio al usuario y se basa en el Proveedor de Identidad para autenticar al usuario, recibe aserciones SAML del IdP para otorgar acceso a los recursos. La librería cie-aspnetcore hace referencia a la segunda entidad, el SP, e implementa la lógica de validación de aserciones SAML dentro de las respuestas SAML. En las versiones afectadas no hay garantía de que la primera firma se refiera al objeto raíz, se deduce que si un atacante inyecta un elemento firmado como primer elemento, todas las demás firmas no serán verificadas. El único requisito es tener un elemento XML firmado legítimamente por el IdP, una condición que se cumple fácilmente utilizando los metadatos públicos del IdP. Un atacante podría crear una respuesta SAML arbitraria que sería aceptada por los SP utilizando SDK vulnerables, lo que le permitiría hacerse pasar por cualquier usuario de Spid y/o CIE. Este problema se ha solucionado en la versión 2.1.0 y se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

ZOO-Project es una plataforma de procesamiento de código abierto, publicada bajo la licencia MIT/X11. Una vulnerabilidad en la implementación de WPS (Web Processing Service) del proyecto ZOO permite el acceso no autorizado a archivos fuera del directorio previsto a través de path traversal. En concreto, el servicio Gdal_Translate, al procesar archivos VRT (Virtual Format), no valida correctamente las rutas de archivo a las que se hace referencia en el elemento VRTRasterBand, lo que permite a los atacantes leer archivos arbitrarios en el sistema. La vulnerabilidad existe porque el servicio no desinfecta correctamente el parámetro SourceFilename en los archivos VRT, lo que permite secuencias de navegación por path traversal (../). Cuando se combina con las capacidades de gestión de datos sin procesar de VRT, esto permite leer archivos arbitrarios como datos binarios sin procesar y convertirlos a formato TIFF, exponiendo de manera efectiva su contenido. Esta vulnerabilidad es particularmente grave porque permite a los atacantes leer archivos sensibles del sistema, lo que potencialmente expone datos de configuración, credenciales u otra información confidencial almacenada en el servidor. Un atacante no autenticado puede leer archivos arbitrarios del sistema a través de path traversal, lo que podría permitirle acceder a información confidencial, como archivos de configuración, credenciales u otros datos confidenciales almacenados en el servidor. La vulnerabilidad no requiere autenticación y se puede explotar de forma remota a través del servicio WPS. Este problema se ha solucionado en el commit `5f155a8` y se recomienda a todos los usuarios que actualicen. No existen workarounds para esta vulnerabilidad.

Meshtastic es una solución de red de malla de código abierto. En las versiones de firmware afectadas los paquetes manipulados sobre MQTT pueden aparecer como DM en el cliente a un nodo a pesar de que no estaban decodificados con PKC. Este problema se ha abordado en la versión 2.5.19 y se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

La vulnerabilidad de Server-Side Access Control Bypass en WombatDialer antes de 25.02 podría permitir a los usuarios no autorizados llamar potencialmente ciertos servicios sin el nivel de acceso necesario. Este problema se limita a los servicios utilizados por el cliente (no los servicios JSON de uso general) y requiere ingeniería inversa del protocolo de serialización patentado, lo que dificulta la explotación.

La gestión incorrecta de la sesión de cookies en Wombatdialer antes de 25.02 da como resultado que la identidad de sesión completa se escriba en sistema registros y podría ser utilizado por un atacante malicioso para hacerse pasar por una sesión de usuario existente.

Se encontró un defecto en Grub2. Un archivo JPEG especialmente manipulado puede hacer que el sistema JPEG de Grub2 verifique incorrectamente los límites de sus búferes internos, lo que resulta en una escritura fuera de los límites. La posibilidad de sobrescribir información confidencial para evitar las protecciones seguras de arranque no se descarta.

Duende.AccessTokenManagement es un conjunto de librerías .NET que administran tokens de acceso de OAuth y OpenId Connect. Duende.AccessTokenManagement contiene una condición de ejecución cuando se solicitan tokens de acceso mediante el flujo de credenciales del cliente. Las solicitudes concurrentes para obtener un token de acceso mediante diferentes parámetros de protocolo pueden devolver tokens de acceso obtenidos con el alcance, el indicador de recursos u otros parámetros de protocolo incorrectos. Este uso es algo atípico y es probable que solo un pequeño porcentaje de usuarios se vea afectado. Duende.AccessTokenManagement puede solicitar tokens de acceso mediante el flujo de credenciales del cliente de varias formas. En el uso básico, el flujo de credenciales del cliente se configura una vez y los parámetros no varían. En situaciones más avanzadas, se pueden realizar solicitudes con parámetros de protocolo variables llamando a sobrecargas específicas de estos métodos: `HttpContext.GetClientAccessTokenAsync()` y `IClientCredentialsTokenManagementService.GetAccessTokenAsync()`. Existen sobrecargas de ambos métodos que aceptan un objeto `TokenRequestParameters` que personaliza los parámetros de solicitud de token. Sin embargo, las solicitudes concurrentes con distintos `TokenRequestParameters` darán como resultado el mismo token para todas las llamadas concurrentes. La mayoría de los usuarios pueden simplemente actualizar el paquete NuGet a la última versión. Las personalizaciones de `IClientCredentialsTokenCache` que derivan de la implementación predeterminada (`DistributedClientCredentialsTokenCache`) requerirán un pequeño cambio de código, ya que su constructor se modificó para agregar una dependencia en el servicio `ITokenRequestSynchronization`. El servicio de sincronización deberá inyectarse en la clase derivada y pasarse al constructor base. El impacto de esta vulnerabilidad depende de cómo se use Duende.AccessTokenManagement y de la arquitectura de seguridad de la solución. La mayoría de los usuarios no serán vulnerables a este problema. Los usuarios más avanzados pueden encontrarse con este problema al llamar a los métodos especificados anteriormente con parámetros de solicitud de token personalizados. El impacto de obtener un token de acceso con parámetros de protocolo diferentes a los previstos variará según la lógica de la aplicación, la arquitectura de seguridad y la política de autorización de los servidores de recursos.

Webkul Qloapps v1.6.1 expone tokens de autenticación en URL durante la redirección. Cuando los usuarios acceden al panel de administración u otras áreas protegidas, la aplicación agrega tokens de autenticación confidencial directamente a la URL.

SmartBanner.js es un banner de aplicaciones inteligente personalizable para iOS y Android. Antes de la versión 1.14.1, haga clic en el enlace SmartBanner `View` y navegando a la página de terceros de las hojas de` Window.opener` expuestas. Puede permitir que terceros hostiles abusen de `window.opener`, por ejemplo, mediante redirección o inyección en la página original con SmartBanner. `rel =" noopener "` se pobla automáticamente en enlaces a partir de `v1.14.1`, que es una actualización recomendada para resolver la vulnerabilidad. Algunos workarounds están disponibles para aquellos que no pueden actualizar. Asegúrese de que el enlace 'Ver' solo esté llevando a los usuarios a App Store o Google Play Store, donde la seguridad está protegida por los respectivos equipos de seguridad de la tienda de aplicaciones. Si el enlace `View` va a una página de terceros, limite SmartBanner.js para usarse en iOS que disminuye el alcance de la vulnerabilidad ya que a partir de Safari 12.1,` rel = "noopener" `se impone en todos los` target = " _Blank "` enlaces. La versión 1.14.1 de SmartBanner.js contiene una solución para el problema.

SAGE DPW antes de 2024_12_001 es vulnerable al control de acceso incorrecto. Los controles de acceso basados ??en roles implementados no siempre se aplican en el lado del servidor. Los usuarios de SAGE de bajo privilegio con permisos de roles de empleados pueden crear cursos externos para otros empleados, a pesar de que no tienen la opción de hacerlo en la interfaz de usuario. Para hacer esto, una solicitud válida para crear un curso simplemente debe modificarse, de modo que la ID de usuario actual en el parámetro "ID" se reemplace con la ID de otro usuario.

Se descubrió un problema en Atos Eviden IDRA antes del 2.7.1. Un rol altamente confiable (administrador de configuración) podría aprovechar una condición ejecución para aumentar los privilegios.