The Power in Power Users

5月にTechNetで最初に公開されました01, 2006

WindowsユーザーアカウントをPower Usersセキュリティグループに配置することは、限られたユーザーとして真に実行する多くの苦痛を回避しながら、ユーザーを最小限の特権 Power Usersグループは、ソフトウェアのインストール、電源とタイムゾーンの設定の管理、ActiveXコントロールのインストール、制限されたユーザーが拒否されるアクショ
しかし、多くの管理者が認識していないのは、この力は真の限られたユーザーセキュリティの代償であるということです。 このマイクロソフトサポート技術情報の記事やMicrosoftセキュリティスペシャリストのJesper Johansenによるこのブログ記事を含む多くの記事では、Power Usersグループに属し したがって、私は調査することにしました。
調査を始める前に、私は問題を定義しなければならなかった。 バッファオーバーフローなどのセキュリティ上の欠陥がない場合、特権の昇格は、より特権の高いアカウントのコンテキストで実行するように任意のコードを構成できる場合にのみ可能です。 パワーユーザーよりも多くの特権を持つ既定のアカウントには、管理者と、いくつかのWindowsサービスプロセスが実行されるローカルシステムアカウントが含ま したがって、Power Usersメンバーがこれらのアカウントのいずれかで実行されるファイルを変更したり、任意のDLLをロードするように実行可能ファイルのいず
私の最初のステップは、Power Usersグループが書き込みアクセス権を持っているが、制限されたユーザーが持っていないファイルとディレクトリを確認するこ 私が検討したシステムは、標準のWindows2000Professional SP4、Windows XP SP2、およびWindows Vistaでした。 最も一般的なパワーユーザーのシナリオはワークステーション上にあるので、私はサーバーシステムを見て気にするつもりはありません。
パワーユーザーが変更できるファイルシステムオブジェクトを見るブルートフォース法では、各ファイルとディレクトリを訪問し、その権限を調べる必要がありますが、明らかに実用的ではありません。 Windowsに含まれるコマンドラインCaclsユーティリティは、セキュリティ記述子をダンプしますが、セキュリティ記述子記述言語（SDDL）を学習し、出力を解析するにはス Bryceが書いたAccessEnumユーティリティは有望に見え、レジストリのセキュリティも見ることができますが、特定のアカウントに利用可能なアクセスではなく、潜在的なパーミッションの弱点を示すことを目的としています。 さらに、Windowsサービスに適用されるセキュリティも検討する必要があることを知っていました。
私は仕事のために新しいユーティリティを書かなければならないと結論づけたので、AccessChkを作成しました。 AccessChkにアカウント名またはグループ名、ファイルシステムパス、レジストリキー、またはWindowsサービス名を渡すと、アカウントのグループメンバーシップを考慮して、 たとえば、Markアカウントがファイルへのアクセス権を持っていたが、Markが明示的にアクセスを拒否されたDevelopersグループに属している場合、AccessChkはMarkにアクセス権
出力を読みやすくするために、AccessChkは、アカウントがオブジェクトを変更できる権限を持っている場合はオブジェクト名の横に’W’を出力し、アカウントがオ さまざまなスイッチにより、AccessChkはサブディレクトリまたはレジストリサブキーに再帰し、–vスイッチはアカウントに利用可能な特定のアクセスを報告 アカウントが書き込みアクセス権を持つオブジェクトを探すために特別に追加したスイッチは–wです。
この新しいツールで武装して、私は調査を開始す 私の最初のターゲットは、VMWare Tools以外のアプリケーションがインストールされていないWindows XP SP2VMWareインストールでした。 最初に実行したコマンドは次のとおりです。
accesschk-ws”power users”c:\windows
Power Usersグループが変更できる\Windowsディレクトリの下にあるすべてのファイルとディレクトリが表示されます。 もちろん、\Windowsの下のファイルの多くはオペレーティングシステムまたはWindowsサービスの一部であるため、ローカルシステムアカウントで実行されます。 AccessChkは、パワーユーザーが\Windowsの下のディレクトリのほとんどを変更できることを報告しました。 したがって、Power Usersグループのメンバーは、\Windowsおよび\Windows\System32ディレクトリにファイルを作成できます。 さらに、パワーユーザーは、ActiveXコントロールをインストールできるように、\Windows\Downloaded Program Filesディレクトリにファイルを作成できる必要があります。 ただし、これらのディレクトリにファイルを作成するだけでは、特権の昇格へのパスではありません。
パワーユーザーは\Windowsとそのサブディレクトリのほとんどの下にファイルを作成できますが、Windowsはこれらのディレクトリに含まれるほとんどのファイ 例外には、フォントファイル(.fon）、多くのシステムログファイル（。ログ）、いくつかのヘルプファイル（。chm）、写真やオーディオクリップ（。jpg,.gif、および。wmv）とインストールファイル（.ただし、これらのファイルのいずれも、管理者特権を得るために変更または置換することはできません。 \Windows\System32\Driversのデバイスドライバは簡単にエスカレーションできますが、パワーユーザーはそれらのいずれにも書き込みアクセス権を持っていません。

私はいくつかを見ました。exeのと。しかし、dllはリストにあるので、私は可能な悪用のためにそれらを調べました。 パワーユーザーが書き込みアクセス権を持っている実行可能ファイルのほとんどは、対話型ユーティリティであるか、特権を削減して実行されます。 システムに対話的にログインするように管理者を騙すことができない限り、これらを使用して昇格することはできません。 しかし、1つの明白な例外があります：ntoskrnl。exe:

そうです、パワーユーザーは、Windowsのコアオペレーティングシステムファイルを交換または変更することができます。 ただし、ファイルが変更されてから5秒後に、Windows File Protection（WFP）は、ほとんどの場合、\Windows\System32\Dllcacheから取得したバックアップコピーに置き換えられます。 パワーユーザーはDllcache内のファイルへの書き込みアクセス権を持っていないので、バックアップコピーを破壊することはできません。 しかし、Power Usersグループのメンバーは、ファイルを置き換え、変更されたデータをディスクにフラッシュし、WFPがアクションを実行する前にシステムを再起動す
私はこのアプローチが機能することを確認しましたが、この脆弱性をどのように使用して特権を昇格できるかという疑問が残っていました。 その答えは、逆アセンブラーを使用して、Windowsが特権チェック、SeSinglePrivilegeCheckに使用する関数を見つけ、ディスク上のイメージ内のエントリポイントにパッチを適用して、常にTRUEを返すようにするのと同じくらい簡単です。 このように変更されたカーネルでユーザーが実行されると、Load Driver、Take Ownership、Create Tokenなどのすべての権限を持っているように見えます。 64ビットWindows XPはpatchguardによるカーネルの改ざんを防止しますが、64ビットWindowsで実行されている企業はほとんどありません。
exeは、しかし、\Windowsディレクトリを介して管理者権限にパンチスルーする唯一の方法ではありません。 デフォルトの権限がパワーユーザー Schedsvcによる変更を許可するDllの少なくとも一つ。dllは、ローカルシステムアカウントでWindowsサービスとして実行されます。 ———–dllは、Windowsタスクスケジューラサービスを実装するDLLです。 Windowsはサービスなしで正常に動作するため、パワーユーザーは、自分のアカウントをローカルのAdministratorsグループに追加するだけのDLLなど、任意のDLLをDLLに置き換えるこ もちろん、WFPもこのファイルを保護するため、置き換えには私が説明したWFPバイパス技術を使用する必要があります。
私はすでにいくつかの標高ベクトルを特定していましたが、\Windowsディレクトリにあるものと同様のデフォルトのアクセス許可を見つけた\Program Filesディレ パワーユーザーは\Program Filesの下にサブディレクトリを作成できますが、プリインストールされているWindowsコンポーネントのほとんどを変更することはできません。 繰り返しますが、Windows Messenger（\Program Files\Messenger\Msmgs。exe）およびWindows Media Player（\Program Files\Windows Media Player\Wmplayer。exe）を対話的に実行します。
それは\Program Filesが潜在的な穴を持っていないことを意味するものではありません。 私が最新の出力を調べたとき、私はパワーユーザーがベースのWindowsインストール中に作成されたものに続いて\Program Filesで作成されたファイルやディレクトリを変 私のテストシステム\Program Files\Vmware\Vmware Tools\Vmwareserviceにあります。ローカルシステムアカウントで実行されるVmware Windowsサービスのイメージファイルであるexeは、そのようなファイルでした。 別のやや皮肉な例は、デフォルトのセキュリティ設定で\Program Files\Windows Defenderにそのサービスの実行可能ファイルをインストールするMicrosoft Windows Defenderのベータ2です。 これらのサービスイメージファイルを置き換えることは、管理者特権への簡単なパスであり、WFPは置換に干渉しないため、\Windowsディレクトリ内のファイルを置
次に、次のコマンドを実行してレジストリに注意を向けました。
accesschk–swk”power users”hklm
パワーユーザーはHKLM\Softwareキーの大部分への書き込みアクセス権を持っているため、出力リ HKLM\System\CurrentControlSet\ServicesのWindowsサービスキーやドライバー構成キーなど、その下にある多くの設定への書き込みアクセスは、ローカルシステムアカウントの些細なサブバージョンを許 分析は、パワーユーザーがそのキーの下で重要なものへの書き込みアクセス権を持っていないことを明らかにしました。
ほとんどのパワーユーザー-HKLMの他の主要なブランチの下で書き込み可能な領域、ソフトウェア、Internet Explorer、Explorerとそのファイルの関連付け、および電源管理構成に関 パワーユーザーは、HKLM\Software\Microsoft\Windows\CurrentVersion\Runへの書き込みアクセス権も持っており、誰かが対話的にログオンするたびに実行するように任意の実行可能ファイルを設定できますが、これを悪用するには、管理者特権を持つユーザーがシステムに対話的にログオンする必要があります(システムによっては、発生したり、まれに発生したりすることはありません)。 また、\Program Filesディレクトリと同様に、パワーユーザーはHKLM\SoftwareのWindows以外のサブキーへのデフォルトの書き込みアクセス権を持っています。 システムにインストールされている唯一のアプリケーションであるVMWareは、そうではありませんでした。
探索の残りの領域はWindowsサービスでした。 AccessChkが書き込みアクセスとみなすサービス権限は、SERVICE_CHANGE_CONFIGとWRITE_DACだけです。 SERVICE_CHANGE_CONFIGを持つユーザーは、サービスの起動時に起動するように任意の実行可能ファイルを構成でき、WRITE_DACを指定すると、サービスのアクセス許可を変更してSERVICE_CHANGE_CONFIG AccessChkは私の株式のWindows XP SP2システム上で次のことを明らかにしました:

次にPsServiceを実行して、DcomLaunchサービスが実行されるアカウントを確認しました:

したがって、Power Usersグループのメンバーは、DComLauncherのイメージパスを自分のイメージを指すように変更し、システムを再起動し、管理者特権を享受することができます。
セキュリティに悪用を導入する他のサービスが潜在的に存在する可能性があります。 サードパーティアプリケーションによって作成されたサービスにWindowsが設定する既定のアクセス許可では、パワーユーザーの書き込みアクセスは許可されませんが、サードパーティアプリケーションによっては、カスタムアクセス許可を構成してユーザーに許可する場合があります。 実際、私の本番環境の64ビットWindows XPインストールAccessChkでは、パワーユーザーが自分自身を昇格させるために使用できるだけでなく、限られたユーザーもできる穴が明ら:

私は今、私の調査の主要な段階を終え、ちょうど誰もが言っていることを確認しました：パワーユーザーグループの決定されたメンバーは、オペレーティングシステム
私の最後のステップは、パワーユーザーアカウントへのMicrosoftのアプローチが時間の経過とともにどのように進化してきたかを確認することでした。 この1999年のマイクロソフトサポート技術情報の資料では、Windows NT4に存在していた有名なスクリーンセーバーの昇格の脆弱性について説明していますが、MicrosoftはWindows2000のリリース前にその穴を閉じました。 KBの記事では、Microsoftが存在する可能性のある他の脆弱性を明らかに認識していないことも示されています。 Windows2000SP4には穴も含まれていますが、実際にはデフォルトのWindows XP SP2構成よりもわずかに安全です。exeまたはタスクスケジューライメージファイルですが、DComLauncherサービスへの書き込みアクセスの代わりに、ローカルシステムアカウントでも実行されるWMIサービスを
Windows XP SP1は、Svchostのような重要なシステムファイルへの書き込みアクセスを含む、より多くのパワーユーザーの弱点を追加しました。exe、Windowsサービスホスティングプロセス、および悪用可能なアクセス許可を持つ追加のサービス、WMIおよびSSDPSRV。 いくつかのサービスでは、今年の3月からこのMicrosoft KBの記事で説明されているように、限られたユーザーが昇格することさえできました。
マイクロソフトの最新のオペレーティングシステムであるWindows Vistaは、限られたユーザーと同じように動作するように、パワーユーザーを中和することによって説明したすべての脆弱性を閉じます。 マイクロソフトは、このように、限られたユーザーアカウントまたは彼らは彼らのシステム上のエンドユーザーの制御を認識する必要があります管理アカウ
要するに、マイクロソフトは私の調査で見つけた脆弱性を修正することができますが、サードパーティのアプリケーションが新しいものを導入するのを防 教訓は、IT管理者として、Power Usersグループが限られたユーザーとして実行する途中で安全な妥協であると考えるように自分自身を欺くべきではないというこ

もともとMark Russinovichによって5/1/2006 11:01:00AM
オリジナルから移行Sysinternals.com/Blog