Windowsメモリ内部解析サービス
豊田孝の「IT談話館」 Windowsメモリダンプ解析を依頼する WinDbgとシステム分析




 本「IT談話館」一般公開記事は、書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方を想定しています。



Windows 7/8/10、セキュリティー、Token、SD


 SaaS時代におけるWindows 10の頻繁なる内部更新は、性能向上と互換性維持などに加え、ML/DL/AI時代への対応と位置付けられています。簡単に表現すれば、Windows 10はCloudサービスと連携しながらBig Dataを収集・蓄積する「ソフトウェアセンサー」、という役割を担っています。本「IT談話館」は、そのソフトウェアセンサーのユーザー空間とカーネル空間を独自の解析コードで詳しく解析する技術を保有し、「Windowsメモリダンプ解析サービス」を提供しています。「本館サービス」をご利用の際には、所属チーム内でご協議の上、「ご連絡」頂けると幸いです。

 「メモリダンプ」を解析すると、採取時点におけるシステム内部の「異様な動き」を検出・解析することができます。「異様な動き」の中には、システムパフォーマンスの低下、既存アプリの動作異常、システムクラッシュ原因、あるいは、セキュリティー脅威なども含まれます。

 本「IT談話館」の「一般公開記事」は、「Active Memory Dump とカーネルメモリダンプ」の解析結果を基に起草され、0dayをはじめとする脆弱性研究者、組み込みシステム開発者、デジタルフォレンジック技術者、および、EDR製品のビジネス関係者に広く読まれています。公開はあくまでもビジネスに支障の出ない範囲に限定されていますが、それでも、インターネット空間上で容易に入手できるレベルの記事ではありません。

 現在、セキュリティー問題を無視することはできません。Microsoft社の技術者側の作業負担だけではなく、同社製品の利用者側の作業負担も増しています。困ったことではありますが、当面避けられません。セキュリティーの視点からWindows10ソフトウェアセンサーを見た場合、本「IT談話館」の確認範囲では、「カーネル層保護ロジック」に加え、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。
  1. Silo/Server Silo
  2. Job
  3. Session
  4. Protected Process
  5. Mandatory Integrity Control(MIC)
  6. Windows API(+CPU)
  7. CPU
 本稿では保護メカニズム階層内の比較的下位に位置する上記赤色のMICを取り上げます。米Microsoft社はこの「Mandatory Integrity Control(MIC)」ページからMIC情報を公開しています。概念的には、このメカニズムは次のような既存の概念を拡張・統合する方向で実装されています。  本館のこの別稿「Windows XP/7/8/10のセッションとプロセス」では、次のような条件に従って、システム内で動作中の各種Windowsプロセスを分類できることを紹介しています。  まずは、このプロセス分類条件を組み入れた解析ードを実行し、次のような情報を取得してみることにします。  実行結果を見てみましょう。
1: kd> vertarget
Windows 10 Kernel Version 10240 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10240.16463.amd64fre.th1.150819-1946
Machine Name:
Kernel base = 0xfffff800`6d404000 PsLoadedModuleList = 0xfffff800`6d729030
Debug session time: Thu Oct  1 08:57:05.915 2015 (UTC + 9:00)
System Uptime: 4 days 21:18:39.610


SessionId->0	System->0xFFFFE0001F2A8840
	MandatoryPolicy->1
	Token->0xFFFFC001EEC16A60
	SecurityDescriptor->0xFFFFC001EEC16510

SessionId->0	smss.exe->0xFFFFE0002090F040
	MandatoryPolicy->1
	Token->0xFFFFC001EFDA5590
	SecurityDescriptor->0xFFFFC001EEC16510

SessionId->0	csrss.exe->0xFFFFE00020E19840
	MandatoryPolicy->1
	Token->0xFFFFC001F11C9060
	SecurityDescriptor->0xFFFFC001F11C9ED0

SessionId->0	wininit.exe->0xFFFFE00020EB9080
	MandatoryPolicy->1
	Token->0xFFFFC001F1D5B060
	SecurityDescriptor->0xFFFFC001EEC16510

SessionId->0	services.exe->0xFFFFE00020ED9700
	MandatoryPolicy->1
	Token->0xFFFFC001F1DE0A10
	SecurityDescriptor->0xFFFFC001EEC16510

SessionId->0	lsass.exe->0xFFFFE00020F8C6C0
	MandatoryPolicy->1
	Token->0xFFFFC001F1D36060
	SecurityDescriptor->0xFFFFC001F1DE27C0

SessionId->0	svchost.exe->0xFFFFE00020E49840
	MandatoryPolicy->3
	Token->0xFFFFC001F0F318F0
	SecurityDescriptor->0xFFFFC001F0F2A640

        [---]

SessionId->1	chrome.exe->0xFFFFE000238545C0
	MandatoryPolicy->3
	Token->0xFFFFC001F5EDA960
	SecurityDescriptor->0xFFFFC001F7033C40

SessionId->1	chrome.exe->0xFFFFE0001FDED840
	MandatoryPolicy->3
	Token->0xFFFFC001F8B3A550
	SecurityDescriptor->0xFFFFC00200851720

SessionId->1	chrome.exe->0xFFFFE000200CE200
	MandatoryPolicy->3
	Token->0xFFFFC001F8A69940
	SecurityDescriptor->0xFFFFC00200851720

SessionId->1	chrome.exe->0xFFFFE0002002D840
	MandatoryPolicy->3
	Token->0xFFFFC001F7C69060
	SecurityDescriptor->0xFFFFC00200851720

        [---]
 実行結果を見ると、「SessionId->0」と「SessionId->1」という異なるセッションに所属するプロセスが存在します。先ほど紹介したプロセス分類条件に従えば、「SessionId->0」に所属するプロセスは、システムプロセスかサービスプロセスとなり、「SessionId->1」に所属するプロセスはユーザープロセスと解釈できます。セキュリティーの観点からは、「SessionId->0」所属プロセスは他のセッション所属のプロセスより多くのアクセス権限と保護制限を与えられているはずです。これは常識中の常識ですが、まずは、この常識を疑ってかかり、「SessionId->0」所属プロセスが与えられているこれらの特性を調査してみます。次の実行結果をご覧ください。
SessionId->0	System->0xFFFFE0001F2A8840
	MandatoryPolicy->1
	Token->0xFFFFC001EEC16A60
	SecurityDescriptor->0xFFFFC001EEC16510

SessionId->0	smss.exe->0xFFFFE0002090F040
	MandatoryPolicy->1
	Token->0xFFFFC001EFDA5590
	SecurityDescriptor->0xFFFFC001EEC16510

        [---]

SessionId->0	svchost.exe->0xFFFFE00021B7E840
	MandatoryPolicy->3
	Token->0xFFFFC001F1368060
	SecurityDescriptor->0xFFFFC001F1368F70

SessionId->0	WUDFHost.exe->0xFFFFE00021C84840
	MandatoryPolicy->3
	Token->0xFFFFC001F140F8D0
	SecurityDescriptor->0xFFFFC001F13BAB10

        [---]
 システムプロセスとサービスプロセスはセッション0に所属しますから、それぞれのトークンとSDを調査すれば、与えられているアクセス権限と保護制限を知ることができます。ここでは、赤色の2つのプロセスを調査してみます。
Systemプロセスのトークン

1: kd> !token -n 0xFFFFC001EEC16A60
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001eec16a60
TS Session ID: 0
User: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
User Groups: 
 00 S-1-5-32-544 (Alias: BUILTIN\Administrators)
    Attributes - Default Enabled Owner 
 01 S-1-1-0 (Well Known Group: localhost\Everyone)
    Attributes - Mandatory Default Enabled 
 02 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
    Attributes - Mandatory Default Enabled 
 03 S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
    Attributes - GroupIntegrity GroupIntegrityEnabled 
Primary Group: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

[---]
 この結果は、Systemプロセスが「システムプロセス」であり、後ほど触れる「System Mandatory Level」を示すSIDを持っていることを示しています。この「システムプロセス」のSD内容は次のようになっています。
SystemプロセスのSD

1: kd> !sd 0xFFFFC001EEC16510 1

[---]

->Sacl    : ->Ace[0]: ->Mask : 0x00000003
->Sacl    : ->Ace[0]: ->SID: S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
 ご覧のように、トークンと同じ「System Mandatory Level」を示すSIDを持っています。「Mask」に関しては、Mandatory Policyとともに後ほど説明します。次に、「WUDFHost.exe」プロセスのトークン内容を見てみます。  
WUDFHost.exeプロセスのトークン

1: kd> !token -n 0xFFFFC001F140F8D0
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001f140f8d0
TS Session ID: 0
User: S-1-5-19 (Well Known Group: NT AUTHORITY\LOCAL SERVICE)
User Groups: 
 00 S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
    Attributes - GroupIntegrity GroupIntegrityEnabled 
 01 S-1-1-0 (Well Known Group: localhost\Everyone)
    Attributes - Mandatory Default Enabled 
 02 S-1-5-32-545 (Alias: BUILTIN\Users)
    Attributes - Mandatory Default Enabled 
 03 S-1-5-6 (Well Known Group: NT AUTHORITY\SERVICE)
    Attributes - Mandatory Default Enabled 
 04 S-1-2-1 (Well Known Group: localhost\CONSOLE LOGON)
    Attributes - Mandatory Default Enabled 
 05 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
    Attributes - Mandatory Default Enabled 
 06 S-1-5-15 (Well Known Group: NT AUTHORITY\This Organization)
    Attributes - Mandatory Default Enabled 
 07 S-1-5-84-0-75023-0-0-0 (no name mapped)
    Attributes - Mandatory Default Enabled Owner LogonId 
 08 S-1-5-84-0-0-0-0-0 (Well Known Group: NT AUTHORITY\USER MODE DRIVERS)
    Attributes - Mandatory Default Enabled 
Primary Group: S-1-5-19 (Well Known Group: NT AUTHORITY\LOCAL SERVICE)

[---]
 この実行結果は、「WUDFHost.exe」プロセスが「サービスプロセス」であり、「System Mandatory Level」を示すSIDを持っていることを示しています。また、「システムプロセス」と「サービスプロセス」は、それぞれが所属するグループの数に大きな違いがあることも示しています。この「WUDFHost.exe」プロセスのSDは次のようになっています。
WUDFHost.exeプロセスのSD

1: kd> !sd 0xFFFFC001F13BAB10 1

[---]

->Sacl    : ->Ace[0]: ->Mask : 0x00000003
->Sacl    : ->Ace[0]: ->SID: S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
 この情報は、「システムプロセス」と「サービスプロセス」の区別がSDレベルではかなり難しいことを示しています。それでは今度は、セッション0以外のセッションに所属するユーザープロセスのトークンを見てみましょう。
[---]

SessionId->1	chrome.exe->0xFFFFE000238545C0
	MandatoryPolicy->3
	Token->0xFFFFC001F5EDA960
	SecurityDescriptor->0xFFFFC001F7033C40

SessionId->1	chrome.exe->0xFFFFE0001FDED840
	MandatoryPolicy->3
	Token->0xFFFFC001F8B3A550
	SecurityDescriptor->0xFFFFC00200851720

SessionId->1	chrome.exe->0xFFFFE000200CE200
	MandatoryPolicy->3
	Token->0xFFFFC001F8A69940
	SecurityDescriptor->0xFFFFC00200851720

SessionId->1	chrome.exe->0xFFFFE0002002D840
	MandatoryPolicy->3
	Token->0xFFFFC001F7C69060
	SecurityDescriptor->0xFFFFC00200851720
[---]
 赤色の2つの「chrome.exe」ユーザープロセスは、次のようなトークンを持っています。  
chrome.exe->0xFFFFE000238545C0のトークン

1: kd> !token -n 0xFFFFC001F5EDA960
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001f5eda960
TS Session ID: 0x1

[---]

 15 S-1-16-8192 (Label: Mandatory Label\Medium Mandatory Level)
    Attributes - GroupIntegrity GroupIntegrityEnabled 
 この「chrome.exe」プロセスは、「System」ではなく、それより一段低い「Medium」を示すSIDを持っています。もう一つの「chrome.exe」ユーザープロセスのトークンは次のようになっています。  
chrome.exe->0xFFFFE0001FDED840のトークン

1: kd> !token -n 0xFFFFC001F8B3A550
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001f8b3a550
TS Session ID: 0x1

[---]

 15 S-1-16-4096 (Label: Mandatory Label\Low Mandatory Level)
    Attributes - GroupIntegrity GroupIntegrityEnabled 
 この「chrome.exe」プロセスは、「Medium」よりさらに低い「Low」を示すSIDを持っています。同じ「chrome.exe」プロセスであっても、前者と比較しますと、レベルの一段低いSIDです。これは、親プロセスは自分よりレベルの高い実行権限を持つ子プロセスを作成できない、というセキュリティー原則が作用していることを証明しています。

 これまでの解析過程で登場した「 S-1-16-4096 (Label: Mandatory Label\Low Mandatory Level)」などのSIDは「Integrity Level」を決定する機能を持ち、次のように定義されています。
  1. 0x0000(0000) Untrusted level SECURITY_MANDATORY_UNTRUSTED_RID
  2. 0x1000(4096) Low integrity level SECURITY_MANDATORY_LOW_RID 子プロセスや新規作成オブジェクト
  3. 0x2000(8192) Medium integrity level SECURITY_MANDATORY_MEDIUM_RID 通常アプリケーション
  4. 0x3000(12288) High integrity level SECURITY_MANDATORY_HIGH_RID 特権ユーザー
  5. 0x4000(16384) System integrity level SECURITY_MANDATORY_SYSTEM_RID システム/サービスプロセス
 これらのSIDは、末尾(RID)の値が大きければ大きいほどより多くのアクセス権限と保護制限を持つことを示し、トークンとSDの両方に設定されます。

 これまでご紹介した実行結果には、「Mandatory Policy」という用語が登場していましたが、トークン側には次のような値が設定されます。
  1. 0x0: TOKEN_MANDATORY_POLICY_OFF
  2. 0x1: TOKEN_MANDATORY_POLICY_NO_WRITE_UP
  3. 0x2: TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN
  4. 0x3: TOKEN_MANDATORY_POLICY_VALID_MASK
 一方、SD側には、たとえば、「->Sacl : ->Ace[0]: ->Mask : 0x00000003」などと設定され、この「Mask」値は下位オブジェクトからの読み書きアクセスを制限することを示します。
  1. 0x1: SYSTEM_MANDATORY_LABEL_NO_WRITE_UP
  2. 0x2: SYSTEM_MANDATORY_LABEL_NO_READ_UP
  3. 0x4: SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP
 Windowsセキュリティーメカニズムの全体像を把握するのは簡単ではありません。新しいセキュリティー保護概念も追加・実装されています。本館は定期的に解析コードを開発し、返される実行結果をその都度吟味しているのが現実です。


ビジネスメニュー




 本「IT談話館」一般公開記事は、書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方々を想定しています。
Windowsメモリダンプ解析技術開発室 ビジネスメニュー

Copyright©豊田孝 2004- 2020
本日は2020-09-28です。