AWS - Lambda Privesc
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
lambdaに関する詳細情報:
AWS - Lambda Enumiam:PassRole
, lambda:CreateFunction
, (lambda:InvokeFunction
| lambda:InvokeFunctionUrl
)iam:PassRole
、lambda:CreateFunction
、およびlambda:InvokeFunction
の権限を持つユーザーは、特権を昇格させることができます。
彼らは新しいLambda関数を作成し、既存のIAMロールを割り当てることができ、そのロールに関連付けられた権限を関数に付与します。ユーザーはその後、このLambda関数にコードを書いてアップロードすることができます(例えばrev shellを使用して)。
関数が設定されると、ユーザーはその実行をトリガーし、AWS APIを通じてLambda関数を呼び出すことで意図したアクションを実行できます。このアプローチにより、ユーザーはLambda関数を介して間接的にタスクを実行し、それに関連付けられたIAMロールによって付与されたアクセスレベルで操作することができます。\
攻撃者はこれを悪用してrev shellを取得し、トークンを盗むことができます:
あなたはまた、lambda関数自体のlambdaロールの権限を悪用することができます。 もしlambdaロールに十分な権限があれば、それを使用してあなたに管理者権限を付与することができます:
lambdaのロール資格情報を外部接続なしで漏洩させることも可能です。これは、内部タスクで使用されるネットワーク隔離されたLambdaにとって便利です。逆シェルをフィルタリングしている未知のセキュリティグループがある場合、このコードはlambdaの出力として資格情報を直接漏洩させることを可能にします。
潜在的な影響: 指定された任意のlambdaサービスロールへの直接的な権限昇格。
興味深く見えるかもしれませんが、lambda:InvokeAsync
は単独では aws lambda invoke-async
を実行することを許可しません。lambda:InvokeFunction
も必要です。
iam:PassRole
, lambda:CreateFunction
, lambda:AddPermission
前のシナリオと同様に、lambda:AddPermission
の権限があれば、自分に lambda:InvokeFunction
の権限を付与することができます。
潜在的影響: 指定された任意のlambdaサービスロールへの直接的な権限昇格。
iam:PassRole
, lambda:CreateFunction
, lambda:CreateEventSourceMapping
iam:PassRole
, lambda:CreateFunction
, および lambda:CreateEventSourceMapping
権限を持つユーザー(おそらく dynamodb:PutItem
および dynamodb:CreateTable
も含む)は、lambda:InvokeFunction
なしでも間接的に 権限を昇格 させることができます。
彼らは 悪意のあるコードを持つLambda関数を作成し、既存のIAMロールを割り当てる ことができます。
ユーザーはLambdaを直接呼び出す代わりに、既存のDynamoDBテーブルを設定または利用し、イベントソースマッピングを通じてLambdaにリンクします。この設定により、テーブルに新しいアイテムが追加されると、ユーザーのアクションまたは別のプロセスによってLambda関数が 自動的にトリガー され、渡されたIAMロールの権限でコードが実行されます。
もしDynamoDBがすでにAWS環境でアクティブであれば、ユーザーはLambda関数のためにイベントソースマッピングを設定する必要があります。しかし、DynamoDBが使用されていない場合、ユーザーはストリーミングが有効な新しいテーブルを作成する必要があります:
今、イベントソースマッピングを作成することによってLambda関数をDynamoDBテーブルに接続することが可能です:
DynamoDBストリームにリンクされたLambda関数を使用して、攻撃者はDynamoDBストリームをアクティブにすることでLambdaを間接的にトリガーすることができます。これはDynamoDBテーブルにアイテムを挿入することによって実現できます:
潜在的な影響: 指定されたlambdaサービスロールへの直接的な権限昇格。
lambda:AddPermission
この権限を持つ攻撃者は自分自身(または他の人)に任意の権限を付与することができる(これはリソースベースのポリシーを生成してリソースへのアクセスを付与します):
潜在的な影響: コードを変更して実行する権限を付与することによって、使用されるlambdaサービスロールへの直接的な権限昇格。
lambda:AddLayerVersionPermission
この権限を持つ攻撃者は自分自身(または他の人)にlambda:GetLayerVersion
の権限を付与することができる。彼はレイヤーにアクセスし、脆弱性や機密情報を探すことができる。
潜在的な影響: 機密情報への潜在的なアクセス。
lambda:UpdateFunctionCode
lambda:UpdateFunctionCode
権限を持つユーザーは、IAMロールにリンクされた既存のLambda関数のコードを変更する可能性があります。
攻撃者はIAM資格情報を抽出するためにlambdaのコードを変更することができます。
攻撃者が関数を直接呼び出す能力を持っていない場合でも、Lambda関数が既に存在し稼働している場合、既存のワークフローやイベントを通じてトリガーされる可能性が高く、したがって変更されたコードの実行を間接的に促進することになります。
潜在的な影響: 使用されるラムダサービスロールへの直接的な権限昇格。
lambda:UpdateFunctionConfiguration
この権限を持つことで、ラムダが任意のコードを実行する環境変数を追加することが可能です。例えば、Pythonでは環境変数PYTHONWARNING
とBROWSER
を悪用して、Pythonプロセスが任意のコマンドを実行することができます:
他のスクリプト言語には、使用できる他の環境変数があります。詳細については、以下のリンクのスクリプト言語のサブセクションを確認してください:
Lambda Layersは、コードをラムダ関数に含めることを可能にしますが、別々に保存するため、関数コードは小さく保たれ、複数の関数がコードを共有できます。
ラムダ内では、次のような関数を使用して、Pythonコードが読み込まれるパスを確認できます:
これらの場所です:
/var/task
/opt/python/lib/python3.7/site-packages
/opt/python
/var/runtime
/var/lang/lib/python37.zip
/var/lang/lib/python3.7
/var/lang/lib/python3.7/lib-dynload
/var/lang/lib/python3.7/site-packages
/opt/python/lib/python3.7/site-packages
/opt/python
例えば、ライブラリboto3は/var/runtime/boto3
(4番目の位置)から読み込まれます。
lambda:UpdateFunctionConfiguration
の権限を悪用して、新しいレイヤーをlambda関数に追加することが可能です。任意のコードを実行するには、このレイヤーにlambdaがインポートするライブラリを含める必要があります。lambdaのコードを読むことができれば、これを簡単に見つけることができます。また、lambdaがすでにレイヤーを使用している可能性があり、そのレイヤーをダウンロードしてあなたのコードを追加**することができるかもしれません。
例えば、lambdaがライブラリboto3を使用していると仮定すると、これはライブラリの最新バージョンを持つローカルレイヤーを作成します:
You can open ./lambda_layer/boto3/__init__.py
and グローバルコードにバックドアを追加します(例えば、資格情報を外部に送信する関数やリバースシェルを取得する関数など)。
次に、その ./lambda_layer
ディレクトリをzip圧縮し、新しいlambdaレイヤーを自分のアカウントにアップロードします(または被害者のアカウントにアップロードしますが、その場合は権限がないかもしれません)。
/opt/python/boto3を上書きするために、pythonフォルダを作成し、ライブラリをそこに置く必要があることに注意してください。また、レイヤーはlambdaで使用されているpythonバージョンと互換性がある必要があります。アカウントにアップロードする場合は、同じリージョンにある必要があります:
アップロードしたラムダレイヤーを任意のアカウントからアクセス可能にします:
そして、被害者のlambda関数にlambdaレイヤーを添付します:
次のステップは、関数を自分で呼び出すか、通常の手段で呼び出されるのを待つことです。これはより安全な方法です。
この脆弱性を利用するよりステルスな方法は以下にあります:
AWS - Lambda Layers Persistence潜在的な影響: 使用されるlambdaサービスロールへの直接的な権限昇格。
iam:PassRole
, lambda:CreateFunction
, lambda:CreateFunctionUrlConfig
, lambda:InvokeFunctionUrl
これらの権限があれば、関数を作成し、URLを呼び出して実行できるかもしれません... しかし、テストする方法を見つけられなかったので、もし見つけたら教えてください!
いくつかのラムダは、ユーザーからのパラメータで機密情報を受け取ることになります。もしそのうちの1つでRCEを取得できれば、他のユーザーが送信している情報を抽出できます。詳細は以下を確認してください:
AWS - Steal Lambda RequestsAWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)