English
Español
Français
Deutsch
日本語
한국어
العربيةリソースポリシー経由で Lambda の呼び出しを自身に付与する
関数の呼び出しポリシーに自分を追加して実行をトリガーできます(実行ロールとして動作します)。
単独で権限昇格を付与します。
lambda:AddPermissionlambda:AddPermission は単独でも、関数の呼び出しポリシーに自身を追加してそれをトリガーできます (実行ロールとして動作します)。広いリソーススコープでは、それだけで外部または公開プリンシパルによるアクセスに至ります。
なぜ危険なのか
プリンシパルは特権的な関数に対して lambda:AddPermission を呼び出して、自分自身(または外部アカウント)を関数の呼び出しポリシーに追加し、続いてそれをトリガーできます。関数は実行ロールとして実行されるため、呼び出すことはそのロールとしてのコード実行です。狙いは関数ではなく、それが明け渡すロールと、そのロールが到達できるすべてです。攻撃者は既存の呼び出し付与を持つのではなく、呼び出しの錠を書き換えます。
MITRE ATT&CK では、これは権限昇格戦術の T1098 (アカウント操作) に対応します。AWS はこれを CloudTrail に AddPermission として記録します。この呼び出しは CloudTrail に記録されますが、通常の管理操作に紛れるため、目立たせるにはルールが必要です。
検知
AddPermission前提条件
関数に対する lambda:AddPermission。この悪用はさらに、SCP/境界/PrincipalOrgID のガードレールが過剰な付与を阻止せず、かつ関数の呼び出しが実際に実行ロールを明け渡すこと (攻撃者が影響を与えたコード、または関数が認証情報や出力を漏らす) を前提とします。信頼されたコードの単純な呼び出しではそうなりません。
MITRE ATT&CK
T1098 · アカウント操作戦術
権限昇格
これを取り除くコントロール: lambda:AddPermission を関数の所有者に限定し、呼び出しポリシーの書き込みを SCP で拒否し、関数のリソースポリシーで aws:PrincipalOrgID / SourceArn を必須にして、実行ロールを最小権限にします。
適用するかどうかは、その権限が環境内でどう使われているかによるため、自動的な修正ではなくビジネス上の判断となります。同じ権限でも、あるアカウントでは不可欠であり、別のアカウントでは純粋なリスクとなることがあります。
Pathbreak は、この経路がお客様のアカウントで成立するかどうかを確認し、どれだけ侵入口を広げるかで他の経路と比較して順位付けし、お客様の脅威モデルとビジネス上の背景を用いて、断ち切る価値のある経路を示します。
質問
lambda:AddPermission は何を可能にしますか。
関数の呼び出しポリシーに自分を追加して実行をトリガーできます(実行ロールとして動作します)。
lambda:AddPermission は単独で権限昇格できますか。
はい。十分に広いリソースに対して保持されていれば、他の権限なしで外部または公開されたプリンシパルへのアクセスに到達します。
リソースポリシーによる Lambda 呼び出しの自己付与はどのように検知されますか。
CloudTrail で AddPermission を監視します。この呼び出しは CloudTrail に記録されますが、通常の管理操作に紛れるため、目立たせるにはルールが必要です。
この経路はどうやって断ち切りますか。
これを取り除くコントロールの一例は次のとおりです。lambda:AddPermission を関数の所有者に限定し、呼び出しポリシーの書き込みを SCP で拒否し、関数のリソースポリシーに aws:PrincipalOrgID / SourceArn を必須とし、実行ロールを最小権限にします。適用するかどうかは、その権限がアカウント内でどう使われているかによるため、自動的な修正ではなくビジネス上の判断となります。
これはどの MITRE ATT&CK テクニックですか。
T1098、アカウント操作、権限昇格戦術に該当します。
関連する経路
参考資料
これを自分のアカウントで見つける
1 つの AWS アカウントに対して読み取り専用のスキャンを実行し、これらの経路のうちどれが存在するかを、影響範囲の順に、それぞれを断ち切る変更とともにお見せします。最初の検証済み経路は 1 時間以内に得られます。