2023.04.27

KubernetesのRBACを悪用したクラスターへ史上初のバックドア攻撃 #aqua #コンテナ #セキュリティ #k8s #バックドア #RBACBuster

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは「Aqua Security」社の技術ブログで2023年4月21日に公開された「 First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters 」の日本語翻訳です。

KubernetesのRBACを悪用したクラスターへ史上初のバックドア攻撃

このたび、攻撃者が Kubernetes(K8s) の Role-Based Access Control (RBAC) を悪用してバックドアを作成している証拠を、史上初めて発見しました。また、攻撃者は DaemonSet リソースを作成し、攻撃する K8s クラスターのリソースを掌握して、ハイジャックしています。私たちの調査によると、このキャンペーンは、少なくとも 60 のクラスターを積極的に狙っていることが明らかになりました。

このブログは、誤設定された K8s クラスターについて Aqua が実施した包括的な研究の一部です。私たちの研究結果は、設定ミスのリスク、大企業でさえ見落としかねないクラスターのセキュリティ確保の重要性、たった1つのミスで潜在的な災害を発生させる脆弱性が残こることを明らかにする、非常に重要なものです。

攻撃内容

私たちは、ハニーポットの1つで、Kubernetes の RBAC システムを利用して永続性を獲得する攻撃を記録し、それを分析しました。攻撃者は、DaemonSet リソースを作成してコンテナを展開し、Monero cryptominers を実行しました。

最初のアクセスは、特権を持つ匿名ユーザからの認証されていないリクエストを許可してしまうという、誤った設定の API サーバを介して行われました。攻撃者は、シークレットをリストアップするためにいくつかの HTTP リクエストを送信します。そして、 kube-system ネームスペースのエンティティをリストアップしてクラスターに関する情報を得るために、2つの API リクエストを行いました。次に、攻撃者は kube-controller という名前のデプロイメントを探すことで、対象クラスターへの攻撃がすでにデプロイされているかを確認しました。

また、攻撃者は、kube-secure-fhgxtsjh、kube-secure-fhgxt、api-proxy、worker-deployment などのさまざまなネームスペースにおける、いくつかの既存のデプロイの削除も試みています。攻撃者は、レガシーキャンペーンや競合他社のキャンペーンを無効化して利用可能な CPU を増やすことで、サーバリソースが枯渇して発見されてしまう可能性を減らしていたと推測されます。

この攻撃で最も興味深かったのは、攻撃者が RBAC を使用して永続性を獲得したときです。攻撃者は、管理者レベルに近い特権を持つ新しい ClusterRole を作成しました。これは、特定のネームスペースに縛られることはありません。次に、攻撃者は、kube-system ネームスペースに ServiceAccount、kube-controller を作成しました。最後に、攻撃者はClusterRoleBindingを作成し、ClusterRole と ServiceAccount を紐づけ、強力で目立たない永続性を作成しました。

図1：攻撃者が作成した管理者レベルに近い権限の ClusterRoleこの時点で攻撃者は、匿名ユーザのアクセスが無効化されていたとしても、クラスターのさらなる悪用を可能にする永続性を作り出しました。さらに、cluster-admin ロールを新規ユーザや疑わしいユーザにバインドするとアラームを出力する可能性がありますが、攻撃者は API 監査ログにうまく紛れ込ませる巧妙な方法を編み出しました。最終的には、この正規の ClusterRoleBinding を system:controller:kube-controller に設定することで、攻撃者はアラームを出力することなくレーダーを潜り抜けることができました。

私たちは、ハニーポット環境のクラスターの様々な場所で AWS のアクセスキーを公開しました。するとその日のうちに、アクセスキーが攻撃者によって使用され、ターゲットのクラウドサービスプロバイダーアカウントへのさらなるアクセスを試み、より多くのリソースやデータを盗み、Kubernetes クラスターの特定の範囲から抜け出すために攻撃を活用することを示すビーコンを受け取りました。

その後、攻撃者は、1回の API リクエストですべてのノードにコンテナをデプロイするための DaemonSet リソースを作成しました。DaemonSet 作成リクエストオブジェクトには、パブリックレジストリ Docker Hub でホストされているコンテナイメージ kuberntesio/kube-controller:1.0.1 が含まれていました。クラスターへの影響は、リソースハイジャックでした。

図2：コンテナイメージkuberntesio/kube-controllerでDaemonSetをデプロイDocker Hub 上のコンテナイメージ kuberntesio/kube-controller:1.0.1 を調べたところ、このコンテナは5ヶ月前にアップロードされてから 14,399回プルされており、このキャンペーンが広く行われていることを示しています。また、この攻撃者によるアクティブな攻撃の痕跡がある、公開された 60個の Kubernetes クラスターが見つかりました。これは、このキャンペーンがいかに大規模なものであるかを証明しています。

コンテナ kuberntesio/kube-controller には3つのタグがあり、そのすべてを分析しました。各コンテナイメージの中に、VirusTotal でクリプトマイナーとして検出されたバイナリ kube-controller (MD5=2833c82055bf2d29c65cd9cf6684449a) が見つかりました。また、各コンテナイメージ上に設定ファイルを発見しました。ウォレットアドレスから、攻撃者はすでに5モネロ (XMR) をマイニングしており、このペースでいけば、1つのワーカーノードから年間で5モネロ (200米ドル) を獲得できることがわかりました。

kuberntesio/kube-controller という名前のコンテナイメージは、正規の kubernetes.io アカウントになりすましたタイポスクワッティングの事例です。数十個のコンテナイメージしか持っていないにもかかわらず、数百万ものプルを集めています。このイメージは、コントロールプレーンの重要なコンポーネントであり、すべてのマスターノード上の Pod 内で動作し、ノードの障害を検出して対応する役割を担う、人気の kube-controller-manager コンテナイメージを模倣しています。基本的には、クラスター上に存在するはずの広く使われている Kubernetes コンポーネントであり、クリプトマイナーではなく正規の導入であると運用者を欺くことができます。継続的に動作するよう設計されているため、その存在に疑問を持つ人はいないでしょう。

MicrosoftのKubernetes脅威マトリックスに攻撃をマッピング

ベストプラクティスとして、私たちのチームは通常、攻撃のコンポーネントを MITRE ATT&CK フレームワークの対応するテクニックにマッピングしています。しかし、今回のケースでは、MITRE は Kubernetes クラスターに対する攻撃のためのフレームワークをまだ公開していません。私たちは、Microsoft が作成した脅威マトリックスを利用し、いくつかの新しい提案を加えました。