patois/winmagic_sdInforme técnico sobre y Exploit de PoC para CVE-2020-11519 y CVE-2020-11520
Fecha: Junio de 2020
Autor: Dennis Elser (código: github)
En referencia a su representación web, Winmagic SecureDoc "permite a las empresas gestionar la seguridad de su entorno de TI de manera eficiente aprovechando características que incluyen: Cifrado Completo de Disco (FDE), Autenticación Multifactor, Cifrado de Contenedores de Medios Extraíbles (RMCE) y Cifrado de Archivos y Carpetas (FFE). Estas características ayudan a las empresas a aumentar la seguridad, mitigar el riesgo empresarial y cumplir con los requisitos gubernamentales y regulatorios para el cifrado de discos duros."
El producto Winmagic SecureDoc, que está disponible en versiones independientes y empresariales, se ve afectado por dos vulnerabilidades de escalada de privilegios locales (CVE-2020-11519 y CVE-2020-11520) en las versiones 8.3 y 8.5. Después de que las vulnerabilidades fueran reportadas a Winmagic a finales de marzo, el proveedor lanzó un parche (versión 8.5SR2) a mediados de junio de 2020. Sin embargo, se encontró que este parche abordaba las vulnerabilidades de manera insuficiente, lo que también hizo que la versión 8.5SR2 fuera vulnerable a las fallas reportadas. Aunque los detalles técnicos sobre las vulnerabilidades se habían retenido por esta razón, las fallas deben considerarse públicas desde entonces. Según el proveedor, otro parche estaba en proceso, aproximadamente 106 días después del informe inicial de vulnerabilidad a Winmagic. El 15 de julio, 111 días después del informe inicial de vulnerabilidad al proveedor, Winmagic lanzó SecureDoc v8.5 SR2 HF1 a los clientes, que según informes corrige CVE-2020-11519 y CVE-2020-11520. Las versiones de SecureDoc anteriores a la 8.3 no han sido probadas pero se puede asumir que también están afectadas, según el código del componente afectado.
La explotación exitosa de cualquiera de las vulnerabilidades conducirá a una escalada de privilegios a SYSTEM para atacantes autenticados localmente.
Ambas vulnerabilidades afectan al componente "SDDisk2k.sys", un controlador de kernel que viene con el producto Winmagic SecureDoc. Las fallas de seguridad se identificaron mediante análisis estático manual con la ayuda del desensamblador y descompilador Hex-Rays IDA Pro. En retrospectiva, las debilidades podrían haberse descubierto con mucho menos esfuerzo si se hubieran aplicado enfoques de prueba dinámicos como el fuzzing. Esto se debe a que se puede interactuar con el controlador desde aplicaciones de modo usuario limitadas y porque asume que su entrada está bien formada por defecto.
Debido a la creación insegura por parte del controlador "SDDisk2k.sys" de un objeto de dispositivo "SecureDocDevice" y la falta de código que establezca un descriptor de seguridad apropiado, incluso cuentas de usuario limitadas tienen la capacidad de adquirir un identificador al dispositivo mediante la función API CreateFile(). Al otorgar el controlador a una aplicación de modo usuario un identificador a su objeto de dispositivo, abre así una ruta directa a su superficie de ataque en el espacio del kernel.``` c RtlInitUnicodeString(&DestinationString, L"\Device\SecureDocDevice"); RtlInitUnicodeString(&SymbolicLinkName, L"\DosDevices\SecureDocDevice"); if ( IoCreateDevice(v1, 0xDD8u, &DestinationString, 0x8D1Fu, 0, 0, &DeviceObject) >= 0 ) // <--- unsafe { memset(DeviceObject->DeviceExtension, 0, 0xDD8ui64); DeviceObject->Flags |= 4u; DeviceObject->AlignmentRequirement = 0; if ( IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString) < 0 ) IoDeleteDevice(DeviceObject); IoObject = DeviceObject; }
Al haber realizado ingeniería inversa a varios de los controladores de servicio de [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) del driver "SDDisk2k.sys", se descubrió que uno de ellos expone funcionalidad crítica al modo usuario, ya que permite operaciones de lectura y escritura de sectores de disco en bruto de una unidad arbitraria, por diseño. A esto se suma que, al interactuar con este mismo código, se observó que el driver ignora cualquier bloqueo exclusivo que pudiera haberse establecido previamente en una unidad. Como consecuencia, se hacen posibles operaciones concurrentes de lectura/escritura, lo que facilita condiciones de carrera y riesgo de pérdida de datos.