ユーザーアカウント制御(UAC)の奇妙な体験――デスクトップは暗転しない?:その知識、ホントに正しい? Windowsにまつわる都市伝説(101)(2/2 ページ)
Windows Vistaで導入された「ユーザーアカウント制御(UAC)」。Windows Vistaではオン/オフしかできませんでしたが、Windows 7以降は4つのレベルで挙動を調整できるようになりました。その1つに「デスクトップを暗転しない」がありますが、これが推奨されない理由、ご存じですか?
暗転した(ように見える)デスクトップの正体は、ロック画面と同じデスクトップ
Windows VistaおよびWindows 7までの「ユーザーアカウント制御」ダイアログボックスは、UACの昇格を要求するプログラムを実行しているのと同じデスクトップ上に表示されていました。そして、既定ではデスクトップが暗転し、「ユーザーアカウント制御」ダイアログボックス以外の場所を操作できないようになります(Windows Vistaはこの動作のみ)。
一方、Windows 8以降の「ユーザーアカウント制御」ダイアログボックスは、UACの昇格を要求する通常のデスクトップではなく、「セキュリティで保護されたデスクトップ(Secure Desktop)」と呼ばれる特別なデスクトップに表示されています。「セキュリティで保護されたデスクトップ」は、[Ctrl]+[Alt]+[Del]キーを押したときに表示されるセキュリティオプションの表示画面や、ワークステーションのロック画面と同じです。
以下の図1は、Windows Vista以降の「セッション(Session)」と「ウィンドウステーション(WindowStation)」オブジェクト、「デスクトップ(Desktop)」オブジェクトの関係を示したものです。
図1 Windows Vista以降の「セッション(Session)」と「ウィンドウステーション(WindowStation)」オブジェクト、「デスクトップ(Desktop)」オブジェクトの関係(UACプロンプトの場所はWindows 8以降の場合を示しています)
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デスクトップの背景として表示しているだけに過ぎません。
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ではうまくいきません。
- トラブルシューター泣かせのWindowsの仕様変更──忘れられた互換性機能?(連載:山市良のうぃんどうず日記 第89回)
筆者紹介
山市 良(やまいち りょう)
岩手県花巻市在住。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.
関連記事
- 「Windows Server version 1709」のダウンロード配布が開始――Microsoft
Microsoftは、Windows Serverの「半期チャネル」による初のリリースとなる「Windows Server version 1709」のダウンロード配布を開始した。コンテナやマイクロサービス関連など、多くの新機能を提供する。 - 「Windows Server version 1709」では、Nano Serverコンテナイメージサイズが80%縮小
Microsoftの公式ブログで、2017年秋に投入予定の「Windows Server version 1709」で注目されるNano ServerおよびLinuxコンテナ機能が紹介された。 - 先行き不安なWindows Update――ボクが2017年10月の更新をスキップした(できた)理由
毎月第二火曜日の翌日(日本時間)は、恒例のWindows Updateの日です。最近は何か問題が起きるのではないか、更新に何時間もかかったり、その上失敗したりするのではないかと、恐怖さえ感じます。さて、2017年10月のWindows Updateは無事に済んだのでしょうか。 - Windows Server 2016の今後の“更新”が怖い
テスト環境として構築したWindows Server 2016の物理サーバと仮想マシン。その一部でWindows Updateやシャットダウンに異様に時間がかかるといった現象に遭遇しました。そんな中、Windows Serverの次期バージョンに関する新方針の発表もあって、いろいろな面で“更新”に対する不安が高まっています(筆者の個人的な感想)。