Windows VistaおよびWindows 7までの「ユーザーアカウント制御」ダイアログボックスは、UACの昇格を要求するプログラムを実行しているのと同じデスクトップ上に表示されていました。そして、既定ではデスクトップが暗転し、「ユーザーアカウント制御」ダイアログボックス以外の場所を操作できないようになります(Windows Vistaはこの動作のみ)。
一方、Windows 8以降の「ユーザーアカウント制御」ダイアログボックスは、UACの昇格を要求する通常のデスクトップではなく、「セキュリティで保護されたデスクトップ(Secure Desktop)」と呼ばれる特別なデスクトップに表示されています。「セキュリティで保護されたデスクトップ」は、[Ctrl]+[Alt]+[Del]キーを押したときに表示されるセキュリティオプションの表示画面や、ワークステーションのロック画面と同じです。
以下の図1は、Windows Vista以降の「セッション(Session)」と「ウィンドウステーション(WindowStation)」オブジェクト、「デスクトップ(Desktop)」オブジェクトの関係を示したものです。
UACと同じくらいに重要なセキュリティ上の変更点として、Windows Vistaからは「セッション0の分離」が行われました。これは、システムやサービスをユーザーセッションとは別のセッション番号「0」のセッションで実行するように変更したことです。
Windows XPまで、システムとサービスは、コンソールに対話的にログオンしたユーザーと同じセッション0で実行されていました。システム(カーネルモードドライバを含む)やサービスはより高い権限で実行されるため、ユーザーセッション内に入り込んだ悪意のあるコードの格好の標的になってしまいます。
Windows Vistaからは、システムとサービスを常にセッション0で実行し、ローカルに対話型ログオンする、あるいはリモートデスクトップ接続のネットワーク経由で対話型ログオンするユーザーのセッションには、セッション1以降が使用され、セッション0と分離されます。
図1に示したように、セッションごとに「WinSta0」という名前のウィンドウステーションオブジェクトが作成され、その中に「Default」や「Winlogon」などの複数のデスクトップオブジェクトが作成されます。そして、Defaultデスクトップは対話型ユーザーの通常のデスクトップであり、Winlogonデスクトップはセキュリティで保護されたデスクトップになります。
Windows VistaおよびWindows 7では、UACの昇格を要求したプログラム(例えば、Regedit.exe)と「ユーザーアカウント制御」ダイアログボックス(%Windir%\System32\Consent.exe)の両方が、Defaultデスクトップで動作します。
一方、Windows 8以降の「ユーザーアカウント制御」ダイアログボックスは、Winlogonデスクトップで動作します。デスクトップが暗転しているように見えるのは、Defaultデスクトップの壁紙にシェード効果を加えて、Winlogonデスクトップの背景として表示しているだけに過ぎません。
Windows 8以降の「ユーザーアカウント制御」ダイアログボックスが、Defaultデスクトップを暗転したものではなく、Winlogonデスクトップであるということを実証してみましょう。Windows Sysinternalsの「PsExec」ユーティリティーを使用すると、それが可能です。
PsExecユーティリティーを使用すると、Winlogonデスクトップやセッション0のデスクトップで任意のプログラムを実行することができます。Windowsは異なるデスクトップ間でのメッセージングを許可しないと説明しましたが、PsExecユーティリティーはデスクトップ間のメッセージングではなく、対象のデスクトップで動作するサービス(PSEXECSVC)をインストールして、そのサービスからプログラムを実行するという仕組みを利用しています。
例えば、Windows 10のローカルコンソールから対話型でログオンし、管理者として開いたコマンドプロンプトで次のコマンドラインを実行すると、Winlogonデスクトップ(-xオプション)でコマンドプロンプト(cmd.exe)をシステムアカウントの権限で実行(-sオプション)することができます(画面3)。
psexec -x -s cmd.exe
上記のコマンドラインを実行後、[Ctrl]+[Alt]+[Del]キーを押して、セキュリティオプション画面、つまりWinlogonデスクトップに切り替えます。いつものセキュリティオプションの画面(%Windir%\System32\LogonUI.exe)に切り替わりますが、その状態で[Alt]+[Tab]キーでウィンドウを切り替えると、コマンドプロンプトの存在に気が付くはずです(画面4)。
「whoami」コマンドや「query session」コマンドを実行すると、システムアカウント(NT AUTHORITY\SYSTEM)であることや、同じセッション(この例の場合はセッション番号1のconsole)であることを確認できるでしょう。セキュリティオプションの「ロック」をクリックして、ロック画面に切り替えても、コマンドプロンプトは消えません。「タスクマネージャー(Taskmgr.exe)」やWindows Sysinternalsの「Process Explorer(Procexp.exe)」を実行すれば、セキュリティオプション画面やロック画面が「%Windir%\Systemroot\LogonUI.exe」であることが分かります。
通常のデスクトップに戻り、今度は「レジストリエディター(Regedit.exe)」を実行してみましょう。UACの「ユーザーアカウント制御」ダイアログボックスが表示されたら、[Alt]+[Tab]キーでウィンドウを切り替えます。すると、先ほどと全く同じコマンドプロンプトを確認できるはずです。タスクマネージャーやProcess Explorerを実行すれば、「ユーザーアカウント制御」ダイアログボックスが「%Windir%\System32\Concent.exe(管理アプリケーションの承認UI)」であることを確認できるはずです(画面5)。
なお、リモートデスクトップ接続のセッションから同じことを行うと、ローカルコンソールのロック画面にコマンドプロンプトが出現するため、少々混乱するかもしれません。
Process Explorerを使えば、Winlogonデスクトップにも攻撃できるのでは? と早合点しないようにしてください。Winlogonデスクトップでプログラムを動かすこの方法は、“既に管理者権限に昇格した状態”からでなければ実行できません。攻撃者が何らかの方法で既に管理者権限を持っているなら、そんな面倒なことをしなくても、もっと悪いことを簡単に、しかもこっそりと実行できるでしょう。
さて、Windows 8以降においても「アプリがコンピュータに変更を加えようとする場合のみ通知する(デスクトップを暗転しない)」レベルへの緩和は、セキュリティの観点からは決して推奨されないことが何となく理解していただけたのではないでしょうか。
このレベルに緩和すると、デスクトップが暗転しない、つまりセキュリティで保護されたデスクトップに切り替わらないことになります(画面6)。
攻撃者は「ユーザーアカウント制御」ダイアログボックスを模した画面をユーザーに提示して、正規のプログラムであるかのように装い、「はい」ボタンをクリックさせることができるでしょう。「はい」ボタンをクリックした後に、本物の「ユーザーアカウント制御」ダイアログボックスが表示されたとしても、よく確認せずにもう一度「はい」ボタンをクリックしてしまうかもしれません。別のセキュリティで保護されたデスクトップに切り替わるのであれば、そのようなことを行うのは困難です。
UACの設定場所には「推奨されません。コンピュータのデスクトップが暗転する際に時間がかかる場合にのみ選択してください」と注意書きがありますが、単にグラフィックス性能の問題を回避するだけでなく、セキュリティが低下するため推奨されないのです。
最後に、PsExecユーティリティーを使用して、セッション0でプログラムを実行する方法については、以下の記事をご覧ください。Windows 8.1までは可能ですが、Windows 10ではうまくいきません。
岩手県花巻市在住。Microsoft MVP:Cloud and Datacenter Management(Oct 2008 - Sep 2016)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows Server 2016テクノロジ入門−完全版』(日経BP社)。
Copyright © ITmedia, Inc. All Rights Reserved.