権限昇格による横展開（Lateral Movement）の危険性 - Prisma^® Cloudから考えるセキュリティ（6）

クラウドサービス部の新山です。

ラックでは、Prisma^® Cloud（プリズマクラウド）を用いたクラウドセキュリティ統制支援サービスを提供しています。Prisma^® Cloudは、パロアルトネットワークス社が展開する、マルチクラウドやハイブリッドクラウド環境におけるクラウドリソースの設定上の脆弱性や不審な挙動を、業界標準の各種コンプライアンス基準や独自の基準に従い、継続的に監視・可視化するSaaS型のサービスです。

機能の1つとして、Prisma^® Cloud側で事前定義されたアラートポリシーに基づいて不適切な設定や不審な挙動を検知・アラートします。非常に多くのアラートポリシーが定義されているので、そのなかでも特に注意したいものを連載でお届けします。

連載6回目となる本記事では、「Privilege escalation risk due to a publicly exposed unauthenticated AWS Lambda function with iam:PassRole and AWS Glue DevEndpoint Creation permissions」というアラートポリシーを参考に、権限昇格による横展開（Lateral Movement）の危険性について紹介します。

アラートの内容

このアラートは、"iam:PassRole"および"glue:CreateDevEndpoint"権限を持つ、公開アクセス可能なAWS Lambdaを検知するものです。以下の条件をすべて満たすLambda関数を検出します。

インターネット上から誰でも呼び出せるLambda関数

Lambda関数がリソースベースポリシーを通じて、インターネットからの無制限アクセスを許可、かつEventSourceTokenやIAMポリシーによるアクセス制限が設定されていない状態は、以下のような危険性を招きます。

• 不正コードの実行
  誰でも任意のパラメータを指定してLambdaを呼び出せるため、機密情報の漏えいや不要なリソース操作を行うコードが実行される恐れがあります。
• 認証情報の悪用
  Lambda実行ロールが高い権限を持っている場合、その権限を攻撃者に乱用される可能性があります。
• サービス妨害（DoS）
  外部から大量リクエストを送られたり、意図的に処理コストの高い操作を呼び出されたりして、Lambdaの実行コストやリソースが圧迫されるリスクがあります。
• 横展開
  攻撃者がLambda経由で他のAWSリソースへのアクセス権を得た場合、クラウド全体への侵害が広がる可能性があります。

ロールの引き渡し権限とGlue DevEndpointの作成権限が割り当てられている

Lambda関数にiam:PassRole（他サービスへのIAMロール委譲）および、glue:CreateDevEndpoint（DevEndpoint作成）の両権限を持たせ、かつ認証なしで誰でも呼び出せる状態にしてしまうと、インターネット上の不特定多数がGlue DevEndpointを作成し、その上で任意のコード実行環境を起動できる状態となります。それだけでもリスクですが、コード実行環境が強い権限を持つ場合はインパクトがさらに増大します。

例えば、高権限のIAMロールを持つLambdaに、iam:PassRoleとglue:CreateDevEndpointを許可している場合、意図せず誰でも管理者権限に近い環境を起動できる踏み台を公開していることになり、インシデント時の影響範囲は極めて大きくなります。

Lambdaの関数URLの認証タイプが「NONE」に設定されている

Lambdaの関数URLの認証タイプが「NONE」になっているということは、認証なしでアクセスできるため、様々なリスクがあります。「インターネット上から自由に呼び出し可能なLambda関数」に記述したリスクに加え、以下が挙げられます。

• 違法・不正行為への利用
  攻撃者が不正用途のソフトウェアをLambda上で実行するなど、環境を踏み台にして他への攻撃を行うリスクもあります。

認証タイプが「NONE」に設定されていることについては連載第2回にて解説しましたので、対処方法を含めご一読ください。

これらの条件が揃うことはなかなかないと思いますが、このアラートが検知される可能性のある処理があると仮定し、以下にサンプル処理とリスクを伴う処理が不正に利用されることについて説明します。

サンプル処理フロー

• ①Lambda実行
  インターネット上でLambdaを実行する。
• ②S3から設定内容を参照
  S3のLambda用バケットに対して設定内容を参照する。
• ③DevEndpoint作成
  参照した設定内容をもとにGlue DevEndpointを作成する。その際、Lambdaに付与した権限をPassRoleさせて引き継ぐ。
• ④DevEndpointにSSH接続
  Glue DevEndpointにSSH接続をする。
• ⑤データ更新
  Lambda用のバケットにあるファイルを更新する。

サンプル処理のフロー図に記載しているように、Lambdaに付与されているIAMロールが処理する権限よりも過剰、かつ幅広く付与されている場合、以下のような不正処理が発生する可能性があります。

不正処理の例

• ①Lambda実行
  攻撃者が、認証不要で呼び出せるLambda関数を見つけ、攻撃目的で呼び出す。
• ②S3から設定内容を参照
  S3のLambda用バケットに対して設定内容を参照する。
• ③DevEndpoint作成
  設定内容をもとにGlue DevEndpointを作成する。その際、Lambdaに付与した権限をPassRoleさせて引き継ぐ。
• ④DevEndpointにSSH接続
  攻撃者は作成したGlue DevEndpointにSSH接続をする。
• ⑤LambdaのロールをGlue DevEndpointに付与
  Lambdaに付与された過剰、かつ幅広い権限を悪用し、高レベルの操作が可能となる。
• ⑥データ書き換え/機密情報取得
  S3のデータの改ざんや、Secrets Managerの機密情報の取得ができる。

①～④の処理は、攻撃目的でLambdaを実行している点は不正アクセスとみなすことができますが、処理としては正常処理の範囲となります。しかし、⑤以降の処理は本来想定していた処理とは異なり、不正処理と考えられます。もし仮に、攻撃者がSSH接続できなくとも、Glueの開発エンドポイントを無制限に作れてしまう場合、それだけで料金がかかってしまいますので、第三者がGlueの開発エンドポイントを作れてしまう状態というのは注意が必要です。

また、今回のアラートが深刻なのは、リスクが高い要素が組み合わさることで、影響が一気に拡大する構造になっている点です。外部公開されたLambdaにglue:CreateDevEndpoint権限があるということは、攻撃者がAWS基盤へ攻撃するための経路を自在に用意できるため、攻撃経路そのものが増殖します。さらに、GlueEndpointが広範囲への権限を持つため、ひとたび侵害された際の影響は一サービスにとどまらず、基盤全体へ波及しかねません。

対処方法

このアラートへの対処方法は、主に以下の4つが挙げられます。

• ①Lambda関数のパブリックアクセス制御
• ②Lambdaに付与するIAMロール見直し
• ③Lambdaに付与するIAMロールのiam:PassRoleの最小権限化
• ④Lambdaの関数URLの認証タイプの変更

今回は、権限昇格による横展開の危険性に焦点を当てたいので、②と③の対処方法に絞って解説します。

上記で挙げた対策以外にも、例えばCloudTrailの有効化など数多くのセキュリティ強化策が存在します。ここでは、あくまでも今回のアラートで指摘された条件に焦点を当てた対処法のみを取り上げています。そのため、記載した対処法以外の基本的な監視体制や全般的な設定についても、改めて総合的に見直しを行うことが極めて重要と言えるでしょう。なお、④については連載第2回で説明していますので、そちらをご確認ください。

Lambdaに付与するIAMロールの見直し

まず、Lambdaに付与するIAMロールは、AWSのセキュリティ設計のベストプラクティスに従い、最小権限の原則となっているのか見直しをします。もし、Lambdaに付与するIAMロールを共有ロールにし、複数のLambdaに付与するIAMロールを1つにしている場合は注意が必要です。Lambdaごとに必要となる権限が異なる場合、IAMロールを複数作成する必要がありますが、最小権限の原則に従い、セキュリティリスクを最小限に抑えることが可能です。

LambdaごとのIAMロールにすることで、"iam:PassRole"、"glue:CreateDevEndpoint"の権限が必要か確認をし、不要であれば削除します。もちろん、それ以外の権限についても不要なものは削除し、可能な限りResourceを"*"で指定しないなど、権限の有効範囲を限定的にすることも重要です。

Lambdaに付与するIAMロールのiam:PassRoleの最小権限化

Lambdaの処理の中で、どうしてもiam:PassRoleの権限が必要となる場合は、最小権限となるようIAMロールを設定することを検討してください。

①Resourceを明示的に制限

Resourceを"*"で無制限に許可するのではなく、渡してよいIAMロールのARNに限定します。その結果、想定外のロールを渡すことを防ぎ、攻撃者が誤って、あるいは悪意を持って高権限ロールを利用するリスクを低減できます。仮に侵入を許したとしても、ポリシーで明示したロール以上の権限エスカレーションを阻止できます。Resourceを"*"で許可している場合、Admin権限の付与も許可してしまっているので、IAMロールのARNに限定することはとても重要です。

②Conditionを活用してサービス制限

IAMロールを譲渡するサービスが明確に決まっているのであれば、iam:PassedToServiceにより、譲渡先サービスを限定します。想定外のサービスにロールを引き渡す可能性を排除できるので、横展開範囲の大幅な縮小が可能です。

以下のようにResourceを制限したり、Condition句でサービスを絞ったりすることでiam:PassRoleの最小権限化ができ、セキュリティ強化に繋がります。

おわりに

今回のポリシーでは、パブリック公開されているLambdaにロールの引き渡し権限とGlue DevEndpointの作成権限が付与されている場合に絞っていますが、別サービスでも脅威となる可能性はあります。Prisma^® Cloudでは、Glue DevEndpointの作成権限に限らず、特に注意すべきものをあらかじめポリシーとして用意しています。以下はその一例です。

• Privilege escalation risk due to a publicly exposed unauthenticated AWS Lambda function with iam:PassRole and CloudFormation Creation permissions
  →AWS CloudFormationスタックを作成できる権限が付与されており、スタックを通じて高権限ロールや追加リソースを作成可能になってしまうリスク。
• Privilege escalation risk due to a publicly exposed unauthenticated AWS Lambda function with iam:PassRole and lambda creation permissions
  →新しいLambda関数を作成する権限があり、PassRoleを併用して高権限ロール付きのLambdaを作成することで任意コード実行につなげられるリスク。
• Privilege escalation risk due to a publicly exposed unauthenticated AWS Lambda function with iam:PassRole and Redshift Cluster Creation permissions
  →新しいRedshiftクラスターを作成する権限を悪用し、高権限ロールをアタッチしたクラスターを立ち上げて任意コード実行やデータアクセスを行うリスク。
• Privilege escalation risk due to a publicly exposed unauthenticated AWS Lambda function with iam:PassRole and run EC2 instances permissions
  →EC2インスタンスを起動できる権限を利用して、高権限ロールを持たせたEC2を起動・操作することで権限エスカレーションが生じるリスク。

今回紹介したアラート以外にも、Prisma^® Cloudでは多数のセキュリティリスクを検知します。 そして、ラックの長年にわたるシステム開発とセキュリティのノウハウを集め提供する「クラウドセキュリティ統制支援サービス」では、検知したアラートの対応を支援するサービスも提供しています。AWS含め、パブリッククラウドのセキュリティに不安がありましたら、ぜひラックにご相談ください。