Ao reverter a engenharia de vários manipuladores de serviço [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) do driver "SDDisk2k.sys", descobriu-se que um deles expõe funcionalidades críticas ao modo de usuário, permitindo operações de leitura e gravação em setores brutos de disco de uma unidade arbitrária — por design. Além disso, ao interagir com esse mesmo código, notou-se que o driver ignora quaisquer bloqueios exclusivos que possam ter sido definidos anteriormente em uma unidade. Como consequência, operações concorrentes de leitura/gravação são possíveis, o que facilita condições de corrida e riscos de perda de dados.

O trecho a seguir mostra o manipulador de serviço IOCTL descompilado do driver que é responsável por tratar requisições de leitura de setores brutos de disco. Ele chama uma função sub_29CD4() com um argumento "controlled_buf", que é um ponteiro para um buffer cujo conteúdo pode ser escolhido arbitrariamente por qualquer aplicação em modo de usuário que o chame:``` 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);

Assim como a leitura de setores brutos do disco, a gravação de setores do disco a partir do modo de usuário é possibilitada pela chamada do manipulador IOCTL 0x8D1F2820, que processa a mesma estrutura de dados e é implementada de maneira semelhante. Dada a compatibilidade com o protocolo deste driver, não há nada que impeça aplicações arbitrárias do modo de usuário de comprometer completamente o Sistema Operacional. A menos que protegido por um mecanismo de boot seguro, isso inclui até mesmo a instalação de software que é permitido executar durante o processo de inicialização do sistema (ransomware, bootkits, implantes personalizados...).

### CVE-2020-11520
Um exame mais aprofundado dos manipuladores de serviço do driver "SDDisk2k.sys" revelou que endereços de memória de aplicações em modo de usuário são processados sem validação prévia. Em alguns casos, a memória acessada por esses ponteiros é cegamente escrita pelo driver, o que pode ser abusado por atacantes para criar primitivas de escrita no kernel. Embora todas as primitivas de escrita permitam controle direto de **onde** escrever dados, infelizmente nenhuma foi encontrada que permitisse controle direto de **quais** dados escrever. Com exceção de [CVE-2020-11519](#cve-2020-11519), cuja exploração neste contexto exigiria um desvio adicional através de operações de leitura/gravação de disco, o que considero uma abordagem suja e, portanto, queria evitar. No entanto, um manipulador específico foi identificado que, admitidamente, não permitia controlar os dados em si, mas ainda assim se mostrou bom o suficiente para ser reaproveitado por outros meios.

O código descompilado abaixo mostra o manipulador de serviço do driver para o código IOCTL 0x8d1f282c. Ele recebe um número inteiro de 16 bits "count" de um buffer controlado pelo usuário, em seguida, garante que não exceda um certo limite. Finalmente, um ponteiro "dst" é adquirido do mesmo buffer de entrada controlado, mas nunca será verificado quanto à validade antes de ser passado como argumento para uma chamada subsequente a memmove(). Para minha decepção inicial, o buffer "src" que é passado como argumento para memmove() não é controlado, mas aponta para uma string fixa ("FRNSecureDoc v4.1\0"), o que limita sua utilidade para exploração até certo ponto. Obviamente, este manipulador de serviço escreve um identificador de versão em um endereço especificável pelo usuário, o que pode ser abusado para fingerprinting de versões vulneráveis do 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;

A estrutura SEP_TOKEN_PRIVILEGES é um conjunto de máscaras de bits com bits individuais representando cada um uma flag de privilégio. Como consequência lógica, solicitar amigavelmente ao driver SecureDoc que armazene partes da sua string de versão "FRNSecureDoc v4.1\0" na estrutura SEP_TOKEN_PRIVILEGES de um token de processo deve inverter alguns bits e, esperançosamente, ativar privilégios úteis, pelo menos hipoteticamente. Acontece que, ao fazer com que o driver armazene os dois primeiros caracteres da sua string de versão nos offsets 1 e 2 do campo "Present" da estrutura SEP_TOKEN_PRIVILEGES, vários privilégios interessantes do token são ativados. O caractere '**F**' retirado de "**F**RNSecureDoc v4.1\0" é igual a 01000110 e, portanto, define o bit 9 (SeTakeOwnershipPrivilege), o bit 10 (SeLoadDriverPrivilege) e o bit 14 (SeIncreaseBasePriorityPrivilege) do campo "Present". O caractere '**R**' é igual a 01010010, definindo o bit 17 (SeBackupPrivilege), o bit 20 (SeDebugPrivilege) e o bit 22 (SeSystemEnvironmentPrivilege):

| Nº do bit ("Present") | Caractere | Byte         | Privilégio |
| :--------------: | :-------: | ------------ | --------- |
| 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 Prova de Conceito
Um [exploit de prova de conceito](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) foi desenvolvido em Python e depurado com a ajuda do [depurador de kernel WinDbg da Microsoft](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk) anexado a uma VM Windows 10 x64.

Este exploit PoC adquire o endereço do kernel do token de segurança do processo atual e, entre outros, ativa o privilégio SeDebugPrivilege ao explorar as vulnerabilidades descritas. Em seguida, cria um shell de comando que herda os privilégios recém-elevados do token.

Ter a flag SeDebugPrivilege ativada tornará possível injetar shellcode e executá-lo no contexto de um processo SYSTEM – no entanto, deixo esta parte para você ;)``` 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")

O código de exploração PoC pode ser encontrado [aqui](https://github.com/patois/winmagic_sd/blob/HEAD/sd_poc.py). Ele tem como alvo a versão 8.5 do Winmagic SecureDoc x64, mas pode funcionar em versões mais antigas (não testado).

Caso você tenha chegado até aqui, mas ainda esteja muito entediado, sinta-se à vontade para discar o 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);
  }

## Solução
Atualize para o Winmagic SecureDoc v8.5 SR2 HF1.

## Somas de verificação
| Nome do arquivo         | Versão   | Hash (SHA-256)                                                   |
| ----------------------- | -------- | ---------------------------------------------------------------- |
| SDDisk2k.sys (64bit)    | 8.3.717  | 98D29D28BB9552D20BC78EB0BD12A57B921167565F3E47919EC2D61F24DA9241 |
| SDDisk2k.sys (64bit)    | 8.5.445  | 1D9054C4B49267EEF63B2EB11EC563E036F9E6E2AC18D32597FA769934BB7E18 |

## Referências
1. [Abusando de privilégios de token para LPE](https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt)
2. [Explorando CVE-2014-4113 no Windows 8.1](http://jodeit.org/research/Exploiting_CVE-2014-4113_on_Windows_8.1.pdf)
3. [Exploração fácil do kernel do Windows local](https://media.blackhat.com/bh-us-12/Briefings/Cerrudo/BH_US_12_Cerrudo_Windows_Kernel_WP.pdf)
4. [Tenho 99 problemas, mas um ponteiro de kernel não é um](https://recon.cx/2013/slides/Recon2013-Alex%20Ionescu-I%20got%2099%20problems%20but%20a%20kernel%20pointer%20ain%27t%20one.pdf)
5. [Explorando handles de processo e thread vazados](http://dronesec.pw/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/)
6. [Discussão no Sourceforge sobre chamar NtQuerySystemInformation usando ctypes](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [Notas de versão do SecureDoc v8.5SR2](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)