Nach der Reverse-Engineering einer Reihe von IOCTL-Service-Handlern des Treibers "SDDisk2k.sys" wurde festgestellt, dass einer von ihnen kritische Funktionalität für den Benutzermodus bereitstellt, indem er Lese- und Schreibvorgänge auf den Rohdatenträgersektoren eines beliebigen Laufwerks ermöglicht – und das absichtlich. Darüber hinaus wurde bei der Interaktion mit ebendiesem Code festgestellt, dass der Treiber alle exklusiven Sperren ignoriert, die möglicherweise zuvor auf einem Laufwerk gesetzt wurden. Infolgedessen werden gleichzeitige Lese-/Schreibvorgänge ermöglicht, was Race Conditions begünstigt und Datenverlust riskiert.

Das Folgende zeigt den dekompilierten IOCTL-Service-Handler des Treibers, der für die Bearbeitung von Leseanforderungen roher Datenträgersektoren zuständig ist. Er ruft eine Funktion sub_29CD4() mit einem Argument "controlled_buf" auf, bei dem es sich um einen Zeiger auf einen Puffer handelt, dessen Inhalt von jeder aufrufenden Benutzermodusanwendung beliebig gewählt werden kann:``` 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);

Just like reading raw disk sectors, writing disk sectors from user mode is made possible by calling IOCTL handler 0x8D1F2820, which processes the same data structure and is implemented in a similar fashion. Given compatibility with this driver's protocol, there is nothing that will prevent arbitray user mode applications from completely compromising the Operating System. Unless protected by a secure boot mechanism, this even includes installation of software that is allowed to run as early as during the system's boot process (ransomware, bootkits, custom implants...).

### CVE-2020-11520
Further examination of the "SDDisk2k.sys" driver's service handlers revealed that memory addresses from user mode applications are processed without prior validation. In some cases, memory accessed by these pointers is blindly written to by the driver, which can be abused by attackers to create kernel write primitives. Whereas all of the write primitives allow direct control of **where** to write data to, unfortunately none was found that'd allow direct control of **what** data to write. With the exception of [CVE-2020-11519](#cve-2020-11519), whose exploitation in this context would require an additional detour through disk read/write operations, which is something I consider a dirty approach and thus wanted to avoid. However, one particular handler was identified that admittedly didn't allow the data itself to be controlled but still turned out to be good enough for being repurposed by other means.

The below decompiled code shows the driver's service handler for IOCTL code 0x8d1f282c. It takes a 16bit integer number "count" from a user-controlled buffer, then ensures it won't exceed a certain limit. Finally, a pointer "dst" is acquired from the very same controlled input buffer, but isn't ever going to be checked for validity before it is passed as an argument to a subsequent call to memmove(). To my initial disappointment, the "src" buffer that is passed as an argument to memmove() isn't controlled but instead points to a hardcoded string ("FRNSecureDoc v4.1\0"), which limits its usefulness for exploitation to a certain degree. Obviously, this service handler writes a version identifier into a user-specifiable address, which may just as well be abused for fingerprinting vulnerable versions of 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;

Die SEP_TOKEN_PRIVILEGES-Struktur ist eine Reihe von Bitmasken, bei denen jedes einzelne Bit ein Berechtigungsflag darstellt. Als logische Konsequenz sollte die freundliche Aufforderung an den SecureDoc-Treiber, Teile seines Versionsstrings "FRNSecureDoc v4.1\0" in die SEP_TOKEN_PRIVILEGES-Struktur eines Prozess-Tokens zu speichern, einige Bits umdrehen und hoffentlich nützliche Berechtigungen aktivieren, zumindest hypothetisch. Wie sich herausstellt, werden durch das Speichern der ersten beiden Zeichen des Versionsstrings an den Offsets 1 und 2 des "Present"-Feldes der SEP_TOKEN_PRIVILEGE-Struktur eine Reihe interessanter Token-Berechtigungen gesetzt. Das '**F**'-Zeichen aus "**F**RNSecureDoc v4.1\0" entspricht 01000110 und setzt daher Bit 9 (SeTakeOwnershipPrivilege), Bit 10 (SeLoadDriverPrivilege) und Bit 14 (SeIncreaseBasePriorityPrivilege) des "Present"-Feldes. Das '**R**'-Zeichen entspricht 01010010 und setzt Bit 17 (SeBackupPrivilege), Bit 20 (SeDebugPrivilege) und Bit 22 (SeSystemEnvironmentPrivilege):

| Bit-Nr. ("Present") | Zeichen | Byte | Berechtigung |
| :--------------: | :-------: | ------------ | --------- |
| 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 |

## Proof-of-Concept Exploit
Ein [Proof-of-Concept-Exploit](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) wurde in Python entwickelt und mit Hilfe des [Microsoft-WinDbg-Kernel-Debuggers](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk) an einer x64 Windows 10 VM debuggt.

Dieser PoC-Exploit erhält die Kernel-Adresse des Sicherheitstokens des aktuellen Prozesses und aktiviert unter anderem die SeDebugPrivilege-Berechtigung durch Ausnutzung der beschriebenen Schwachstellen. Anschließend wird eine Befehlsshell gestartet, die die neu erhöhten Berechtigungen des Tokens erbt.

Wenn das SeDebugPrivilege-Flag gesetzt ist, wird es möglich sein, Shellcode in den Kontext eines SYSTEM-Prozesses zu injizieren und auszuführen – diesen Teil überlasse ich jedoch Ihnen ;)``` 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")

Der PoC-Exploit-Code ist [hier](https://github.com/patois/winmagic_sd/blob/HEAD/sd_poc.py) zu finden. Er zielt auf v8.5 von Winmagic SecureDoc x64 ab, könnte aber auch auf älteren Versionen funktionieren (nicht getestet).

Falls du es bis hierher geschafft hast, aber immer noch extrem gelangweilt bist, kannst du gerne den IOCTL-Code 0x8D1F2848 wählen ;)``` 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);
  }

## Lösung
Aktualisieren Sie auf Winmagic SecureDoc v8.5 SR2 HF1.

## Prüfsummen
| Dateiname             | Version | Hash (SHA-256) |
| -------------------- | ------- | -------------- |
| SDDisk2k.sys (64bit) | 8.3.717 | 98D29D28BB9552D20BC78EB0BD12A57B921167565F3E47919EC2D61F24DA9241 |
| SDDisk2k.sys (64bit) | 8.5.445 | 1D9054C4B49267EEF63B2EB11EC563E036F9E6E2AC18D32597FA769934BB7E18 |

## Referenzen
1. [Missbrauch von Token-Berechtigungen für LPE](https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt)
2. [Ausnutzen von CVE-2014-4113 unter Windows 8.1](http://jodeit.org/research/Exploiting_CVE-2014-4113_on_Windows_8.1.pdf)
3. [Einfache lokale Windows-Kernel-Ausnutzung](https://media.blackhat.com/bh-us-12/Briefings/Cerrudo/BH_US_12_Cerrudo_Windows_Kernel_WP.pdf)
4. [Ich habe 99 Probleme, aber ein Kernel-Pointer ist keins](https://recon.cx/2013/slides/Recon2013-Alex%20Ionescu-I%20got%2099%20problems%20but%20a%20kernel%20pointer%20ain%27t%20one.pdf)
5. [Ausnutzen von durchgesickerten Prozess- und Thread-Handles](http://dronesec.pw/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/)
6. [Sourceforge-Diskussion zum Aufruf von NtQuerySystemInformation mit ctypes](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [Versionshinweise zu SecureDoc v8.5SR2](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)