本文の内容は、2021年3月30日にStefano Chiericiが投稿したブログ(https://sysdig.com/blog/lateral-movement-cloud-containers/)を元に日本語に翻訳・再構成した内容となっております。
クラウドセキュリティでは、ラテラルムーブメントが懸念されています。つまり、クラウドインフラの一部が侵害されると、攻撃者はどこまで到達出来てしまうのでしょうか?
クラウド環境への有名な攻撃では、一般に公開されている脆弱なアプリケーションが侵入口となることがよくあります。攻撃者はそこからクラウド環境の内部に移動し、機密データを流出させようとしたり、クリプトマイニングなどの目的でアカウントを使用したりします。
この記事では、攻撃者がクラウドのアカウントにフルアクセスする方法を紹介するために、段階的ではありますが、現実のシナリオを紹介します。また、Sysdig Cloud Connectorを使用して、この種の攻撃を検出し、軽減する方法についても説明します。
ラテラルムーブメントのシナリオ
クラウドセキュリティの演習では、脆弱なStruts2アプリケーションがKubernetesクラスター内で動作し、AWSアカウント内でホストされている状態から始めていきます。
攻撃者がポッドにアクセスすると、ラテラルムーブメントを実行して権限を昇格させるためのシークレットや認証情報を探して環境を評価します。
これらの認証情報は、awsのメタデータの中にある可能性があります。取得すると、攻撃者はAWSアカウントにアクセスできるようになり、そこからいろいろと調べ始めることができます。
クラウドインフラにアクセスできるようになると、攻撃者は次の行動を可能にするような設定ミスを探します。例えば、自分の権限を維持することでポジションを固めたり、クラウドの防御力を低下させたり、自分の権限を拡大させたりします。最終的には、攻撃者は、データを流出させたり、クリプトマイナーやボットのコントロールセンターをインストールしたりすることで、被害をもたらします。
さて、敵の全体的な戦略を理解したところで、敵の行動を詳しく見ていきましょう。
ステップ1: 公開されているWebアプリケーションを利用する
クラウドMITRE ATT&CKで報告されている初期アクセスTTP(戦術、技術、手順)の1つに「公開されているアプリケーションの悪用」があります。これは理にかなっています。結局のところ、公開されているものはすべて、すでにアクセス可能です。このシナリオでは、Apache Struts2アプリケーションが公開されています。
利用可能なインスタンスが有名な脆弱性の影響を受けているかどうかを確認するために、攻撃者は受動的かつ能動的な情報収集活動を開始します。ウェブアプリケーションとインタラクトすることで、ソフトウェアのバージョンや、デプロイされたアプリケーションに関するその他の追加情報を取得することができます。そこから、攻撃者は脆弱性データベースを照会し、侵入口を探します。
攻撃者は、使用しているApache Struts2のバージョンに、マシン上でのリモートコード実行を可能にするCVE-2020-17530の脆弱性があることを発見します。攻撃者は、この脆弱性を利用することができれば、システム内でリバースシェルを開くなど、マシン内で任意のコードを実行することが可能になります。
攻撃者がサーバーに細工したHTTPリクエストを送信すると、被害者のホストから攻撃者のマシンに向けてシェルが開きます。

リバースシェルを開くために必要なbashコマンドには特殊文字が含まれており、実行時にエラーが発生する可能性があります。これを避けるために、コマンドをbase64でエンコードし、実行時にデコードするのが一般的です。
ホスト名がapache-struts-6c8974d494であることから、攻撃者はKubernetesクラスター内のポッドやコンテナに侵入したことがわかります。
ステップ2:クラウドへのラテラルムーブメント
さて、攻撃者は侵入した後、地勢を考慮しなければなりません。コンテナに着地したことで、攻撃者はかなり制限されていると思うかもしれません。その通りですが、攻撃者にはクラウドのセキュリティを侵害するためのオプションがいくつかあります。攻撃者は、ポッドがAWSインスタンスのメタデータにアクセスできるかどうかを確認します。

このように見えます。クラウド環境に関する有益な情報があり、攻撃者が特権を昇格させたり、ラテラルムーブメントを行うのに役立つかもしれません。
IAM認証情報を見ると、攻撃者はポッドが実行されているKubernetesノードに関連するAWS IAMロール認証情報を見つけます。

これで、攻撃者は自分の環境で認証情報をインポートし、cli経由でクラウドアカウントに直接アクセスすることができます。

ステップ3:ポリシーの誤設定による特権の昇格
この時点で、攻撃者は盗んだ認証情報を使ってAWSアカウントに接続することができます。まず最初に行うことは、なりすましたロールに付随するロールとポリシーの評価を開始し、クラウド環境内で特権を昇格させる方法を見つけようとします。

devAssumeRoleポリシーは有望です。どのような権限が付与されるのか見てみましょう。

AssumeRoleでは、敵対者は他のユーザとして行動することができます。これは、このようなアカウントに付与するには奇妙な権限です。これは、攻撃者が探していたような、誤った設定である可能性があります。
また、ReadOnlyAccess権限があれば、攻撃者はAWSアカウントで利用可能な役割を列挙し、実施されている制限に基づいてどの役割を担うことができるかを見つけることができます。この場合、攻撃者は “dev “で始まるロールになりすますことができます。現在のユーザーが仮定できるロールの1つはdev-EC2Fullで、EC2の完全な制御を許可します。

このロールを使用すると、攻撃者はEC2インスタンスに対するフルアクセスを持つdevユーザーのように振る舞うことができ、自分の目的のために新しいインスタンスを作成することもできます。
次のステップ
これまでの説明と、2つの主な流れを振り返ってみましょう。- 脆弱な公開用アプリケーションがKubernetesの本番環境で稼働している。それを攻撃者が環境への侵入口として利用する。
- 本番環境のエンティティ(Kubernetesノードを実行するEC2インスタンス)に取り付けられたdev関連のIAMポリシーの設定ミスにより、攻撃者がより強力な役割を担い、クラウド環境内の権限をエスカレートさせる。
Sysdig Secureを使ったラテラルムーブメント攻撃の検知
幸いなことに、この種の攻撃は非常に認識しやすい痕跡を残します。例えば、リバースシェルは通常とは異なるものであり、ランタイムセキュリティツールは容易にアラートを発することができます。さらに、セキュリティ・ツールは設定ミスを指摘することもできます。適切なツールを使うことで、クラウドのセキュリティを強化することができます。Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドを自信を持って実行するために必要な可視性を提供します。オープンソース・スタックをベースにSaaS型で提供されるため、運用と拡張が非常に簡単です。
Sysdig Secure for cloudでは、この攻撃を各ステップでどのように検出できるかを見てみましょう。
公開されているWebアプリケーションの悪用を検知する
攻撃者が脆弱性を悪用して、被害者のポッドにリバースシェルを開く方法を見てきました。システム・イベントを利用することで、Sysdigはこの出来事を知ることができます。すぐに使えるFalcoルールの1つがトリガーされ、アラートが生成されました:

このアラートには、KubernetesクラスターにデプロイされたSysdig Agentが収集したメタデータにより、多くの有用な情報が含まれています。関係するIPだけでなく、クラスター名、ネームスペース、ポッドのデプロイメントも含まれています。
しかし、アラートがトリガーされた後はどうなるでしょうか?コンテナが消えてしまったら、どうやってイベントを調査すればいいのでしょうか?
ランタイムポリシーの設定で、システムイベントのキャプチャーを有効にすることができます。これにより、ポリシーがトリガーされた時点でのすべてのシステムイベントが収集されます。

そして、Sysdig Inspectでフォレンジック分析を行い、攻撃者がシステム内で行ったことを知ることができます。
クラウドへのラテラルムーブメントの検出
攻撃者がポッドとの接続を確立した後、AWSインスタンスのメタデータを読み取ってクラウド環境の情報を収集した方法を見ました。Sysdig Inspectを使用して、Reverse Shellアラートがトリガーされたときにポリシーによって行われたキャプチャを分析し、これらのコマンドを見てみましょう。

まず、リバースシェルを開くのに使われたbashスクリプトを見ることができます。
そしてその後、AWSアカウントへのアクセスを許可するIAMシークレットを取得するために使用された内部IPへのcurlコマンドを見ることができます。
クラウドの悪意ある行動や設定ミスを検知する
Sysdig Secure for cloudを活用することにより、セキュリティ保護はクラウド環境全体に及びます。すでに導入されているランタイムルールに基づいて、アカウントにセキュリティ上の問題が検出された場合、セキュリティアラートが生成されます。ここでは、攻撃者がdev-EC2Fullというロールを想定してトリガーしたと思われるセキュリティアラートの例を紹介します。
このシナリオでは、環境の設定ミスにより、攻撃者が特権を拡大することができたことがわかります。もしセキュリティチームが、環境に誤設定が適用された直後にそれを検知できたとしたらどうでしょうか。
Cloud Connectorの機能を使用して、誤設定が適用された場合にアラートを生成するカスタムFalcoルールを作成することができます。
今回のケースでは、開発に関連するポリシーを、開発とは無関係のインスタンスロールに適用したことが誤設定の原因でした。ここで報告されているカスタムルールを使えば、このような特定のシナリオに対応した検出を行うことができます。
- rule: "Attach a dev-AssumeRole Policy to a non-dev Role" desc: "dev-AssumeRole Policy must be attached to only dev Roles so that only dev users can assume extra roles" condition: jevt.value[/eventName]="AttachRolePolicy" and (not jevt.value[/errorCode] exists) and (not jevt.value[/requestParameters/roleName] contains "dev") and jevt.value[/requestParameters/policyArn]="arn:aws:iam::720870426021:policy/dev-AssumeRole" output: The dev-AssumeRole has been attached to a Role (%jevt.value[/requestParameters/roleName]) which is not related to the dev. requesting IP=%jevt.value[/sourceIPAddress], AWS region=%jevt.value[/awsRegion], requesting user=%jevt.value[/userIdentity/arn]" priority: "WARNING" tags: - "cloud" - "aws" source: "aws_cloudtrail"

先ほどのセキュリティイベントと同様に、Sysdig Secure for cloudがいかに多くの有益な情報を提供しているかがわかります。コネクターによって収集された追加のメタデータのおかげで、イベントにはAWSアカウント、影響を受けたオブジェクト、アクションを実行したユーザに関する重要な情報が含まれています。
まとめ
今回紹介した現実のシナリオの攻撃は、敵対者がクラウド環境内を横移動することがいかに可能であるかを示しています。このような攻撃は、一般に公開されている脆弱なコンテナから始まる可能性があり、Sysdig Secureの機能を使って検知・軽減することができます。新しいSysdig Secure for cloudを活用することで、セキュリティチームはコンテナやクラウド資産に関連するセキュリティイベントをまとめ、脅威の検知を一元化し、クラウドセキュリティを強化することができます。これらはすべて、単一のツール、すぐに使えるポリシーで実現でき、さらにカスタム統合の必要はありません。
弊社のツールは、セキュリティイベントの調査を容易にします。セキュリティチームにとって重要な時には、すべての関連情報が同じ場所で、一元化されたタイムラインで、イベント間の相関関係を把握できます。
ぜひお試しください!
Sysdig Secure for Cloudを使えば、悪者が侵入する前に、クラウドの設定ミスに継続的にフラグを立てたり、流出した認証情報からの異常なログインなどの不審なアクティビティを検出することができます。これらはすべて単一のコンソールで実行されるため、クラウドのセキュリティ態勢を簡単に検証することができます。しかも、わずか数分で始められます。Sysdig Free Tierでは、無料でクラウドのセキュリティを確保できます!
Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドを自信を持って実行するために必要な可視性を提供します。オープンソース・スタック上に構築され、SaaS型で提供されており、根本的にシンプルな運用と拡張性を実現しています。
今すぐ無料トライアルをお申し込みください!