← すべての記事 リファレンス

AWS 権限昇格マップ

Pathbreak チーム · · 7 分で読めます

要点

  • 攻撃者が管理者権限、データ、永続化へと連鎖させ得る AWS 権限のリファレンスを作成し、それぞれに 1 ページを設けました。
  • すべての項目は同じ 4 つの情報を備えています。その権限がどう使われるか、それを捕捉する CloudTrail イベント、MITRE ATT&CK のテクニック、そしてその経路を取り除く制御です。
  • 権限昇格の項目の半数以上は iam:PassRole を経由します。最も多くのサービスに関わる唯一の権限です。
  • 単独で昇格する権限もあります。多くは他の権限と組み合わさって初めて昇格し、ほかの権限と併せ持たれます。こうしたトキシックな組み合わせこそ、ポリシーを 1 つずつ見るレビューが見逃すものです。
  • ある権限が危険だと知ることと、それがあなたのアカウントで危険だと知ることは別です。それには実際の認可に照らした検証と、その権限が不可欠かどうかというビジネス文脈の判断が必要です。

10 人の AWS エンジニアに、どの権限が危険かと尋ねれば、10 通りの短いリストが返ってきます。誰もが iam:PassRole を挙げます。ほとんどがポリシーの編集を挙げます。その先は曖昧になります。本当の答えは長く、AWS が新しいサービスを出すたびに変わり、そして危険の大半は単一のアクションではなく組み合わせの中にあるからです。

そこで、私たちはそれを書き出しました。AWS 権限昇格マップ は、攻撃者が管理者アクセス、データ、あるいは再侵入の手段へと連鎖させ得るすべての権限のページです。サービス別、テクニック別、または権限の組み合わせで検索でき、どの項目も同じ読み方ができます。

各ページに載っているもの

すべての項目は 4 つの問いに答えます。その権限はどう使われるのか、単独でか、それとも他の権限と並んでのみか。どう見えるのか、呼び出しを記録する CloudTrail イベントとして。攻撃者のプレイブックのどこに位置するのか、MITRE ATT&CK のテクニックとして。そして何がその経路を取り除くのか、ディフェンダーが適用できる制御として。ページはその動きを、攻撃者プリンシパルからその権限が到達する先までの連鎖として描き、各ステップに実際の API アクションを添えます。

CreateFunction iam:PassRole runs as role 01 Attacker principal 02 New Lambda 03 Passed role 04 Administrator
マップにあるトキシックな組み合わせの 1 つ。lambda:CreateFunction と iam:PassRole を併せ持つと、プリンシパルは関数を作成し、特権ロールをそれに渡し、関数はそのロールとして実行されます。どちらの権限も単独では警戒するほどのものではありません。

経路を一歩ずつ

上の動きを見てみましょう。権限昇格の項目の半数以上が頼りにしているものです。2 つの別々のポリシーステートメントとして読めば、どちらも危険には見えません。連鎖させると、プリンシパルが付与されたことのないロールとして攻撃者のコードを実行します。

  • ステップ1. 普通のプリンシパルとして始める。 lambda:CreateFunction と iam:PassRole を持つ開発者ロールや CI ロールがあれば十分です。この時点ではまだ何も管理者ではありません。
  • ステップ2. 攻撃者のコードを持つ関数を作成する（lambda:CreateFunction）。 関数の本体は、攻撃者が実行したいものなら何でもかまいません。
  • ステップ3. 特権ロールをそれに渡す（iam:PassRole）。 プリンシパルが持つよりも大きなアクセス権を持つロール、たとえばすべてのバケットを読めるロールやポリシーをアタッチできるロールに、その関数を向けます。
  • ステップ4. それを呼び出すと、コードはそのロールとして実行される。 プリンシパルは付与されたことのないアクセス権を借り受けました。これが昇格のすべてです。
  • ステップ5. 断ち切り: iam:PassRole を特定のロール ARN にスコープし、iam:PassedToService を固定する。 このひとつの変更がこの経路を閉じ、マップの残りの大部分も閉じます。あなたの代わりにコードを実行するすべてのサービスが、渡されたロールを同じやり方で受け入れるからです。

これが 1 つの項目です。マップはカバーするすべての権限について同じ連鎖を描くので、その権限が自分のアカウントで不可欠かどうかを判断する前に、その動きを見ることができます。

iam:PassRole が共通の糸

マップにある権限昇格の項目のうち、半数以上が iam:PassRole に頼っています。これは 20 以上のさまざまなサービスに到達する経路に現れます。あなたの代わりにコードを実行するすべてのサービスが、渡したロールを受け入れるからです。Lambda、EC2、ECS、Glue、SageMaker、CodeBuild、Step Functions、その他すべてが、渡されたロールを受け取り、そのロールとして実行します。だからこそ、ワイルドカードリソースに対する 1 つの iam:PassRole の付与は、ほかのほとんどどの権限よりも攻撃者にとって価値があります。それを特定のロール ARN にスコープし、iam:PassedToService を固定すれば、マップの大部分が一度に閉じます。

単一の権限とトキシックな組み合わせ

単独で昇格する権限もあります。十分に広いリソースに対する iam:AttachUserPolicy は単独で昇格します。しかし、最も危険な経路の多くは 2 つ以上の権限を併せ持つ必要があり、そのどれも単独では警戒するほどには見えません。iam:PassRole は、それを使うサービスアクションがなければ無害です。lambda:CreateFunction は、渡すロールがなければ無害です。両方を持てば、特権ロールとして実行される任意のコードが手に入ります。

こうしたトキシックな組み合わせは、レビューをすり抜けるものです。ステートメントを 1 つずつ見るポリシー監査では、その組を決して見られないからです。マップは各項目を、直接悪用可能か、トキシックな組み合わせかとしてラベル付けし、組み合わせだけに絞り込めます。

権限のリストがすべてを語らない理由

このようなリファレンスは、どの権限が危険になり得るかを教えてくれます。どの権限があなたのアカウントで危険かは教えてくれません。それは、実際に誰がその権限を持っているか、信頼ポリシーと条件が噛み合っているか、SCP がすでにそれをブロックしているか、そしてそれが到達するロールが特権的かどうかに左右されます。同じ権限でも、あるアカウントでは不可欠で、別のアカウントでは純然たるリスクになり得ます。

そのため、マップは修正について意図的に慎重です。各ページはその経路を取り除く制御を示し、そのうえで、それを適用するかどうかは自動的な変更ではなくビジネス上の判断であると、はっきり述べています。パイプラインが依存する権限を外すことは、それ自体が一種の障害です。

使い方

運用しているサービスから始めて、その項目を読んでみてください。これから付与しようとしている権限を検索し、それが何を開くのかを見てみてください。2 つの権限を入力して、それらが組み合わさって経路を形成するかどうかを確認してみてください。各ページは、今日からアラートを設定できる検知イベントと、ご自身のマッピング用の MITRE テクニックをリンクしています。ですからこのマップは、ハードニング、検知、脅威モデリングのいずれにも役立ちます。

Pathbreak での使い方

このマップは、Pathbreak があなたのアカウント内で推論する内容の公開版です。私たちは読み取り専用で接続し、実際の IAM ポリシー、ロール、信頼関係を解決して、これらの経路のうちどれがあなたのアイデンティティに対して実際に存在するかを確認します。それから、それぞれがどれだけ開くかで順位付けし、あなたの脅威モデルとビジネス文脈を踏まえて、どの少数の変更が最も多くを断ち切るかを示します。最初の検証済み経路は 1 時間以内に返ってきます。

よくあるご質問

最も危険な AWS IAM 権限は何ですか。

iam:PassRole は、権限昇格の経路で最も多く再利用される単一の権限です。ワイルドカードリソースに対して付与されると、プリンシパルは、自分が実行できるサービス（Lambda や EC2 など）に特権ロールを渡し、そのロールを引き継げます。これは単独でではなく、サービスアクションと組み合わさって危険になります。それが、しばしば広すぎるまま放置される理由の一部です。 Pathbreak の AWS 権限昇格マップでは、それを経路に変えるすべての組み合わせを確認できます。

権限のトキシックな組み合わせとは何ですか。

それは、個別には安全でありながら、1 つのプリンシパルが併せ持つと昇格を可能にする、2 つ以上の権限の組です。iam:PassRole と lambda:CreateFunction は典型的な例です。ポリシーステートメントを 1 つずつ確認するレビューはこれらを見逃します。リスクはどちらか一方の権限ではなく、その組み合わせにあるからです。 Pathbreak のマップでは、これらをトキシックな組み合わせとして表示しています。

これらの権限のうち、どれが実際に自分のアカウントで危険かをどう知ればよいですか。

それらを実際の認可に照らして検証します。ある権限が経路を形成するのは、プリンシパルが実際にそれを持ち、信頼ポリシーと条件がそれを許し、どのガードレールもそれをブロックせず、到達するロールが特権的である場合に限られます。Pathbreak はこれを読み取り専用で解決し、理論上リスクになり得るすべての権限ではなく、解決する経路だけを報告します。

マップにある権限をすべて削除すべきですか。

いいえ。これらの権限の多くは正当な役割を果たしています。マップは各経路を取り除く制御を示しますが、それを適用するかどうかはビジネス上の判断です。正しいやり方は、どの経路が存在するかを検証し、それらがどれだけ開くかで順位付けし、依存しているものを壊さずに、最も重要な少数を断ち切ることです。 Pathbreak は、そのうちどれがお使いのアカウントで実際の経路を形成するかを検証するため、それらから先に修正できます。

マップは権限昇格以外もカバーしていますか。

はい。権限昇格に加えて、認証情報へのアクセス、自社のロギングやガードレールに対する防御回避、外部や公開プリンシパルへのリソース露出、データへのアクセス、そして永続化もカバーしています。実際の攻撃経路は、被害に至るまでにこれらのカテゴリーをまたぐからです。 Pathbreak はこのマップを管理し、同じ手法を自社プラットフォームで検証しています。

関連記事

これらの経路のうち、どれがご自身の AWS アカウントに存在するかをご覧ください。

無料スキャンを申し込む