Vulnerabilidades

Una vulnerabilidad de neutralización inapropiada de la entrada en FortiWLC versión 8.5.1, permite a un atacante autenticado remoto realizar un ataque de tipo cross site scripting (XSS) almacenado por medio del perfil ESS o el perfil Radius

Una vulnerabilidad de expiración de sesión insuficiente en FortiDeceptor versiones 3.0.0 y posteriores, permite a un atacante reutilizar los ID de sesión de usuario administrador no vencidos para obtener privilegios de administrador, en caso de que el atacante sea capaz de obtener ese ID de sesión por medio de otros ataques hipotéticos

En CSS Validator, menor o igual al commit 54d68a1, se presenta una vulnerabilidad de tipo cross-site scripting al manejar los URI. Un usuario tendría que hacer clic en un enlace validador específicamente diseñado para activarlo. Esto ha sido parcheado en el commit e5c09a9

En APNSwift versión 1.0.0, llamando a APNSwiftSigner.sign(digest:) es probable que resulte en un desbordamiento del búfer de la pila. Esto se ha corregido en la versión 1.0.1

En Limdu versiones anteriores a 0.95, la función trainBatch tiene una vulnerabilidad de inyección de comandos. Es poco probable que los clientes de la biblioteca de Limdu se den cuenta de esto, por lo que pueden escribir involuntariamente código que contiene una vulnerabilidad. Esto ha sido parcheado en la versión 0.95

el archivo documents_add.php en Kordil EDMS versiones hasta 2.2.60rc3, permite una ejecución de comandos remota porque los archivos .php pueden ser cargados en la carpeta de documentos

En LoRa Basics Station versiones anteriores a 2.0.4, se presenta una vulnerabilidad de Uso de la Memoria Previamente Liberada que conlleva a una corrupción de la memoria. Este error es desencadenado en máquinas de 32 bits cuando el servidor CUPS responde con un mensaje (https://doc.sm.tc/station/cupsproto.html#http-post-response) donde la longitud de la firma es mayor que 2 GByte (nunca sucede en la práctica), o la respuesta está diseñada específicamente para desencadenar este problema (es decir, el campo length signature indica un valor mayor que (2**31)-1 aunque la firma en realidad no contiene tantos datos). En tal escenario, en máquinas de 32 bits, Basic Station ejecutaría una ruta de código, donde se accede a una porción de memoria después de que ha sido liberada, lo que hace que el proceso se bloquee y se reinicie nuevamente. La transacción de CUPS generalmente se autentica mutuamente por medio de TLS. Por lo tanto, para desencadenar esta vulnerabilidad, el atacante primero tendría que conseguir acceso al servidor CUPS. Si el usuario elige operar sin autenticación por medio de TLS pero está preocupado por esta vulnerabilidad, una solución posible es habilitar la autenticación TLS. Esto se ha corregido en la versión 2.0.4

Una ejecución de código del lado del cliente en gitlab-vscode-extension versión v2.2.0, permite al atacante ejecutar código sobre el sistema del usuario

En Conjur OSS Helm Chart versiones anteriores a 2.0.0, una vulnerabilidad crítica recientemente identificada resultó en la instalación de la base de datos de Conjur Postgres con un puerto abierto. Esto permite a un atacante conseguir acceso completo de lectura y escritura a la base de datos de Conjur Postgres, incluyendo el aumento de los privilegios del atacante para asumir el control total. Un actor malicioso que conoce la dirección IP y el número de puerto de la base de datos de Postgres y tiene acceso al clúster de Kubernetes donde se ejecuta Conjur puede conseguir acceso completo de lectura y escritura a la base de datos de Postgres. Esto permite al atacante escribir una política que permita el acceso total para recuperar cualquier secreto. Este Helm chart es un método para instalar Conjur OSS en un entorno Kubernetes. Por lo tanto, los sistemas afectados son solo sistemas Conjur OSS que se implementaron usando este gráfico. Otras implementaciones, incluidas Docker y CyberArk Dynamic Access Provider (DAP), no están afectadas. Para remediar esta vulnerabilidad, clone el último Helm Chart y siga las instrucciones de actualización. Si no es capaz de remediar completamente esta vulnerabilidad de inmediato, puede mitigar algunos de los riesgos asegurándose de que Conjur OSS se implemente en un clúster o espacio de nombres Kubernetes aislado. El término "isolated" se refiere a: - No se están ejecutando otras cargas de trabajo además de Conjur OSS y su base de datos de backend en ese clúster y espacio de nombres de Kubernetes. - El acceso de Kubernetes y helm al clúster y espacio de nombres está limitado a los administradores de seguridad por medio del Control de Acceso basado en Roles (RBAC)

Kordil EDMS versiones hasta 2.2.60rc3, permite un ataque de tipo XSS almacenado en los archivos users_edit.php, users_management_edit.php y user_management.php

Una vulnerabilidad en las versiones entre 20190304 y 20200507 de guest-oslogin de Google Cloud Platform, permite a un usuario al que solo se le otorga el rol "roles/compute.osLogin" para escalar privilegios a root. Al usar su membresía en el grupo "adm", los usuarios con este rol son capaces de leer el XID de DHCP desde el diario systemd. Con el XID de DHCP, es posible configurar la dirección IP y el nombre de host de la instancia en cualquier valor, que luego es almacenada en /etc/hosts. Un atacante puede luego apuntar a metadata.google.internal en una dirección IP arbitraria y suplantar al servidor de metadatos GCE que hace posible que el módulo PAM de inicio de sesión del Sistema Operativo otorgue privilegios administrativos. Todas las imágenes creadas después del 07 de mayo 2020 (20200507) están corregidas, y si no puede actualizar, le recomendamos editar /etc/group/security.conf y eliminar el usuario "adm" de la entrada de inicio de sesión del sistema operativo

Una vulnerabilidad en las versiones entre 20190304 y 20200507 de guest-oslogin de Google Cloud Platform, permite a un usuario al que solo se le otorgó el rol "roles/compute.osLogin" para escalar privilegios a root. Al utilizar su pertenencia al grupo "docker", un atacante con este rol es capaz de ejecutar docker y montar el Sistema Operativo host. Dentro de Docker, es posible modificar el sistema de archivos del Sistema Operativo host y modificar /etc/groups para obtener privilegios administrativos. Todas las imágenes creadas después del 07 de mayo 2020 (20200507) están corregidas, y si no la pueden actualizar, le recomendamos editar /etc/group/security.conf y eliminar el usuario "docker" de la entrada de Inicio de Sesión del Sistema Operativo