Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Kubernetes Security for penetration testers

mrtc0
February 17, 2021

Kubernetes Security for penetration testers

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

mrtc0

February 17, 2021
Tweet

More Decks by mrtc0

Other Decks in Programming

Transcript

  1. Kohei Morita @mrtc0 GMO Pepabo, inc. セキュリティ対策室 OWASP Fukuoka Chapter

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

    コンテナや Kubernetes をプラットフォームとしたアプリケーションに対する攻 撃の勘所を理解するのが目的
  3. Linux Container • LXC や Docker などを筆頭にホストマシンから隔離した環境でプロセス を動かす仕組み • 隔離

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

    を制御するための規格化 されたインターフェイスを持つ • OCI (Open Container Initiative) … CRI から受け取った命令を元にコ ンテナを実行する主体 • それぞれの実装を切り替えることを可能とした高い拡張性が特徴
  5. 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]'
  6. 主要な Namespace • UTS Namespace ◦ ホスト名の分離 • PID Namespace

    ◦ プロセスの分離 • Network Namespace ◦ ネットワークの分離 • IPC Namespace ◦ IPC の分離 • Mount Namespace ◦ マウントテーブルの分離
  7. 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
  8. 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
  9. seccomp • Firefox や Snap などを始め様々なアプリケーションで利用されている • コンテナではホスト側に影響を与えかねないシステムコールを禁止してい る ◦

    kexec_file_load ◦ mount ◦ ptrace Docker のデフォルトのプロファイルについては https://docs.docker.com/engine/security/seccomp/#significant-syscalls-blocked-by-the-default-profile を参照
  10. LSM • SELinux / AppArmor などが利用されている • seccomp や Capability

    などが破られた場合に最後の砦として機能す る ◦ 具体的には procfs などへのアクセス制御をしている • コンテナごとに適用するプロファイルを生成することで、より堅牢にするこ とができる
  11. User Namespace / ID Mapping • 非特権コンテナで利用される機能 • User Namespace

    を分離した際に、ホストとコンテナでのユーザーID / グループID の mapping を行う • もし Break Out されても非特権ユーザーの権限となる
  12. Sensitive File Mount • コンテナから読み書きできてはいけないファイルが多数ある ◦ 主に /proc や /sys

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

    mount(2) の呼び出しによるファイルシステムマウント • Privileged Container への侵入 = ホストへの侵入と同じ • call_usermodehelper_exec() を利用したホスト側へのエスケープ
  14. Kubernetes とは • 複数のマシン(ノード)でクラスタを作り、その上でコンテナを管理するオー ケストレーションツール • manifest と呼ばれる YAML や

    JSON 等でコンテナの状態を定義し、そ れを維持してくれる宣言的なアーキテクチャ • 拡張性が高く様々なデプロイ方式をサポートしているのが特徴
  15. クラスタの構成 • (構成に依存するが) 実際には他のアプリケーションも動作している ◦ CoreDNS などの DNS Server ◦

    Prometheus や cAdvisor などのリソース監視ツール ◦ ダッシュボード (kube-dashboard / Grafana) ◦ td-agent などの Log Collector • これらすべて Pod で動いていることが多い
  16. • コンテナから Node への Break out ◦ コンテナの設定不備 (Privileged Container

    など) ◦ カーネルの脆弱性 (Dirty CoW など) ◦ ランタイムの脆弱性 (CVE-2019-5736 など) Runtime Security
  17. API • Kubernetes API と kubelet API の2つがある • 認証不要な場合、クラスタの制御や

    Information Leak が可能 • パブリッククラウドだと Metadata API から Information Leak も可能
  18. 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
  19. Metadata API • クラウドプロバイダーが提供しているエンドポイント 169.254.169.254 • IAM のクレデンシャルや Kubernetes クラスタに必要な環境変数などが

    格納されている • アプリケーションレイヤからは SSRF などを利用して窃取されるケースも 考えられる
  20. 基本の対策まとめ 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 など、より分離レベルの強いランタイムへの変更。
  21. 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
  22. 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
  23. Training • 守るべきところが増えたので、トレーニングも重要 ◦ CKS (Certified Kubernetes Security Specialist) の取得

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

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

    falco などを用いたコンテナの監査 ◦ auditd では Pod / コンテナ名などを取得できない ◦ セキュリティイベント発生時に自動でノードを切り離すなど ◦ https://github.com/falcosecurity/kubernetes-response-en gine • ノードのセキュリティモニタリングにも falco や Wazuh を利用
  26. 参考文献 • イラストでわかる Docker と Kubernetes / 技術評論社 • Docker

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