KubernetesのRBACを悪用したクラスターへ史上初のバックドア攻撃 #aqua #コンテナ #セキュリティ #k8s #バックドア #RBACBuster
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
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 を紐づけ、強力で目立たない永続性を作成しました。
.png?width=900&height=1408&name=carbon%20(13).png)
私たちは、ハニーポット環境のクラスターの様々な場所で AWS のアクセスキーを公開しました。するとその日のうちに、アクセスキーが攻撃者によって使用され、ターゲットのクラウドサービスプロバイダーアカウントへのさらなるアクセスを試み、より多くのリソースやデータを盗み、Kubernetes クラスターの特定の範囲から抜け出すために攻撃を活用することを示すビーコンを受け取りました。
その後、攻撃者は、1回の API リクエストですべてのノードにコンテナをデプロイするための DaemonSet リソースを作成しました。DaemonSet 作成リクエストオブジェクトには、パブリックレジストリ Docker Hub でホストされているコンテナイメージ kuberntesio/kube-controller:1.0.1 が含まれていました。クラスターへの影響は、リソースハイジャックでした。
.png?width=620&height=546&name=carbon%20(14).png)
コンテナ 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 が作成した脅威マトリックスを利用し、いくつかの新しい提案を加えました。
まとめと緩和策
この攻撃を RBAC Buster と名付けました。Kubernetes API サーバを悪用して ClusterRoleBinding を作成し、誤設定が修正された後も持続してクラスターへのフルアクセスを獲得することを目的とした、Kubernetes に対する新しい攻撃です。
このような攻撃を軽減するために、Aqua Trivy を使用して Kubernetes クラスターのセキュリティを確保できます。Trivy は、脆弱性、公開されたシークレット情報、および誤設定を見つけるのに役立ちます。
さらに、Aqua の CNAPP は、そのような誤設定を検出し、Kubernetes クラスターを保護するように設計されています。
