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.

A continuación se muestra el controlador de servicio IOCTL descompilado del driver, responsable de manejar las solicitudes de lectura de sectores de disco en bruto. Llama a una función sub_29CD4() con un argumento "controlled_buf", que es un puntero a un buffer cuyo contenido puede ser elegido arbitrariamente por cualquier aplicación en modo usuario que lo invoque:``` c
if ( ioctlcode == 0x8D1F2824 )   // <--- I/O control code for raw disk reading functionality
{
  controlled_buf = (unsigned __int8 *)controlled_addr;
  mode = 0;
  temp_result = sub_29CD4((char *)controlled_buf, v3, mode);   // <--- call to raw disk read function

// get object pointer of drive
if ( IoGetDeviceObjectPointer(&DestinationString, 0x80u, &FileObject, &DeviceObject) >= 0
  || (v12 = sub_2C5D4(&DestinationString, &DeviceObject), v12 >= 0) )
{
  // extract further fields from structure
  offset = *(_QWORD *)(p + 0x4E);                    // <--- where to start reading from
  length = *(_DWORD *)(p + 0x56);                    // <--- number of bytes to read
  ptr_buf = *(void **)(p + 0x5A);                    // <--- ptr to destination buffer
  devobj = DeviceObject;
  StartingOffset.QuadPart = offset << 9;
  KeInitializeEvent(&Event, NotificationEvent, 0);
  
  // build request
  v17 = IoBuildSynchronousFsdRequest(
          (unsigned int)(mode != 0) + IRP_MJ_READ,   // <--- issue read request
          devobj,
          ptr_buf,
          length << 9,
          &StartingOffset,
          &Event,
          &IoStatusBlock);
  v18 = v17;
  if ( v17 )
  {
    v19 = v17->Tail.Overlay.CurrentStackLocation;
    if ( mode )
      v19[0xFFFFFFFF].Flags |= 0x10u;
    ObfReferenceObject(devobj);

    // send request to respective device object (issue read request)
    v12 = IofCallDriver(devobj, v18);

Así como la lectura de sectores de disco en bruto, la escritura de sectores de disco desde el modo de usuario es posible llamando al manejador de IOCTL 0x8D1F2820, que procesa la misma estructura de datos y está implementado de manera similar. Dada la compatibilidad con el protocolo de este controlador, no hay nada que impida que aplicaciones arbitrarias en modo de usuario comprometan por completo el Sistema Operativo. A menos que esté protegido por un mecanismo de arranque seguro, esto incluye incluso la instalación de software que puede ejecutarse tan temprano como durante el proceso de arranque del sistema (ransomware, bootkits, implantes personalizados...).

### CVE-2020-11520
Un examen más profundo de los manejadores de servicio del controlador "SDDisk2k.sys" reveló que las direcciones de memoria de las aplicaciones en modo de usuario se procesan sin validación previa. En algunos casos, la memoria a la que acceden estos punteros es escrita ciegamente por el controlador, lo que puede ser aprovechado por atacantes para crear primitivas de escritura en kernel. Si bien todas las primitivas de escritura permiten el control directo de **dónde** escribir datos, desafortunadamente no se encontró ninguna que permitiera el control directo de **qué** datos escribir. Con la excepción de [CVE-2020-11519](#cve-2020-11519), cuya explotación en este contexto requeriría un desvío adicional a través de operaciones de lectura/escritura de disco, lo cual considero un enfoque sucio y por lo tanto quería evitar. Sin embargo, se identificó un manejador particular que, si bien no permitía controlar los datos en sí, resultó ser lo suficientemente bueno para ser reutilizado por otros medios.

El código descompilado a continuación muestra el manejador de servicio del controlador para el código IOCTL 0x8d1f282c. Toma un número entero de 16 bits "count" de un búfer controlado por el usuario, luego se asegura de que no exceda un cierto límite. Finalmente, se obtiene un puntero "dst" del mismo búfer de entrada controlado, pero nunca se verifica su validez antes de pasarlo como argumento a una llamada posterior a memmove(). Para mi decepción inicial, el búfer "src" que se pasa como argumento a memmove() no está controlado, sino que apunta a una cadena hardcodeada ("FRNSecureDoc v4.1\0"), lo que limita su utilidad para la explotación hasta cierto punto. Obviamente, este manejador de servicio escribe un identificador de versión en una dirección especificable por el usuario, lo que también podría ser aprovechado para identificar versiones vulnerables de Winmagic SecurDoc.``` c
// handler for I/O control code 0x8d1f282c

// get "count" from controlled buffer
count = *((_WORD *)controlled_buf + 5);

// if count is zero, return error
if ( !count )
{
  *((_WORD *)controlled_buf + 5) = 0x13;
  goto leave_dispatcher;
}

// otherwise further sanitize and limit "count"
if ( count >= 0x12u )
  count = 0x11;

// bug! controlled pointer, passed from userland!
dst = *(void **)(controlled_buf + 2);
src = aFrnsecuredocV4;   // <--- 'FRNSecureDoc v4.1',0

// unchecked write!
memmove(dst, src, count);
goto leave_dispatcher;

La estructura `SEP_TOKEN_PRIVILEGES` es un conjunto de máscaras de bits donde cada bit individual representa una bandera de privilegio. Como consecuencia lógica, pedir amablemente al driver de SecureDoc que almacene partes de su cadena de versión "FRNSecureDoc v4.1\0" en la estructura `SEP_TOKEN_PRIVILEGES` de un token de proceso debería invertir algunos bits y, con suerte, habilitar privilegios útiles, al menos hipotéticamente. Resulta que, al hacer que el driver almacene los dos primeros caracteres de su cadena de versión en los offsets 1 y 2 del campo "Present" de la estructura `SEP_TOKEN_PRIVILEGES`, se establecen varios privilegios de token interesantes. El carácter '**F**' tomado de "**F**RNSecureDoc v4.1\0" equivale a 01000110 y, por lo tanto, establece el bit 9 (SeTakeOwnershipPrivilege), el bit 10 (SeLoadDriverPrivilege) y el bit 14 (SeIncreaseBasePriorityPrivilege) del campo "Present". El carácter '**R**' equivale a 01010010, estableciendo el bit 17 (SeBackupPrivilege), el bit 20 (SeDebugPrivilege) y el bit 22 (SeSystemEnvironmentPrivilege):

| Bit No ("Present") | Character | Byte         | Privilege |
| :--------------: | :-------: | ------------ | --------- |
| 8                | 'F'       | 0100011**0** | SeSecurityPrivilege |
| 9                | 'F'       | 010001**1**0 | **SeTakeOwnershipPrivilege** |
| 10               | 'F'       | 01000**1**10 | **SeLoadDriverPrivilege** |
| 11               | 'F'       | 0100**0**110 | SeSystemProfilePrivilege |
| 12               | 'F'       | 010**0**0110 | SeSystemtimePrivilege |
| 13               | 'F'       | 01**0**00110 | SeProfileSingleProcessPrivilege |
| 14               | 'F'       | 0**1**000110 | **SeIncreaseBasePriorityPrivilege** |
| 15               | 'F'       | **0**1000110 | SeCreatePagefilePrivilege |
| 16               | 'R'       | 0101001**0** | SeCreatePermanentPrivilege |
| 17               | 'R'       | 010100**1**0 | **SeBackupPrivilege** |
| 18               | 'R'       | 01010**0**10 | SeRestorePrivilege |
| 19               | 'R'       | 0101**0**010 | SeShutdownPrivilege |
| 20               | 'R'       | 010**1**0010 | **SeDebugPrivilege** |
| 21               | 'R'       | 01**0**10010 | SeAuditPrivilege |
| 22               | 'R'       | 0**1**010010 | **SeSystemEnvironmentPrivilege** |
| 23               | 'R'       | **0**1010010 | SeChangeNotifyPrivilege |

## Exploit de Prueba de Concepto
Se ha desarrollado un [exploit de prueba de concepto](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) en Python y se ha depurado con la ayuda del [depurador de kernel WinDbg de Microsoft](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk) conectado a una máquina virtual Windows 10 x64.

Este exploit PoC obtiene la dirección del kernel del token de seguridad del proceso actual y, entre otros, habilita el privilegio SeDebugPrivilege explotando las vulnerabilidades descritas. Luego procede a generar un shell de comandos que hereda los privilegios recién escalados del token.

Tener la bandera SeDebugPrivilege activa hará posible que se inyecte y ejecute shellcode en el contexto de un proceso SYSTEM - esto lo dejo a tu criterio ;)``` python
token_addr = sdi.get_token_obj()
if not token_addr:
    print("[!] Could not get address of token")
    sdi.close()
    return

print("[+] Got token object: %x" % token_addr)
print("[+] Patching token")
sdi.acquire_debug_privs(token_addr)
sdi.close()

os.system("cmd.exe")

El código de exploit PoC se puede encontrar [aquí](https://github.com/patois/winmagic_sd/blob/HEAD/sd_poc.py). Está dirigido a v8.5 de Winmagic SecureDoc x64, pero podría funcionar en versiones anteriores (no probado).

En caso de que hayas llegado hasta aquí pero todavía estés muy aburrido, siéntete libre de marcar el código IOCTL 0x8D1F2848 ;)``` c
case 0x8D1F2848:
  DbgPrint("SDDEV_IO_BLUE_SCREEN comes in ...");
  if ( *(_WORD *)controlled_buf == 0x55AA
    && *(_QWORD *)(controlled_buf + 2)
    && *((_WORD *)controlled_buf + 5) == 4 )
  {
    StartContext = ExAllocatePoolWithTag(PoolType, 4ui64, 'gaMW');
    if ( !StartContext )
    {
      KeSetPriorityThread(KeGetCurrentThread(), 0x1F);
      KeBugCheckEx(0xE2u, 0x2D8ui64, **(unsigned int **)(controlled_buf + 2), 0i64, 'WM');
    }
    DbgPrint("SDDEV_IO_BLUE_SCREEN preps ...");
    *StartContext = **(_DWORD **)(controlled_buf + 2);
    if ( PsCreateSystemThread(
            &ThreadHandle,
            0x1FFFFFu,
            0i64,
            0i64,
            0i64,
            (PKSTART_ROUTINE)sub_23948,
            StartContext) < 0 )
      ExFreePoolWithTag(StartContext, 0);
    else
      ZwClose(ThreadHandle);
  }

## Solución
Actualizar a Winmagic SecureDoc v8.5 SR2 HF1.

## Sumas de verificación
| Nombre de archivo       | Versión | Hash (SHA-256) |
| -------------------- | ------- | -------------- |
| SDDisk2k.sys (64bit) | 8.3.717 | 98D29D28BB9552D20BC78EB0BD12A57B921167565F3E47919EC2D61F24DA9241 |
| SDDisk2k.sys (64bit) | 8.5.445 | 1D9054C4B49267EEF63B2EB11EC563E036F9E6E2AC18D32597FA769934BB7E18 |

## Referencias
1. [Abusando de privilegios de token para LPE](https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt)
2. [Explotando CVE-2014-4113 en Windows 8.1](http://jodeit.org/research/Exploiting_CVE-2014-4113_on_Windows_8.1.pdf)
3. [Explotación fácil del kernel de Windows local](https://media.blackhat.com/bh-us-12/Briefings/Cerrudo/BH_US_12_Cerrudo_Windows_Kernel_WP.pdf)
4. [Tengo 99 problemas pero un puntero del kernel no es uno](https://recon.cx/2013/slides/Recon2013-Alex%20Ionescu-I%20got%2099%20problems%20but%20a%20kernel%20pointer%20ain%27t%20one.pdf)
5. [Explotando manejadores de procesos e hilos filtrados](http://dronesec.pw/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/)
6. [Discusión en Sourceforge sobre llamar a NtQuerySystemInformation usando ctypes](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [Notas de lanzamiento de SecureDoc v8.5SR2](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)