Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetes Security for penetration testers

B49933741d74e122bc1314b2975e9fc9?s=47 mrtc0
February 17, 2021

Kubernetes Security for penetration testers

OWASP Fukuoka Meeting #1 の発表資料 https://owasp-kyushu.connpass.com/event/200714/

B49933741d74e122bc1314b2975e9fc9?s=128

mrtc0

February 17, 2021
Tweet

Transcript

  1. Kubernetes Security for penetration testers 攻撃者のための Kubernetes セキュリティ OWASP Fukuoka

    Meeting #1 / Kohei Morita @mrtc0 / blog.ssrf.in
  2. Kohei Morita @mrtc0 GMO Pepabo, inc. セキュリティ対策室 OWASP Fukuoka Chapter

    Leader https://blog.ssrf.in/ https://container-security.dev/ をちま ちま書いています。
  3. Outline ・コンテナと Kubernetes の仕組み ・Kubernetes の Attack Surfaces ・Kubernetes クラスタの守り方

    コンテナや Kubernetes をプラットフォームとしたアプリケーションに対する攻 撃の勘所を理解するのが目的
  4. Docker を知っている🙋

  5. Linux コンテナの仕組みを知っている🙋 コンテナとホストのリソース分離技術について知っている

  6. Linux コンテナのセキュリティを知っている 🙋

  7. Kubernetes を知っている🙋

  8. Kubernetes セキュリティを知っている🙋

  9. # コンテナと Kubernetes の仕組み

  10. Linux Container • LXC や Docker などを筆頭にホストマシンから隔離した環境でプロセス を動かす仕組み • 隔離

    = chroot よりは強固だが VM よりは弱い • Namespace や cgroup などリソースを分離する既存の技術を組み合 わせることで実現している
  11. Container Runtime Architecture

  12. CRI / OCI • CRI (Container Runtime Interface) … OCI

    を制御するための規格化 されたインターフェイスを持つ • OCI (Open Container Initiative) … CRI から受け取った命令を元にコ ンテナを実行する主体 • それぞれの実装を切り替えることを可能とした高い拡張性が特徴
  13. リソース分離のための主要素 • Namespace • Capability • seccomp • cgroup •

    LSM • chroot / pivot_root
  14. Namespace ・名前空間内のプロセスに対して、そのプロセスがあたかも専用のグローバル リソースを持っているかのように見せる仕組み ・PID, Network, Mount, IPC, User, UTS などが提供されている

    ubuntu@sandbox ~> docker run --rm -it ubuntu:20.10 sleep 100 ubuntu@sandbox ~> sudo ls -l /proc/(pidof sleep)/ns/pid lrwxrwxrwx 1 root root 0 Feb 14 19:45 /proc/15112/ns/pid -> 'pid:[4026532224]' ubuntu@sandbox ~> ls -l /proc/self/ns/pid lrwxrwxrwx 1 ubuntu ubuntu 0 Feb 14 19:43 /proc/self/ns/pid -> 'pid:[4026531836]'
  15. 主要な Namespace • UTS Namespace ◦ ホスト名の分離 • PID Namespace

    ◦ プロセスの分離 • Network Namespace ◦ ネットワークの分離 • IPC Namespace ◦ IPC の分離 • Mount Namespace ◦ マウントテーブルの分離
  16. Capability • setuid で root を与えるのではなく、最小権限のみを与える ◦ 1024 以下のポートで Listen

    するには CAP_NET_BIND_SERVICE が必要 ◦ chroot(2) を呼び出すには CAP_SYS_CHROOT が必要 root@sandbox /h/ubuntu# nc -lp 80 -v Listening on [0.0.0.0] (family 0, port 80) ^C⏎ root@sandbox /h/ubuntu# capsh --drop="cap_net_bind_service" -- -c 'nc -lp 80 -v' nc: Permission denied
  17. cgroup • メモリの使用量やプロセス数などを制限する目的で利用される ubuntu@sandbox ~> docker run --rm -it ubuntu:20.10

    bash root@sandbox /h/ubuntu# CID=6b2304c98dcdd530fd8dca2b936097c849126eee05f500b3e3d57ac5218b75cb root@sandbox /h/ubuntu# cat /sys/fs/cgroup/pids/docker/$CID/pids.max max root@sandbox /h/ubuntu# echo 10 > /sys/fs/cgroup/pids/docker/$CID/pids.max root@sandbox /h/ubuntu# cat /sys/fs/cgroup/pids/docker/$CID/pids.max 10 root@6b2304c98dcd:/# :(){ :|: & };: bash: fork: retry: Resource temporarily unavailable bash: fork: retry: Resource temporarily unavailable
  18. seccomp • Firefox や Snap などを始め様々なアプリケーションで利用されている • コンテナではホスト側に影響を与えかねないシステムコールを禁止してい る ◦

    kexec_file_load ◦ mount ◦ ptrace Docker のデフォルトのプロファイルについては https://docs.docker.com/engine/security/seccomp/#significant-syscalls-blocked-by-the-default-profile を参照
  19. seccomp bypass https://asciinema.org/a/jTJmL1VVyCcFk387isJXPOENk

  20. LSM • SELinux / AppArmor などが利用されている • seccomp や Capability

    などが破られた場合に最後の砦として機能す る ◦ 具体的には procfs などへのアクセス制御をしている • コンテナごとに適用するプロファイルを生成することで、より堅牢にするこ とができる
  21. chroot と pivot_root • コンテナのファイルシステムをホストと分離する • chroot は条件によって脱獄可能なので、多くのコンテナランタイムでは pivot_root が使われている

    ◦ Mount Namespace と組み合わせることで古い(ホストの) root ディレクトリにアクセスできなくなる
  22. User Namespace / ID Mapping • 非特権コンテナで利用される機能 • User Namespace

    を分離した際に、ホストとコンテナでのユーザーID / グループID の mapping を行う • もし Break Out されても非特権ユーザーの権限となる
  23. # コンテナのセキュリティ

  24. Sensitive File Mount • コンテナから読み書きできてはいけないファイルが多数ある ◦ 主に /proc や /sys

    配下 ◦ ReadOnly にする, bind-mount するなどの対応が必要 • /var/run/docker.sock などもマウントすると Docker API 経由でホスト 側で任意のコマンドが実行できる
  25. Privileged Container • 特権(Privileged Container)は非常に強力な権限を持っている ◦ CAP_SYS_ADMIN, CAP_SYS_PTRACE など ◦

    mount(2) の呼び出しによるファイルシステムマウント • Privileged Container への侵入 = ホストへの侵入と同じ • call_usermodehelper_exec() を利用したホスト側へのエスケープ
  26. Breakout with uevent_helper https://asciinema.org/a/KbToy20RnDlycB0tkh4v8HGhP

  27. # Kubernetes の仕組み

  28. Kubernetes とは • 複数のマシン(ノード)でクラスタを作り、その上でコンテナを管理するオー ケストレーションツール • manifest と呼ばれる YAML や

    JSON 等でコンテナの状態を定義し、そ れを維持してくれる宣言的なアーキテクチャ • 拡張性が高く様々なデプロイ方式をサポートしているのが特徴
  29. クラスタの構成

  30. クラスタの構成 https://kubernetes.io/ja/docs/concepts/overview/components/

  31. クラスタの構成 • (構成に依存するが) 実際には他のアプリケーションも動作している ◦ CoreDNS などの DNS Server ◦

    Prometheus や cAdvisor などのリソース監視ツール ◦ ダッシュボード (kube-dashboard / Grafana) ◦ td-agent などの Log Collector • これらすべて Pod で動いていることが多い
  32. # Kubernetes Attack Surfaces

  33. Kubernetes Attack Matrix https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

  34. • コンテナから Node への Break out ◦ コンテナの設定不備 (Privileged Container

    など) ◦ カーネルの脆弱性 (Dirty CoW など) ◦ ランタイムの脆弱性 (CVE-2019-5736 など) Runtime Security
  35. Image Vulnerability • イメージに含まれるパッケージの脆弱性 • クレデンシャルを誤ってイメージに含めてしまう • レジストリの不正操作

  36. ServiceAccount • Mount している ServiceAccount Token を利用して、その権限でクラスタを 操作する

  37. API • Kubernetes API と kubelet API の2つがある • 認証不要な場合、クラスタの制御や

    Information Leak が可能 • パブリッククラウドだと Metadata API から Information Leak も可能
  38. Secret • Base64 でエンコードされた値となっている ◦ うっかり git push しちゃった...... というケースも

  39. Networking • デフォルトでは Pod 間同士で通信し放題 • そのため、Pod への侵入等からさらなる権限昇格につながる

  40. Tiller Pod • Helm v2 では Helm Server (Tiller) を通して機能する

    • Tiller はデフォルトで認証設定がされていないため、Pod から接続できた 場合、任意のリソースをクラスタに作成できる ◦ ServiceAccount に権限がなくても、これを利用して RBAC を新規 に作成し、cluster-admin に権限昇格できる in-pod:/# helm --host tiller-deploy.kube-system.svc.cluster.local:44134 install /pwnchart
  41. etcd • Secret やクラスタの情報を格納している KVS • クライアント証明書を使って接続するのが普通だが...

  42. Metadata API • クラウドプロバイダーが提供しているエンドポイント 169.254.169.254 • IAM のクレデンシャルや Kubernetes クラスタに必要な環境変数などが

    格納されている • アプリケーションレイヤからは SSRF などを利用して窃取されるケースも 考えられる
  43. EKS • インスタンス情報の取得 • VPC, SecurityGroup 情報の取得 • ECR リポジトリからイメージの取得

    https://docs.aws.amazon.com/eks/latest/userguide/restrict-ec2-credential-access.html
  44. GKE • kube-env に bootstrap 処理で仕様される証明書等を保持 • そのクレデンシャルを使ってクラスタにノードとして Join できる

    • これを利用して kubelet になりすますことが可能
  45. # How to Kubernetes cluster

  46. How to protect Kubernetes cluster • Kubernetes はコンポーネントが多いので、守るところも多い • Pod

    が一つ侵害されるとクラスタ全体が危険になることがある
  47. 基本の対策まとめ ServiceAccount Token … 自動でマウントしない。RBAC を適切に設定する。 Unauthorized API … API

    に認証を設定する。 etcd … 認証を設定する。暗号化を施す。 Secret の管理 … 暗号化を施したり Hashicorp Vault や KMS などの利用。 Network … Network Policy や Service Mesh を利用した mTLS などの利用。 Metadata API … クラウドプロバイダに保護策が提示されているのでそれに従う。 Runtime … Gatekeeper でポリシーに従わない Pod を作成させない。 ※ gVisor や Kata Container など、より分離レベルの強いランタイムへの変更。
  48. Service Mesh

  49. Envoy CSRF Filter • Envoy Sidecar で CSRF 対策ができる ◦

    Origin ヘッダと Referrer ヘッダを見る実装 ◦ https://www.envoyproxy.io/docs/envoy/latest/start/sandb oxes/csrf ◦ https://www.envoyproxy.io/docs/envoy/latest/configuratio n/http/http_filters/csrf_filter.html
  50. Authorization with Open Policy Agent // authz.rego package httpapi.authz import

    input default allow = false allow { some username input.method == "GET" input.path = ["user", username] input.user == username } ❯ curl --user alice:password localhost:5000/user/alice Success: user alice is authorized ❯ curl --user alice:password localhost:5000/user/bob Error: user alice is not authorized to GET url /user/bob
  51. Training • 守るべきところが増えたので、トレーニングも重要 ◦ CKS (Certified Kubernetes Security Specialist) の取得

    ◦ https://github.com/madhuakula/kubernetes-goat ◦ https://github.com/kubernetes-simulator/simulator ◦ https://github.com/mrtc0/kubectf
  52. Sec ができることはガードレールを作ること • 崖から落ちないような仕組みを用意する ◦ Gatekeeper や Open Policy Agent

    による保護 ◦ Dev / Ops / Sec でポリシーを育てていく ◦ CI での manifest のテスト • CIS Benchmark や NIST SP 800-190 などへの準拠 ◦ 「そこまでするの...」という内容もあるので、脅威分析をした上で、妥 協点を決めるのが良い
  53. インシデントへの対応 • Kubernetes API の auditd ログを取得しておく ◦ リソースの作成や削除などを追跡できるように •

    falco などを用いたコンテナの監査 ◦ auditd では Pod / コンテナ名などを取得できない ◦ セキュリティイベント発生時に自動でノードを切り離すなど ◦ https://github.com/falcosecurity/kubernetes-response-en gine • ノードのセキュリティモニタリングにも falco や Wazuh を利用
  54. まとめ • コンテナは多層防御の仕組みを取っている • Kubernetes は複雑で守るところも多く、攻撃を受けた場合の影響が深 刻になるケースがある • しかし、これまでとは少し違うアプローチの対策も取れて、Security に加

    えて Observability の向上も期待できる • OPA を始めとしたポリシー言語は波が来ている
  55. 参考文献 • イラストでわかる Docker と Kubernetes / 技術評論社 • Docker

    / Kubernetes 開発・運用のためのセキュリティ実践ガイド / マ イナビ出版 • コンテナ型仮想化概論 / カットシステム