Vulnerabilidades

Como se indica en el archivo “VTPM.md” en la documentación de eve, “VTPM es un servidor que escucha en el puerto 8877 en EVE, lo que expone la funcionalidad limitada del TPM a los clientes. VTPM permite a los clientes ejecutar binarios de tpm2-tools a partir de una lista de opciones codificadas. La comunicación con este servidor se realiza mediante protobuf y los datos se componen de 2 partes: 1. Encabezado 2. Datos Cuando se realiza una conexión, el servidor esperando 4 bytes de datos, que serán el encabezado, y estos 4 bytes se analizarán como el tamaño uint32 de los datos reales siguientes. Luego, en la función ""handleRequest"", este tamaño se usa para asignar un payload en memoria para los datos entrantes. A medida que este payload se asigna en la memoria, esto permitirá desbordar el tamaño asignado para el proceso relevante con datos libremente controlados. <br /> * Un atacante puede bloquear el sistema. <br /> * Un atacante puede obtener control sobre el sistema, específicamente sobre el proceso ""vtpm_server"", que tiene privilegios muy altos.

Al arrancar, el contenedor Pillar eve comprueba la existencia y el contenido de “/config/GlobalConfig/global.json”. Si el archivo existe, anula la configuración existente en el dispositivo al arrancar. Esto permite a un atacante cambiar la configuración del sistema, que también incluye algunas funciones de depuración. Esto podría usarse para desbloquear el ssh con “claves_autorizadas” personalizadas a través de la clave “debug.enable.ssh”, similar al hallazgo de “claves_autorizadas” que se señaló anteriormente. Otros usos incluyen desbloquear el USB para habilitar el teclado mediante la tecla ""debug.enable.usb"", permitir el acceso a VNC mediante la tecla ""app.allow.vnc"" y más. Un atacante podría habilitar fácilmente estas funcionalidades de depuración sin activar el mecanismo de ""measured boot"" implementado por EVE OS y sin marcar el dispositivo como ""UUD"" (""Actualización desconocida detectada""). Esto se debe a que la partición “/config” no está protegida por “measured boot”, es mutable y no está cifrada de ninguna manera. Un atacante puede obtener control total sobre el dispositivo sin cambiar los valores de PCR, por lo que no activará el mecanismo de ""measured boot"" y tendrá acceso completo a ""vault"". Nota: Este problema se solucionó parcialmente en estos commits (después de la divulgación a Zededa), donde la medición de la partición de configuración se agregó a PCR13: <br /> • aa3501d6c57206ced222c33aea15a9169d629141 <br /> • 5fef4d92e75838cc78010edaed5247dfbdae1889. <br /> Este problema se hizo viable en la versión 9.0.0 cuando el cálculo se trasladó a PCR14, pero no se incluyó en el ""measured boot"".

Al sellar/abrir la clave de “vault”, se utiliza una lista de PCRs, que define qué PCRs se utilizan. En un proyecto anterior, CYMOTIVE descubrió que la configuración no está protegida por el arranque seguro y, en respuesta, Zededa implementó medidas en la partición de configuración que estaba asignada a PCR 13. En ese proceso, PCR 13 se agregó a la lista de PCRs que sellan /abrir la llave. En el commit “56e589749c6ff58ded862d39535d43253b249acf”, la medición de la partición de configuración pasó de PCR 13 a PCR 14, pero PCR 14 no se agregó a la lista de PCR que sellan/abren la clave. Este cambio hace que la medición de PCR 14 sea efectivamente redundante ya que no afectaría el sellado/abrir de la llave. Un atacante podría modificar la partición de configuración sin activar el arranque medido, lo que podría dar como resultado que el atacante obtenga control total sobre el dispositivo con acceso completo al contenido de la "vault" cifrada.

Debido a la implementación de "deriveVaultKey", antes de la versión 7.10, la clave de almacén generada siempre tendría los últimos 16 bytes predeterminados como "arfoobarfoobarfo". Este problema ocurre porque "deriveVaultKey" llama a "retrieveCloudKey" (que siempre devolverá "foobarfoobarfoobarfoobarfoobarfo" como clave) y luego fusiona la clave de 32 bytes generada aleatoriamente con esta clave (tomando 16 bytes de cada una, consulte "mergeKeys"). Esto debilita mucho la clave. Este problema no persiste en los dispositivos que se inicializaron en la versión 7.10 o posteriores, pero los dispositivos que se inicializaron antes y se actualizaron a una versión más reciente aún tienen este problema. Implemente una actualización que imponga el uso completo de la clave de 32 bytes.

Al arrancar, el contenedor Pillar eve comprueba la existencia y el contenido de “/config/authorized_keys”. Si el archivo está presente y contiene una clave pública compatible, el contenedor abrirá el puerto 22 y habilitará sshd con las claves proporcionadas como claves autorizadas para el inicio de sesión de root. Un atacante podría agregar fácilmente sus propias claves y obtener control total sobre el sistema sin activar el mecanismo de ""measured boot"" implementado por EVE OS y sin marcar el dispositivo como ""UUD"" (""Actualización Desconocida Detectada""). Esto se debe a que la partición “/config” no está protegida por “measured boot”, es mutable y no está cifrada de ninguna manera. Un atacante puede obtener control total sobre el dispositivo sin cambiar los valores de PCR, por lo que no activará el mecanismo de ""measured boot"" y tendrá acceso completo a ""vault"". Nota: Este problema se solucionó parcialmente en estos commits (después de la divulgación a Zededa), donde la medición de la partición de configuración se agregó a PCR13:<br /> • aa3501d6c57206ced222c33aea15a9169d629141 <br /> • 5fef4d92e75838cc78010edaed5247dfbdae1889. <br /> Este problema se hizo viable en la versión 9.0.0 cuando el cálculo se trasladó a PCR14, pero no se incluyó en el ""measured boot"".

Phpjabbers PHP Shopping Cart 4.2 es vulnerable a la inyección SQL a través del parámetro id.

Vulnerabilidad de Cross-Site Scripting (XSS) almacenado en Webmin 2.002 y versiones anteriores a través del archivo Cluster Cron Job tab Input, que permite a los atacantes ejecutar scripts maliciosos inyectando un payload manipulado.

Se descubrió que D-Link DIR-816 A2 v1.10CNB05 contenía un Desbordamiento del Búfer a través del parámetro statuscheckpppoeuser en dir_setWanWifi.

Se descubrió que D-Link DIR-816 A2 v1.10CNB05 contenía un Desbordamiento del Búfer mediante el parámetro macCloneMac en setMAC.

Se descubrió que D-Link DIR-816 A2 v1.10CNB05 contenía un Desbordamiento del Búfer mediante el parámetro nvmacaddr en form2Dhcpip.cgi.

Se descubrió que D-Link DIR-816 A2 v1.10CNB05 contenía un Desbordamiento del Búfer a través del parámetro flag_5G en showMACfilterMAC.

Se descubrió que D-Link DIR-816 A2 v1.10CNB05 contenía un Desbordamiento del Búfer a través del parámetro sip_address en ipportFilter.