DCOMはやっぱり危険，IE/Officeを遠隔から操作できる（下）

日経バイト

2003.07.24

DCOMセキュリティ

　以上で紹介したコードは，リモートPCに現在ログオンしているユーザーと同じアカウント情報で，ローカルPCにログオンしてコードを実行した場合にしか正常に動作しない。その理由とコードを正常に動作させる方法を理解するには，DCOMのセキュリティについて理解しなければならない。

図4　認証の二つのステップ

　DCOMを利用してネットワーク経由でCOMコンポーネントを呼び出すには，二つの認証機構をパスする必要がある（図4[拡大表示]）。一つはログオン監査，もう一つはDCOM認証である。

　DCOMでは，COMコンポーネントを呼び出す側のローカルPCから，呼び出される側のリモートPCに対して，アカウント情報が送信される。通常，このアカウント情報はCOMコンポーネントを呼び出すアプリケーションを実行したユーザーのアカウント情報となる。このアカウント情報はまずログオン監査によりチェックされ，呼び出される側のPCに同じアカウント情報が存在しない場合，COMコンポーネントの呼び出しは失敗する。

　ログオン監査をパスしたCOMコンポーネント呼び出し要求は，DCOM認証機構により再びチェックされる。各COMコンポーネントは起動・アクセス権限を制御するためのアクセス・コントロール・リスト（ACL）と，COMコンポーネントの呼び出しにどのユーザーを使用するかを示す識別プロパティを持つ。

写真4　規定の起動アクセス許可

写真5　IEの識別プロパティ

図5　リモートPCからローカルPCへの認証要求

リスト11　リモートPCのログオン・アカウントと同じアカウントをローカルPC上に作成するコード

リスト12　新しく作成したユーザーのコンテキストでIEを呼び出すコード

図6　Windows XPの新しいセキュリティ・モデル

写真6　ローカルセキュリティポリシーの変更

写真7　簡易ファイルの共有「簡易ファイルの共有を使用する（推奨）」のチェックを外す。

写真8　Officeをリモートから呼び出しているところ

　COMコンポーネントに設定されたACLと識別パラメータの値は，分散COM構成ユーティリティから見ることができる。IEをはじめとするほとんどのCOMコンポーネントは，規定の起動アクセス許可を使用するように設定されている。規定の起動アクセス許可には，SYSTEM, Administrators, INTERACTIVEの三つのエントリが存在する（写真4[拡大表示]）。INTERACTIVEとは，Microsoftの技術情報によれば，PCにローカルにログオンしているユーザーを示す。またIEの識別プロパティのデフォルト設定は，「起動したユーザー」となっている（写真5[拡大表示]）。これはログオン監査をパスしたユーザーが，そのままCOMコンポーネントの呼び出しに使われることを示している。

　ローカルPC上のアプリケーションが，リモートPC上のCOMコンポーネントからイベントを受信するためには，リモートPCに対してイベント受信用のCOMインタフェースへの参照をローカルPCが提供する必要がある（これは前述した）。この際，リモートPCからローカルPCへのCOMコンポーネント呼び出しが生じ，リモートPCからローカルPCへの認証要求が発生する（図5[拡大表示]）。ローカルPCはリモートPCから送信されたアカウント情報を，ローカルPC上のログオン監査によりチェックする。リモートPCが使うアカウント情報は，リモートPCにローカルにログオンしているユーザーのもので，ローカルPC上に，リモートPCにローカル・ログオンしているユーザーと同じアカウントが存在している必要がある。

　ここで，IE'enで使用しているコードを紹介する。最初に，NetUserAdd APIを使用して，リモートPCに現在ローカルにログオンしているアカウントと同じアカウントを，ローカルPC上に作成する（リスト11[拡大表示]）。

　次に，新しく作成したユーザーのコンテキストで，IEを呼び出すためのコードを実行する。このとき，CreateProcessWithLogonW APIを使用する（リスト12[拡大表示]）。

Windows XPの新しいセキュリティ・モデル

　前述したコードは，操作対象のIEがWindows 2000上ならば，正常に動作する。しかし，デフォルト設定のWindows XP上のIEを操作しようとするとうまくいかない。なぜなら，Windows XPにはWindows 2000とは違う新しいセキュリティ・モデルが採用されているからだ。

　ローカルPCからリモートPCに対して送信されたアカウント情報は,まずログオン監査によりチェックされる。ここまではWindows 2000の場合と同じだ。このアカウントがリモートPC上に存在すれば，ログオン監査は成功する。Windows2000の場合，このあと同じアカウント情報を使用してDCOM認証が行われるが，Windows XPの新しいセキュリティ・モデルでは，GuestユーザーをDCOM認証に使用する（図6[拡大表示]）。

　先に解説した通り，IEの起動アクセス許可には，SYSTEM, Administrators, INTERACTIVEの三つのエントリがあるだけで，Guestユーザーによる起動アクセスは禁止されている。このため，IEへの起動アクセスは失敗する。

　WindowsXP Professionalには，Windows2000と同じ古いセキュリティ・モデルを使用するように設定する方法が二つある。

　一つは，ローカルセキュリティポリシーを変更する方法だ。コントロールパネルの管理ツールにあるローカルセキュリティポリシーをダブルクリックすると，ローカルセキュリティ設定ツールが起動する。ここで，「ローカルポリシー」の「セキュリティオプション」をクリックし，右ペインに表示されたポリシーのリストから「ローカルアカウントの共有とセキュリティ・モデル」を「クラシック-ローカルユーザーがローカルユーザーとして認証する」に変更する（写真6[拡大表示]）。

　もう一つは，エクスプローラの「ツール」メニューで「簡易ファイルの共有」を無効にする方法だ（写真7[拡大表示]）。「ツール」メニューの「フォルダオプション」項目を選択し，「詳細設定」タブから「簡易ファイルの共有を使用する（推奨）」を選択してチェックを外す。

　この二つは連動しており，どちらか一方を変更すればよい。

　リモートPCのWindows XPに上記の設定を施すと，IEを操作することが可能になる。ローカルPCがWindows XPの場合も，デフォルト設定ではリモートPC上のIEからのイベントを受け取ることができない。同様の設定を行う必要がある。

Officeをリモートから呼び出す

　DCOMを使って，リモートPC上のIEを操作することが簡単だと分かったと思う。DCOMを使って遠隔操作を行うことができるのは，IEだけではない。最後に，同様の手法でMicrosoft Officeの遠隔操作も可能になることについて述べておく。

　写真8[拡大表示]はリモートPC上にあるWordファイルを，DCOMを使って開いたところだ。このサンプル・プログラムは，リモートPC上のWordを起動して最近Wordを使って編集されたファイルの一覧を表示することができる。Wordファイルの存在場所を知らなくてもよいのだ。一覧からファイルを選択すると，このファイルの内容を取得できる。さらに，このファイルをこのプログラムから書き換えてしまうことも可能である。

　ただし，WordなどのOfficeアプリケーションは，IEの場合とは違い，リモートPC上でAdministrator権限を持つユーザーがローカル・ログオンしている必要がある。IEもOfficeもデフォルトでは，同じDCOMセキュリティ・プロパティを持っている。この必要権限の違いが，DCOMの仕様によるものか，Officeの実装によるものかは，残念ながら今のところよく分かっていない。

DCOMを悪用されないために

　DCOMを使ってWordやExcelをネットワーク経由で操作するプログラムは，業務システムを開発するエンジニアにとって有用かもしれない。Windowsには，Windows Management Instrumentation（WMI）というコンピュータの遠隔管理を行うためのCOMコンポーネントが登録されている。これも複数のコンピュータを管理する管理者にとっては有用だろう。

　とはいえ，これらのリモート呼び出し機能は，悪用されると大変危険である。便利さと危険を兼ね備えた両刃の剣となり得る機能である。

　DCOMが悪用される危険性から身を守るためには，DCOM（DCE-RPC）が使うポート135をフィルタリングする，またはDCOMを無効にするなどの方法がある。ただ，これらの方法を採ると，DCE-RPCやDCOMを必要とするすべてのアプリケーションが動作しなくなる。各COMコンポーネントに起動・アクセス権限を厳しくする方法もあるが，すべてのCOMコンポーネントに起動・アクセス権限を設定し直すのは容易ではない。