いくつかの「SDDisk2k.sys」ドライバの[IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes)サービスハンドラをリバースエンジニアリングしたところ、そのうちの1つが、任意のドライブの生ディスクセクタの読み取りおよび書き込み操作を可能にする重要な機能を、設計上ユーザーモードに公開していることが判明した。さらに、このコードとインターフェイスを介してやり取りすることで、このドライバが、ドライブ上で以前に設定された可能性のある排他ロックを無視することも確認された。その結果、同時の読み取り/書き込み操作が可能になり、競合状態を引き起こし、データ損失のリスクを招く。

以下は、生ディスクセクタの読み取り要求を処理する、ドライバの逆コンパイルされたIOCTLサービスハンドラを示している。これは「controlled_buf」という引数を指定して関数 sub_29CD4() を呼び出す。この引数は、任意の呼び出し元ユーザーモードアプリケーションが内容を自由に選択できるバッファへのポインタである:``` 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)を除いて、このコンテキストでの悪用にはディスク読み取り/書き込み操作による追加の回り道が必要であり、これは私が汚いアプローチと見なして回避したいと考えていたものです。しかしながら、特定のハンドラが1つ特定されました。確かにデータ自体を制御することはできませんでしたが、それでも他の手段で再利用するのに十分優れていることが判明しました。

以下の逆コンパイルされたコードは、IOCTLコード0x8d1f282cに対するドライバのサービスハンドラを示しています。ユーザー制御のバッファから16ビット整数の数値 "count" を取得し、特定の制限を超えないようにします。最後に、ポインタ "dst" は同じ制御された入力バッファから取得されますが、その後の memmove() 呼び出しに引数として渡される前に有効性がチェックされることはありません。最初は残念に思いましたが、memmove() に引数として渡される "src" バッファは制御されず、ハードコードされた文字列 ("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 ドライバーに、プロセス トークンの SEP_TOKEN_PRIVILEGES 構造体へバージョン文字列 "FRNSecureDoc v4.1\0" の一部を保存するよう丁寧に依頼すると、いくつかのビットが反転し、少なくとも仮説上は有用な特権が有効になることが期待できます。実際には、ドライバーにバージョン文字列の最初の 2 文字を SEP_TOKEN_PRIVILEGE 構造体の "Present" フィールドのオフセット 1 と 2 に保存させることで、多数の興味深いトークン特権が設定されます。"**F**RNSecureDoc v4.1\0" から取られた '**F**' 文字は 01000110 に等しく、したがって "Present" フィールドのビット 9 (SeTakeOwnershipPrivilege)、ビット 10 (SeLoadDriverPrivilege)、ビット 14 (SeIncreaseBasePriorityPrivilege) を設定します。'**R**' 文字は 01010010 に等しく、ビット 17 (SeBackupPrivilege)、ビット 20 (SeDebugPrivilege)、ビット 22 (SeSystemEnvironmentPrivilege) を設定します:

| ビット番号 ("Present") | 文字 | バイト         | 特権 |
| :--------------: | :-------: | ------------ | --------- |
| 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 |

## 概念実証エクスプロイト
[概念実証エクスプロイト](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) は Python で開発され、x64 Windows 10 VM に接続された [Microsoft の WinDbg カーネル デバッガー](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk) の助けを借りてデバッグされました。

この 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)にあります。これはWinmagic SecureDoc x64のv8.5を対象としていますが、古いバージョンでも動作する可能性があります（未テスト）。

ここまでたどり着いたものの、まだとても退屈している場合は、遠慮なく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. [Windows 8.1 での CVE-2014-4113 の悪用](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. [ctypesを使用したNtQuerySystemInformationの呼び出しに関するSourceforgeのディスカッション](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [SecureDoc v8.5SR2 リリースノート](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)