CNDT 2020シリーズ：Kubernetesを攻撃する側に立って考えてみる

攻撃しながら考えるKubernetesのセキュリティ

CloudNative Days Tokyo 2020のセッションからコンテナ、Kubernetesをセキュアに守るために何をすれば良いのか？を攻撃する側から考えてみたというNTTデータの藤井秀行氏のセッションを紹介する。

セッションを行うNTTデータの藤井氏

タイトルは「攻撃しながら考えるKubernetesのセキュリティ」というもので、守るためにはまずどうやって攻撃されるのかを理解した上で始めようというのが藤井氏の発想だ。

参考リンク：攻撃しながら考えるKubernetesのセキュリティ

ただこの発表の性格上、攻撃する側の「手口」が明らかになってしまうことを意識し、「このセッションでは違法なクラッキングを推進するものではない、悪用しないで欲しい」とセッションの冒頭と最後に重ねて念を押していた。そういう注意が必要なほど、ある意味衝撃的な内容であったと言える。

「悪用しないで欲しい」と何度も念を押した藤井氏

このセッションでは2つのシナリオを使って、具体的にどうやってハッカーはシステムに入り込むのか？　これを解説するというのが大きな流れだ。

2つのシナリオを使って攻撃の仕方を解説

シナリオ1では、内部の人間が不正アクセスを行って個人情報を抜き取るもの、そしてシナリオ2ではPodの設定の不備を突いてPodを生成する権限を獲得して外部からビットコインのクリプトマイニングを仕込み、同じNode上の情報を盗むというものだ。

内部の人間による不正アクセスを想定したシナリオ

セキュリティそのものを語る前に藤井氏からは「セキュリティを考慮せずにKubernetesを使っているのでは？」という問いかけがあった。デフォルトのままで導入されているKubernetesが意外と多いそうだ。

Kubernetesはセキュリティがちゃんと設定されていないのでは？ という問いかけ

その例として「コンテナにすべての特権を与えて実行したり、SELinuxの機能を利用不可にして実行したりしていないだろうか？」というコンテナの例と同じように、Kubernetesについても「オレたちは雰囲気で使っている」としてあまり耳慣れないService Accountやメタデータアクセスなどという新しい概念を深く理解せずに、デフォルトの設定のまま利用していないだろうか？と問いかけた。

Kubernetesの新しい概念を理解せずにデフォルトのまま利用していないか？

そしてこのセッションの中では、NISTで定義されたコンテナにおけるセキュリティの対策のうち、オーケストレーター、コンテナ、最後にホストOSに関するリスクについて解説すると紹介した。

NISTの定義の内、どこにフォーカスして解説するのか？を説明

ここから始まるシナリオについては、攻撃されるシステムの概要、使われているコンポーネントの状況、攻撃する側の種別、対象、手段、目的などを解説した。通常のセキュリティに関するテクニカルな解説では守るための機能を解説することが多いが、ここでは敢えて「古いOSを使っている、脆弱性があるWebアプリを動かしている」といういかにもありそうな状況を想定して解説しているところが新鮮と言える。

攻撃されるシステムの概要を解説

また攻撃目的という部分では「以前、同じ組織に所属していて恨みを持っているから」というこれもいかにもありそうな状況を想定しているのがユニークだ。

攻撃側のシナリオが現実的すぎる

また攻撃するために利用する脆弱性にDirtyCow（CVE-2016-5195）を使っているが、これは既知の脆弱性であり、これを基に実際に攻撃を行わせないようにするための配慮が透けて見えてくる。

DirtyCowを使って攻撃を行う

実際にmakeして実行形式ファイルを生成し、対象となるIPに向けて実行し、root権限が手に入ったことをスクリーンショットで見せることで、ハッカーが行っている手順がいかに簡単に実行できるのかを解説した。

DirtyCowでroot権限が手に入った

このシナリオでは、コンテナ内のユーザーがホストの特権を手に入れたというのがポイントだが、そもそもseccompとケーパビリティはデフォルトのまま有効になっているのに、どうして権限が奪われたのか？ についても解説を行った。

このシナリオの解説

より詳細に言えば、OSとコンテナランタイムに深刻な脆弱性があり、そこを突いて特権を確保したこと、またマルチテナントとして別のコンテナにアクセスできる状態にあったことを解説した。

このシナリオのポイントは2点

またどうしてseccompとケーパビリティがオンになっていたのに脆弱性を突かれたのか？ に関しては、より低レベルの脆弱性は設定だけでは防げず、コンポーネントのバージョンアップを行うしか対処方法がないことを紹介した。

バージョンアップが最適な脆弱性対処方法

そして対策としてはOSやランタイムを最新版にアップデートすることを強調した。マルチテナントについては仮想マシンよりも影響を受けやすく脆弱であるとしたものの、すでにある程度改善されつつあることを紹介した。

シナリオ1の対策

またseccompとケーパビリティについても簡単に解説し、細かな設定ができるものの万能ではないと語った。

seccompとケーパビリティの解説

また参考情報として、Kubernetesの1.19からseccompとケーパビリティの設定が可能になっていることを紹介した。

Kubernetesの1.19のseccompとケーパビリティ設定例を紹介

外部からの攻撃を想定したシナリオ

次に挙げたシナリオは、オンプレミスではなくパブリッククラウドのサービスとして提供されるマネージドのKubernetes環境における事例だ。ここではWebサイト構築のためのCMS（名前は伏せられているが、WordPressと思われる）に脆弱性があるという前提である。

シナリオ2の攻撃される側の状況

このシナリオでは、攻撃側はスクリプトキディとしてあまり深い知識がないエンジニアという設定だ。CMSの脆弱性を突いてシェルスクリプトへのアクセスを入手した後に、ビットコインのマイニングのためのPodを実行し、バックドアを仕込んだPodを実行するというシナリオだ。

攻撃側の設定

CMSの脆弱性を突いてシェルへのアクセスを行った後に、Kubernetesの中身を恐る恐る探し当てていくようすを例として挙げている。

シェルからkubectlを利用

そしてNodeの特権を取り、バックドアを作成するという辺りまでを簡単に紹介した。

攻撃のためのスクリプトを利用してバックドアを作成

シナリオ2ではService Accountを悪用し、マイニング用のPodを実行、さらにバックドアのためのPodを実行するなど、クリプトマイニング以外の再攻撃の下準備をしているという辺りが、現代的な攻撃と言えるだろう。

シナリオ2の攻撃の概要

ここでは、CMSの脆弱性以外はKubernetesの設定に問題があるケースであることが紹介された。ここでの藤井氏が主張するポイントは、攻撃が成功する要因は必ずしも脆弱性だけではなく、特に意識せずにデフォルトのまま放置されている設定情報の場合もあるという部分だろう。

Kubernetesの設定に問題があった

脆弱性ではなくユーザーの設定が問題の根本

最後にまとめとして以下のような対処策を紹介してセッションを終えた。

• Service Accountの権限を最小にする
• コンテナ内で実行できることを必要最小限にする
• 特権コンテナを禁止する」

防御を行う際に敵を知ることは重要だ。今回は守るためのツールの解説ではなく、攻撃する側が使う具体的なコマンドやツール、処理の流れなど、攻撃側の目線で解説を行うという興味深いセッションとなった。そして藤井氏は最後にもう一度、攻撃側を理解することは必要だが、興味本位で試したりすることがないようにと念を押してセッションを終えた。