クラウドにおけるラテラルムーブメント：脆弱なコンテナから侵入する

By 清水 孝郎 - JULY 25, 2022
Topics: クラウド セキュリティ, コンテナ、Kubernetes、ホストのセキュリティ

SHARE:

本文の内容は、2022年7月25日にStefano Chiericiが投稿したブログ(https://sysdig.com/blog/lateral-movement-cloud-containers/)を元に日本語に翻訳・再構成した内容となっております。

クラウドセキュリティでは、横方向の移動が懸念されています。つまり、クラウドインフラの一部が侵害された場合、攻撃者はどこまで手を伸ばすことができるのでしょうか？

Blackhat booth 1760 Sysdig
このチャットに参加すると、不気味なクラーケンのシャツがもらえます。会期中は、楽しいサプライズやエンターテイメントをご用意しています。

クラウド環境への有名な攻撃でよく起こるのは、一般に公開されている脆弱なアプリケーションが侵入口として機能することです。そこから攻撃者はクラウド環境内に移動し、機密データの流出を試みたり、クリプトマイニングのような自分たちの目的のためにアカウントを使用しようとしたりします。



この記事では、攻撃者がクラウドアカウントにフルアクセスする方法を、段階的ではありますが、現実のシナリオで紹介します。また、Sysdig Cloud Connectorを使用して、この種の攻撃を検知し、軽減する方法についても説明します。

ラテラルムーブメントのシナリオ

このクラウドセキュリティの演習を、Kubernetesクラスターで作動させ、AWSアカウント内でホストされている脆弱なStruts2アプリケーションから始めて行きたいと思います。



攻撃者はポッドにアクセスすると、横移動と特権の拡大を行うために、シークレットや認証情報を探して環境を評価します。

これらの認証情報は、awsのメタデータ内に潜在的に存在する可能性があります。一度取得すると、攻撃者はAWSアカウントにアクセスできるようになり、そこから詮索を始めることができるようになります。

クラウドインフラストラクチャーにアクセスできるようになると、攻撃者は次の行動を可能にするような誤った設定を探すことになります。例えば、権限の持続による地位の強化、クラウド防御の障害、権限の昇格などです。最終的に攻撃者は、データの流出や、クリプトマイナーやボットコントロールセンターをインストールすることで、被害を与えることができます。

さて、敵の全体的な戦略を理解したところで、彼らの行動をより深く掘り下げてみましょう。

ステップ1：一般公開されているWebアプリケーションを悪用する

Cloud MITRE ATT&CKで報告されている初期アクセスTTP（戦術、技術、手順）の1つに、Exploiting Public-Facing Application（パブリック向けアプリケーションを悪用する）があります。これは理にかなっています。結局のところ、公開されているものは何でもすでにアクセス可能なのです。

このシナリオでは、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つは、EC2を完全に制御できる dev-EC2Fullです。



このロールになりすますと、攻撃者はEC2インスタンスにフルアクセスできるdevユーザーのように振る舞うことができ、自分の目的のために新しいインスタンスを作成することができます。

次のステップ

ここまでの説明と、2つの主なフローを振り返ってみましょう。

  1. Kubernetesの本番環境では、脆弱性のある公開アプリケーションが動作しています。それを攻撃者が環境へのエントリーポイントとして利用します。
  2. 本番環境エンティティ（Kubernetesノードを実行するEC2インスタンス）に紐付けた開発関連IAMポリシーの設定ミスにより、攻撃者がより強力な役割を担い、クラウド環境内で特権をエスカレートさせることができます。
  3. この時点で、攻撃者は私たちの組織に害を及ぼすのに十分な権限を持っています。攻撃者は、今すぐ行動を開始するか、あるいはさらにクラウドのセキュリティを侵害して、より大きなアクセス権を得ようとする可能性があります。攻撃者が取り得る次のステップについてのより包括的な見解と、これらの攻撃を防止、検出、および軽減するためにAWSが提供するツールについて、「AWSクラウドとコンテナのための統合された脅威検知」の記事を見逃さないでください。

Sysdig Secureを使用したラテラルムーブメント攻撃の検出

幸いなことに、この種の攻撃は非常に認識しやすい痕跡を残します。例えば、リバースシェルは通常とは異なるものであり、ランタイムセキュリティツールは簡単にアラームを発することができます。さらに、セキュリティ・ツールは、設定ミスにフラグを立てることもできます。適切なツールを使用することで、クラウドのセキュリティを強化することができます。

Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、およびクラウドを自信を持って実行するために必要な可視性を提供します。オープンソースのスタックをベースにSaaS型で構築されているため、実行と拡張が根本的にシンプルです。

Sysdig Secure for cloudを使用して、この攻撃を各ステップでどのように検出することができるかを見てみましょう。

公開型Webアプリケーションの悪用を検知する

攻撃者がどのように脆弱性を悪用し、被害者のポッドでリバースシェルを開くことができたかを見てきました。

システムイベントを利用することで、Sysdigはそれが起こったことを知ることができます。数あるFalcoルールのうちの1つがトリガーされ、アラートが生成されました。



Kubernetesクラスターに配置されたSysdigエージェントによって収集されたメタデータのおかげで、アラートには多くの有用な情報が含まれています。アラートには、関係するIPの他に、クラスター名、ネームスペース、ポッドのデプロイメントが含まれています。

しかし、アラートがトリガーされるとどうなるのでしょうか？コンテナが消えてしまった場合、どのようにイベントを調査すればいいのでしょうか？

ランタイムポリシーの設定で、システムイベントキャプチャーを有効にすることができます。これにより、ポリシーがトリガーされた時点のすべてのシステムイベントが収集されます。



その後、Sysdig Inspectでフォレンジック分析を行い、攻撃者がシステムで何を行ったかを知ることができます。

クラウドへのラテラルムーブメントの検出

攻撃者がポッドとの接続を確立し、AWSインスタンスのメタデータを読み取ってクラウド環境に関する情報を収集する様子を確認しました。

Reverse Shellアラートがトリガーされたときにポリシーによって行われたキャプチャーを分析するためにSysdig Inspectを使用して、これらのコマンドを見てみましょう。



まず、リバースシェルを開くために使用された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を使用すると、悪者が侵入する前にクラウドの誤設定に継続的にフラグを立てたり、漏洩した認証情報からの異常なログインなどの疑わしいアクティビティを検出することができます。これらはすべて1つのコンソールで実行されるため、クラウドのセキュリティ態勢を簡単に検証することができます。しかも、わずか数分で使い始めることができます。




Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドを自信を持って実行するために必要な可視性を提供します。オープンソースのスタック上に構築され、SaaS型で提供されるため、運用や拡張が極めてシンプルです。

無料トライアルをお申し込みください。

8月11日（木）10:00-11:30に開催されるセッションに参加しませんか？

BlackHat Arsenal Falco Plugins