脅威：Kubernetesクラスタを攻撃するために作成された初のコンテナイメージ #aqua #セキュリティ #コンテナ #kubernetes #動的分析 #DTA

本ブログは「Aqua Security」社の技術ブログで2020年11月23日に公開された「 Threat Alert: Market-First Container Image Built to Attack Kubernetes Clusters 」の日本語翻訳です。

脅威：Kubernetesクラスタを攻撃するために作成された初のコンテナイメージ

---

Aqua の Team Nautilus(セキュリティチーム)は、Kubernetes クラスタの脆弱性を発見して悪用することを可能にするコンテナイメージを初めて発見しました。攻撃者は、開発者を騙して悪意のあるイメージをダウンロードさせるために、Docker Hub に作成した紛らわしいアカウントを利用してこのマルウェアを伝播させます。私たちの知る限りでは、サイバー攻撃者がこの手法を用いて Kubernetes クラスタの脆弱性を特に標的にしてクラウドネイティブスタックを悪用している初めてのケースです。

Aqua の Dynamic Threat Analysis(DTA)スキャナを使用して、Docker Hub アカウントから11個の悪意のあるコンテナイメージを発見しました(イメージと IoC の完全なリストは以下に記載しています)。攻撃者がこのアカウントを作成したのは、正規のソフトウェアプロバイダになりすまし、疑いを持たない開発者にダウンロードさせ、通常通りに使用させるためだと考えています。

これらのコンテナイメージはどのようにして攻撃するか

コンテナイメージのエントリポイントは、コンテナ化された環境からホストを乗っ取ることを試みるために設計された攻撃的セキュリティツール(OST)である DEEPCE を実行するように設定されており、このコンテナイメージはターゲットの環境で実行するように設計されていることに他なりません。このコンテナイメージの他にも、API サーバ、Pod、kublet API、Docker API、docker.sock などの脆弱性を検出するなど、攻撃者が Kubernetes クラスタに対してさらに悪意のある攻撃を行うことを可能にする OST が含まれています。

精密検査の結果、再び TeamTNT の仕業であることを発見

調査の初期段階で、私たちは不審な Docker Hub アカウント「portaienr」を検出しました。私たちは経験に基づいた直感から、TeamTNT が正当な Docker Hub アカウントとソフトウェア(Portainer)を装うため、このアカウントを作成したのではないかと考えました。このアカウントはタイポスクワッティング(ウェブサイトのアドレスを入力する際の(タイプミスなどの)よくあるミス)を狙っています。ユーザが「portainer」を「portanier」とタイプミスすると、攻撃者のアカウントが提供する、悪意のあるコンテナイメージを pull する恐れがあります。

成果物の調査を進めた結果、このアカウントは TeamTNT に属していると結論づけました。TeamTNT の C2サーバ(teamtntnt[.]red)から悪意のあるコンポーネントをダウンロードするいくつかのコンテナイメージがあったためです。さらに、ほとんどのコンテナイメージは、以前のキャンペーンで TeamTNT が利用したバイナリが含まれていました。たとえば、bioset(MD5=283e0172063d1a23c20c6bca1ed0d2bb)は、マルウェアをコンテナに展開後、攻撃者がホストへ接続できるようにするバインドシェルとして機能します。また、ziggy(MD5=03647c6ae05aa8e4475d8ade50016385)は、TeamTNT の武器としてよく使用されるマルウェア Tsunami と同じものです。

私たちの主張を証明するにあたり、この Docker Hub アカウントからの他の攻撃を探すために、短期間の OSINT 調査(複数の方法によるアプローチ)を行いました。

OSINT 調査で他の被害者も判明

最近、仮想プライベートサーバ(VPS)が TeamTNT によって攻撃されたと主張する投稿が Reddit に投稿されていました。その投稿では、ホスティング会社から「悪質なトラフィックがサーバの IP アドレスから発信されている」と苦情を受けた、と報告していました。迅速な検査の結果、彼は新しいユーザ(Hilde)と SSH 鍵をサーバ上で発見しました。さらに、悪意のあるシェルスクリプト(Docker MassAutoInfect V1.2 by (c) 2020 by hilde[@]TeamTNT[...]red)を発見しました。これは他の TeamTNT の悪意のあるスクリプトと相関しています。

この被害者は Portainer も使用していて、Docker API や Portainer の設定で「何かミスをした」可能性があると主張しました。また、多くのコンテナで docker.sock を理由もなくマウントされていたとも述べていました。Reddit ユーザの詳細から、VPS がすべてのポート、特に2375番ポートへのインバウンドトラフィックを許可していたことがわかりました。被害者が提供した証拠から、私たちは Masscan や Shodan エンジンを使用することで、TeamTNT の暗号ワームが開放されている2375番ポートを自動的に検出し、VPS 上にコンテナイメージ「portaienr/allink:latest」をデプロイして実行したと推測しました。

次に、ある1つのイメージ(portaienr/bobedpei:latest)に注目しました。その理由は、Kubernetes と Linux Container(LXC)環境の脆弱性を発見し、悪用するように設計された自作のオープンソースツールが含まれていたからです。さらなる分析の結果、このイメージには Kubernetes クラスタへの攻撃するよう設計された、興味深いバイナリやスクリプトが含まれていることがわかりました。エントリポイントコマンドとイメージ内の埋め込まれたスクリプトに基づいて、攻撃時に使用されるのは一部のツールのみです。攻撃者は必要に応じて(リモートソースからダウンロードした)スクリプトを追加して、特定のターゲットを攻撃していると考えられます。これは、TeamTNT が攻撃を行う際に使用する手法です。

コンテナイメージ「bobedpei」の分析

まず、DTAで検出された内容に基づいて、このコンテナイメージをコンポーネントに分解してみましょう。

Kubernetesの脆弱性をスキャン

コンテナイメージにはバイナリファイルが含まれており、Kubernetes クラスタの脆弱性を検出するために設計された Python パッケージをダウンロードします。

• Kube-hunter：Python パッケージは Aqua のオープンソースのペンテストツールです。正当なセキュリティ担当者が Kubernetes クラスタのセキュリティ上の弱点を探すのに役立つように設計し我々により作成したツールが、サイバー攻撃者によって悪意ある目的のために再利用されているのです。
• Peirates：攻撃者が Kubernetes クラスタを介して権限昇格し、様々な操作を可能にするもう1つの Kubernetes 侵入ツールです。これは、ServiceAccount を盗んで収集し、さらなるコード実行を可能にし、クラスタの制御を得るための既知のテクニックを自動化します。このツールのバイナリは pei(MD5=018d88b8203bdea0fe4dc5b4baa930c4) です。

コンテナへの攻撃

コンテナイメージには、コンテナの脆弱性を検出して悪用するためのツールがいくつか含まれています。

• Bob(Break Out the Box)：コンテナの脆弱性の悪用、Kubernetesクラスタ内のServiceAccountの特定・試行、メタデータサービスのエンドポイントの特定、UNIX ドメインソケットの特定、HTTP をサポートしている UNIX ドメインソケットの特定を行います。
• DEEPCE(Docker Enumeration, Escalation of Privileges and Container Escapes)：コンテナ環境上からデータを列挙するツールです。例えば、コンテナ名と ID、IP アドレスと DNS サーバ、Docker のバージョン、マウント、パスワードと機密ファイル、環境変数、ネットワーク上の他のコンテナなどのデータを収集できます。また、このツールには権限昇格や Docker のエスケープを実行するように設定されています。イメージには deepce.sh を実行するように設計された2つのスクリプトも含まれています。 スクリプト docker.sh は、 Docker コンテナ上で deepce.sh を実行するように設計されており、lxc.sh は Linux コンテナ上で deepce.sh を実行するように設計されています。
• ed：アクセス可能な UNIX ドメインソケット、特に docker.sock を識別して悪用するために使用されます。ed は一度検出されると、コンテナを脱出するためにソケットを悪用しようとします。

ネットワーク操作ツール

コンテナイメージには、攻撃者が脆弱なネットワーク接続を悪用するための合法的なネットワーク操作ツールが含まれています。

• Scapy：コンピュータネットワーク用のパケット操作ツールであり、パケットの偽造やデコード、有線送信、キャプチャ、リクエストと返信の照合を行えます。また、スキャン、トレースアウト、プロービング、ユニットテスト、攻撃、ネットワーク発見などのタスクを処理できます。
• UTscapy：こちらもインポートされており、敵対者が scapy キャンペーンを開始できます。これらのツールは、攻撃者がコンテナの密集した環境(Kubernetes 等)内で、効率的な攻撃を行うために存在していると推測されます。

Kubernetesクラスタに対する攻撃の可能性

攻撃を実行する固有のスクリプトは特定できていませんが、このコンテナイメージに格納されているツールから、TeamTNT がリモートソースからスクリプトをダウンロードし、ターゲットに応じて攻撃を修正できると推測できます。イメージに格納されているツールに基づいて、下図のように Kubernetes クラスタ上で実行される可能性のあるいくつかの攻撃ベクトル(クラスタの内部および外部から)を示唆できます。

初期アクセス

コンテナイメージのツール「bobedpei」は、初期アクセスポイントの可能性を検出できます。

• ポートの設定ミスがある場合、誰でも API にコマンドを実行できるようになります。これらのツールはデフォルトのポートをスキャンして誤設定を特定します。例えば、ポート2375で動作している Docker API をパブリックに公開したり、ポート2379で設定ミスのある etcd API を公開したりします。
• 設定ミスがある場合、 Kubernetes ダッシュボードへ認証なしでログインを可能にします。
• 設定ミスがある場合、 Kubernetes API Server へ認証なしでログインを可能にします。
• etcd データベースに誤った設定がある場合、誰でもデータベース内でアクションを実行できるようになります。例えば、etcd DB への Read と Write を許可できます。
• v1.10.11、v1.11.5、v1.12.3以前のすべての Kubernetes のバージョンでは、CVE-2018-1002105に基づいて認証 API-Server が悪用される可能性があります。

ディスカバリ

初期アクセスを許可するだけでなく、コンテナイメージ「bobedpei」は、幅広いディスカバリを可能にします。

• Kubernetes Dashboard
• Kubernetes API Server
• Kubernetes etcd
• Kubernetes Pods
• docker.socket
• コンテナのファイル、ネットワーク、インタフェース情報など、機密情報を搾取するための予備情報収集
• ネットワークスキャン
• プロバイダのメタデータ(AWS、GCP等々)

権限昇格とコンテナ間移動

Kubernetes クラスタと初期アクセスが発見されると、いくつかのツールによって Kubernetes クラスタのさらなる活用が可能になります。

• Pod 上で ServiceAccount パーミッションが実行されている場合、攻撃者は Kubernetes API Server を悪用して
  • ServiceAccount トークンを取得してパーミッションを増やします。
  • Pod上でコードを実行します。
  • リバースシェルのため Kubectl exec を使用します。
• 攻撃者は DNS や ARP スプーフィングを実行して、他の Pod のネットワーク接続を乗っ取ることができます。
• 攻撃者は「/var/log」ホストマウントを悪用して、Pod がホストマシン上のファイルを読み取ることができます。
• 古いバージョンの Kubernetes では、オープンな Kubelet API を悪用して ServiceAccount トークンが盗まれることがありました。
• プロバイダメタデータ(AWS、GCP等々)をスクレイピングして IAM クレデンシャルを盗みます。
• GCS 環境では、攻撃者はバケットストレージから ServiceAccount トークンを引き出すことができます。
• RunCPawn の脆弱性(CVE-2019-5736)を利用して、攻撃者はコンテナのエスケープを試みることができます。
• 攻撃者は特権コンテナを悪用して、ホストOS上に新しいルートユーザを作成できます。
• 攻撃者はホスト上の docker グループのメンバーシップを経由して root に昇格し、カスタムペイロードを実行できます。

影響範囲

v1.11.8、v1.12.6、v1.13.4より古いすべての Kubernetes のバージョンでは、API パッチリクエストを許可されているユーザであれば、攻撃者は CVE-2019-1002100 を悪用して API-Service に対して DoS 攻撃を行うことができます。

Kubernetes環境を保護

---

TeamTNT がクラウドネイティブスタックに対する攻撃を、これまでにないアプローチで拡大していることが明らかになりました。Kubernetes クラスタの脆弱性を検出して悪用するツールを詰め込んだコンテナイメージと、イメージをホストする Docker Hub アカウントの使用で、正規の Kubernetes ソフトウェアになりすまし、無実のユーザを騙して悪意のあるコンテナイメージをダウンロードさせることができます。

また、これは理論的なデモではなく、取るに足らないハニーポットへの攻撃でもありません。この Docker Hub アカウントによる実際の攻撃の証拠があります。TeamTNT が誤って設定された docker daemon を悪用した後、実際に攻撃を実行することも確認しています。

利用している Kubernetes クラスタを保護するために、公開レジストリからダウンロードしたコンテナイメージには細心の注意を払い、実際に意図したコンテナイメージであることを確認することをお勧めします。

1. Kubernetes の脆弱性がないかコンテナイメージをスキャンし、公開されているソースから頻繁にイメージをダウンロードしている場合は、DTA のようなツールを使って隠れたマルウェアを見つけましょう。
2. 必ず Kubernetes のバージョンを更新してください。以前のバージョンには、より多くの既知の脆弱性が存在します。
3. kube-bench、kube-hunter、Aqua KSPM を使用してクラスタを強化しましょう。
4. 実行中のワークロードやリソースの使用状況を監視して、不審な挙動やパターンがないかを確認しましょう。(Aqua のランタイム保護は、Drift Prevention などの機能を使って自動的に保護します。

Kubernetes クラスタを守るためのセキュリティ手順をより知りたい場合は、Holistic Kubernetes Security を参照してください。