CVE-2020-11519 および CVE-2020-11520 に関する技術レポート

日付: 2020年6月

著者: Dennis Elser (コード: github)

はじめに

そのウェブサイトによると、Winmagic SecureDoc は「フルディスク暗号化 (FDE)、多要素認証、リムーバブルメディアコンテナ暗号化 (RMCE)、ファイルおよびフォルダー暗号化 (FFE) などの機能を効率的に活用することで、企業が IT 環境のセキュリティに対処できるようにします。これらの機能は、企業のセキュリティ強化、ビジネスリスクの軽減、ハードドライブ暗号化に関する政府および規制要件への適合に役立ちます。」

Winmagic SecureDoc 製品は、スタンドアロン版とエンタープライズ版で提供されており、バージョン 8.3 および 8.5 において、2 つのローカル権限昇格の脆弱性 (CVE-2020-11519 および CVE-2020-11520) の影響を受けます。脆弱性が 3 月下旬に Winmagic に報告された後、ベンダーは 2020年6月中旬にパッチ (バージョン 8.5SR2) をリリースしました。しかし、このパッチでは脆弱性を十分に対処できないことが判明し、8.5SR2 も報告された欠陥に対して脆弱な状態となりました。このため、脆弱性に関する技術的詳細は伏せられていましたが、それ以降、これらの欠陥は公開されたものと見なさざるを得ません。~~ベンダーによると、Winmagic への最初の脆弱性報告からおよそ 106 日後になっても、別のパッチがまだ準備中です。~~ 7月15日、ベンダーへの最初の脆弱性報告から 111 日後に、Winmagic は SecureDoc v8.5 SR2 HF1 を顧客向けにリリースしました。これは CVE-2020-11519 および CVE-2020-11520 を修正するとのことです。8.3 より古いバージョンの SecureDoc はテストされていませんが、影響を受けるコンポーネントのコードに基づくと、同様に影響を受けると想定できます。

これらの脆弱性のいずれかを悪用すると、ローカルで認証された攻撃者に対し、SYSTEM への権限昇格がもたらされます。

アプローチと技術的説明

両方の脆弱性は、Winmagic SecureDoc 製品に含まれるカーネルドライバーである "SDDisk2k.sys" コンポーネントに影響します。セキュリティ上の欠陥は、Hex-Rays IDA Pro 逆アセンブラおよび逆コンパイラを用いた手動静的解析によって特定されました。振り返ってみると、これらの弱点は、代わりにファジングなどの動的テスト手法が適用されていれば、はるかに少ない労力で発見できたはずです。これは、このドライバーが制限されたユーザーモードアプリケーションからインターフェース接続できること、またデフォルトで入力が整形式であると想定しているためです。

CVE-2020-11519

"SDDisk2k.sys" ドライバーによる "SecureDocDevice" デバイスオブジェクトの安全でない作成と、適切なセキュリティ記述子を設定するコードの欠落により、制限されたユーザーアカウントでも、CreateFile() API 関数を使用してデバイスへのハンドルを取得できます。ドライバーがユーザーモードアプリケーションにデバイスオブジェクトへのハンドルを許可することにより、ここでカーネルランドの攻撃対象への直接経路が開かれます。``` c RtlInitUnicodeString(&DestinationString, L"\Device\SecureDocDevice"); RtlInitUnicodeString(&SymbolicLinkName, L"\DosDevices\SecureDocDevice"); if ( IoCreateDevice(v1, 0xDD8u, &DestinationString, 0x8D1Fu, 0, 0, &DeviceObject) >= 0 ) // <--- unsafe { memset(DeviceObject->DeviceExtension, 0, 0xDD8ui64); DeviceObject->Flags |= 4u; DeviceObject->AlignmentRequirement = 0; if ( IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString) < 0 ) IoDeleteDevice(DeviceObject); IoObject = DeviceObject; }

いくつかの「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

実際には、この攻撃者制御のバッファは構造体であり、そのフィールド "offset"、"length"、"ptr_buf" は、IoBuildSynchronousFsdRequest() の呼び出しに渡される完全にチェックされていない関数引数です。後者の関数は、IRP_MJ_READ I/O 要求パケット (IRP) を準備し、それを IofCallDriver() の呼び出しを使用して基盤となるファイルシステムドライバーに送信します:``` c __int64 __fastcall sub_29CD4(char *controlled_addr, PIRP a2, char mode) { //[...snip...] // extract drive number and type (floppy/hd) from offset 0 devicetype_and_num = (unsigned __int8)*controlled_buf // <--- controllable from user mode

// advance pointer p = controlled_buf + 1;

// build device name if ( (devicetype_and_num & 0x80u) == 0 ) v11 = vsnprintf_wrapper(&device_name, 0x3Fui64, L"\Device\Floppy%d", devicetype_and_num); else v11 = vsnprintf_wrapper(&device_name, 0x3Fui64, L"\Device\Harddisk%d\Partition0", devicetype_and_num & 0x7F); v12 = v11; if ( v11 >= 0 ) { RtlInitUnicodeString(&DestinationString, &device_name);

// 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);

//[...snip...] }

生のディスクセクタの読み取りと同様に、ユーザーモードからのディスクセクタの書き込みは、IOCTLハンドラ0x8D1F2820を呼び出すことで可能になります。これは同じデータ構造を処理し、同様の方法で実装されています。このドライバのプロトコルとの互換性を考慮すると、任意のユーザーモードアプリケーションがオペレーティングシステムを完全に危険にさらすことを防ぐものは何もありません。セキュアブート機構によって保護されていない限り、これにはシステムのブートプロセス中に早期に実行されることが許可されているソフトウェア（ランサムウェア、ブートキット、カスタムインプラント...）のインストールも含まれます。

### CVE-2020-11520

"SDDisk2k.sys" ドライバのサービスハンドラをさらに調査したところ、ユーザーモードアプリケーションからのメモリアドレスが事前検証なしに処理されることが明らかになりました。場合によっては、これらのポインタによってアクセスされるメモリはドライバによって盲目的に書き込まれ、攻撃者がカーネル書き込みプリミティブを作成するために悪用する可能性があります。すべての書き込みプリミティブはデータを書き込む**場所**を直接制御できますが、残念ながら、書き込む**データ**を直接制御できるものは見つかりませんでした。[CVE-2020-11519](#cve-2020-11519)を除いて、このコンテキストでの悪用にはディスク読み取り/書き込み操作による追加の回り道が必要であり、これは私が汚いアプローチと見なして回避したいと考えていたものです。しかしながら、特定のハンドラが1つ特定されました。確かにデータ自体を制御することはできませんでしたが、それでも他の手段で再利用するのに十分優れていることが判明しました。

winmagic_sd

人気

CVE-2020-11519 および CVE-2020-11520 に関する技術レポート

目次

はじめに

アプローチと技術的説明

CVE-2020-11519