デバッグプログラムポリシー有効時にSeDebugPrivilegeを取得する方法

前回の記事では、mimikatzのようなツールへの対策の一つとして、「プログラムのデバッグ(Debug programs)」ポリシーを使ってシステム管理者のデバッグ権限を無効化する方法を紹介しました。しかし最近、デバッグ権限(WindowsではSeDebugPrivilege)がないと、ローカルのサーバー管理者がMicrosoft SQL Serverをインストールしたり更新したりできないことが判明しました。というのも、SQL Serverのインストーラーは起動時に、SeSecurity、SeBackup、SeDebugの各権限が存在するかどうかをチェックするからです。これは、SQL Serverプロセスを実行し、その正常な起動に関する情報を取得するために必要なものです。以下にその様子を示します。

SQL Serverインストール時の権限チェックエラー

SQL Serverのインストール中、インストーラーは事前チェックを実行し、「セットアップアカウントの権限(Setup account privileges)」に問題があることを検出します。

「失敗(Failed)」リンクをクリックすると、次のメッセージが表示されます。

ルール「Setup account privileges」が失敗しました。
SQL Serverセットアップを実行しているアカウントには、次の権限のうち1つまたはすべてがありません。ファイルとディレクトリのバックアップ権限、監査とセキュリティログの管理権限、そしてプログラムのデバッグ権限です。続行するには、これらの権限をすべて持つアカウントを使用してください。

次に、SystemConfigurationCheck_Report.htmレポートを開いてみましょう。

ご覧のとおり、「HasSecurityBackupAndDebugPrivilegesCheck」ルールのチェックにおいて、インストーラーは現在のプロセスに以下のいずれかの権限がないことを検出しています。

• SeSecurity – 監査ログとセキュリティログの管理権限
• SeBackup – ファイルとフォルダーのバックアップ権限
• SeDebug – プログラムのデバッグ権限

ログには、インストールプロセスにSeDebugフラグがないことを示す詳細情報が記録されています。

(09) 2017-12-12 11:15:13 Slp: Initializing rule      : Setup account privileges
(09) 2017-12-12 11:15:13 Slp: Rule is will be executed  : True
(09) 2017-12-12 11:15:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck
(09) 2017-12-12 11:15:13 Slp: Rule 'HasSecurityBackupAndDebugPrivilegesCheck' Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege.
(09) 2017-12-12 11:15:13 Slp: Evaluating rule        : HasSecurityBackupAndDebugPrivilegesCheck
(09) 2017-12-12 11:15:13 Slp: Rule running on machine: rom-sql10
(09) 2017-12-12 11:15:13 Slp: Rule evaluation done   : Failed

seceditを使ったSeDebugPrivilegeの取得方法

そこで筆者は、「プログラムのデバッグ」ポリシーを変更または無効化することなくSeDebugPrivilegeを取得する回避策を探してみました。その結果、サーバーのローカル管理者権限を持っていれば、このポリシーを比較的簡単にバイパスできる方法があることがわかりました。鍵となるのは、サーバーのローカルセキュリティポリシーを管理できるseceditツールです。

まず、現在の権限を確認します。

whoami /priv

ご覧のとおり、ユーザーの現在のトークンにはSeDebugPrivilegeが含まれていません。

次に、グループポリシーによって設定された現在のユーザー権限をテキストファイルにエクスポートします。

secedit /export /cfg secpolicy.inf /areas USER_RIGHTS

任意のテキストエディターでsecpolicy.infを開き、「[Privilege Rights]」セクションに、ローカル管理者グループへプログラムのデバッグ権限を付与する文字列を追加します。

SeDebugPrivilege = *S-1-5-32-544

注: S-1-5-32-544はローカル管理者グループのSIDですが、他の任意のSIDに置き換えることも可能です。グループ名やユーザー名をSIDに変換する方法については、「SIDからユーザー名への変換(およびその逆)」の記事を参照してください。

ファイルを保存したら、新しいユーザー権限を適用します。

secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS

注: 現在の設定を上書きするかどうかの確認を求められるので、承認してください。

一度ログオフして再度ログオンし、secpol.mscを使って「プログラムのデバッグ」権限がローカル管理者グループに割り当てられていることを確認しましょう。whoami /privコマンドの結果にも同じ内容が表示されます。

SeDebugPrivilege Debug programs Enabled

これで、SQL Serverのインストールや更新を実行できるようになります。ただし、SeDebugPrivilegeは一時的に割り当てられるものであり、次回のGPO更新サイクル(ユーザーがログオフした後)でリセットされる点に注意してください。

セキュリティ上の注意点

最後に理解しておくべき重要な点として、「プログラムのデバッグ」ポリシーを有効にしても、ローカル管理者権限を持ってすでにサーバーに侵入しているマルウェアがSeDebugPrivilegeを取得することを完全に防ぐことはできません。その場合、サーバー上で動作しているすべてのユーザー/管理者アカウントが危険にさらされる可能性があります。あくまで多層防御の一環として、他のセキュリティ対策と組み合わせて運用することが推奨されます。