ブログ

Weave Scopeの悪意ある利用を防ぐ

Weave Scopeの悪意ある利用を防ぐ

本文の内容は、2020年12月10日にVicente Herrera Garcíaが投稿したブログ(https://sysdig.com/blog/mitigating-weave-scope/)を元に日本語に翻訳・再構成した内容となっております。

IntezerとMicrosoftは9月9日、TeamTNTのハッカーが侵入の補助ツールとして侵害されたシステムにWeave Scopeを配備していることを報告した。Weave Scopeは、サーバーインフラストラクチャーを管理するための合法的で強力なツールで、一度配備すれば、すべてのリソースを簡単に制御できるようになります。

この記事では、このツールがどのように悪意を持って利用されるのか、また、このツールを探すためにセキュリティ設定に特定のチェックを追加する方法について説明します。

脆弱性のコンテキスト

TeamTNTが最初に侵入するために使用した脆弱性は、インターネットに公開された無防備なDocker APIエンドポイントでした。それを悪用した後、彼らはシステム全体をスキャンするためのツールとしてWeave Scopeをデプロイしていきました。

攻撃の流れ

  1. 攻撃者は、保護されていない公開されたDocker APIを特定しました。
  2. 攻撃者は、公開されたDockerデーモンを実行しているホスト上で新しいUbuntuコンテナを起動しました。
  3. 新しいコンテナはホストのファイルシステムをマウントし、機密情報へのアクセスを許可しました。
  4. 彼らは、サーバにSSHするために使用できる新しい特権ユーザを作成しました。
  5. ホストに接続した後、Weave Scopeアプリケーションをダウンロードしてインストールしました。
  6. 彼らはポート4040を介してWeave Scopeコンソールに接続しました。
  7. これにより、攻撃者はKubernetes環境を完全に可視化することができ、機密性の高い資産を特定して環境を乗っ取ることができました。
December_001.png

公開されたDocker APIとWeave Scopeリーチの影響

公開されたDocker APIにより、攻撃者はルートユーザーとしてインフラストラクチャー内のワークロードを実行することができます。この方法では、攻撃者はホストオペレーティングシステム、実行中のすべてのコンテナ、そして場合によってはクラスターのインフラストラクチャのすべてにアクセスすることができます。

そこから、Weave Scopeは、すべてのワークロードをスキャンして、さらなる脆弱性を探し、安全ではない情報を流出させ、クリプトマイナーのような追加のワークロードを実行することを容易にしようとしています。また、Weave Scopeが終了してDocker APIエンドポイントが安全になった場合に利用できるように、追加のエクスプロイトを仕込むこともできます。

Weave Scopeのトポロジーグラフのスクリーンショット

December_002.png

公開されたDocker APIのポートとWeave Scopeの使用を緩和する

公開されたDocker APIポート

このエクスプロイトを使って何がインストールされていたかは誰にもわからないので、危険にさらされている可能性があると思われる場合は、すべてのインフラストラクチャーの完全なセキュリティ監査を行うことをお勧めします。

しかし、簡単にチェックするには、まずDocker APIのポートがしっかりと保護されていて、公開IPからアクセスできないことを確認してください。以下のコマンドで外部からポート2376(デフォルトのDockerポート)に到達することで確認できます。

export public_ip=<your_infra_public_ip>
nc -z $public_ip 2367 ; if [ "$?" = "1" ]; then echo "Port not exposed" ; else echo "Port exposed" ; fi 

クラウドで管理されたコンテナプラットフォームは、デフォルトでセキュアなアプローチを使用します。ワークロードに安全な方法で接続する方法について、彼らの推奨事項に従うようにしてください。

自分でDockerやKubernetesをデプロイしたことがある人は、それらが逆のパラダイムに従っていることを知っておく必要があります。彼らの場合、デフォルトではすべてのものが安全ではなく、自分でセキュリティを追加するようにしなければなりません。安全なKubernetesのデプロイDockerのインストールは、些細な作業ではありません。DockerとKubernetesは、箱から出して自動的に多くの管理メカニズムを提供していますが、それでもセキュリティと認証の設定には注意しなければなりません。

CNCFのインキュベーションプロジェクトであるFalcoは、クラウドネイティブ環境での異常な活動を検知するのに役立ちます。さらなる予防策として、このようなFalcoルールを使用して、ローカルネットワークの外部からポート2376への接続を検出することができます。

- rule: Connection to exposed Docker API on port 2376
  desc: Detected connection to exposed Docker API on port 2376
  condition: >
    (inbound_outbound) and fd.sport=2376
    and not fd.snet in (rfc_1918_addresses))
  output: >
    Detected connection to exposed Docker API on port 2376
    (command=%proc.cmdline connection=%fd.name user=%user.name
    container_id=%container.id image=%container.image.repository)
priority: CRITICAL
tags: [network] 

Weave Scopeのデプロイを検出

DockerやKubernetesのインフラストラクチャーにWeave Scopeが既にデプロイされているかどうかを確認する必要があります。

Docker上で実行中のイメージをすべてチェックするのは、docker psを使えば簡単です。

docker ps | grep weavescope

Kubernetes上で実行中のイメージの一覧を取得するには、以下のように実行します。

$ kubectl get pods -o jsonpath="{..image}" --all-namespaces |\
    tr -s '[[:space:]]' '\n' |\
    sort |\
    uniq -c 

イメージスキャナーは、Weaveworks/scopeをグローバルブロック/禁止リストに追加して、Weave Scopeイメージを検出するのにも役立ちます。

また、Falcoを活用して、DockerやKubernetes上でイメージが気づかれずに実行されるのを防ぐために、次のようなルールを設定することもできます。

- rule: Launch of Weave Scope network tool container
  desc: Detect launching Weave Scope network tool container
  condition: >
    container and
    container.image.repository startswith 'weaveworks/scope'
  output: >
    Detect launching Weave Scope network tool binary process running
    (command=%proc.cmdline connection=%fd.name user=%user.name
    user_loginuid=%user.loginuid container_id=%container.id
    image=%container.image.repository)
  priority: WARNING
  tags: [network] 

イメージは、オリジナルの Weave Scope とは異なるレジストリとイメージ名の組み合わせでデプロイされる可能性があることを覚えておいてください。そのため、イメージ名に依存しないチェックを追加する必要があります。

例えば、イメージスキャナの中には、特定のファイルやフォルダを検出できるものもあります。Weave Scopeは正規のツールなので、脆弱性のデータベースには出てこないことを覚えておいてください。Docker HubのWeave Scopeのイメージエントリにアクセスすると、そのentrypointは下記の通りとなります。

ENTRYPOINT ["/home/weave/scope" "--mode=probe" "--no-app" "--probe.docker=true"]

そこで、その特定のエンドポイントをチェックするためのイメージスキャンポリシーを作成しておけば、イメージの名前やソースが違っていても、このツールを検出することになります。

一番良い方法は、追加のパラメータが変更された場合に備えて、"*/home/weave/scope*"との"like"比較を使用することです。

December_003.png

理想的には、このポリシーをKubernetesのアドミッションコントローラで使用するように設定し、一致するイメージがデプロイされないようにします。また、CIパイプラインにインラインスキャンステップを含めることで、非準拠のイメージがレジストリに到達するのをブロックします。

最後の防御策は、ディレクトリとバイナリの組み合わせがDockerホストのカーネル、またはKubernetesノードで実行されているかどうかを検出するためのFalcoルールを追加することで、デプロイに使用された方法の性質に関係なく検出することです。

- rule: Weave Scope network tool binary process
  desc: Detect the Weave Scope network tool binary process running
  condition: spawned_process and proc.cmdline contains 'weave/scope'
  output: >
    Detect launching Weave Scope network tool binary process running
    (command=%proc.cmdline connection=%fd.name user=%user.name
    user_loginuid=%user.loginuid container_id=%container.id
    image=%container.image.repository)
  priority: CRITICAL
  tags: [network, weave_scope] 

まとめ

公開されたDocker APIエントリポイントは非常に危険な脅威のベクトルであり、強力なWeave Scopeツールと組み合わせることで、インフラストラクチャー全体を非常に迅速に危険にさらす可能性があります。

Sysdig Secureは、インラインスキャン、Falcoを使用したランタイムセキュリティ、アドミッションコントローラ、イメージアナライザー機能でお客様をサポートします。今すぐSysdigをお試しください!

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top