Kubernetes Security for penetration testers

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

Transcript

1. Kubernetes Security for
   penetration testers
   攻撃者のための Kubernetes セキュリティ
   OWASP Fukuoka Meeting #1 / Kohei Morita @mrtc0 / blog.ssrf.in
   

   View Slide

2. Kohei Morita @mrtc0
   GMO Pepabo, inc. セキュリティ対策室
   OWASP Fukuoka Chapter Leader
   https://blog.ssrf.in/
   https://container-security.dev/ をちま
   ちま書いています。
   

   View Slide

3. Outline
   ・コンテナと Kubernetes の仕組み
   ・Kubernetes の Attack Surfaces
   ・Kubernetes クラスタの守り方
   コンテナや Kubernetes をプラットフォームとしたアプリケーションに対する攻
   撃の勘所を理解するのが目的
   

   View Slide

4. Docker を知っている🙋
   

   View Slide

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

   View Slide

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

   View Slide

7. Kubernetes を知っている🙋
   

   View Slide

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

   View Slide

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

   View Slide

10. Linux Container
    ● LXC や Docker などを筆頭にホストマシンから隔離した環境でプロセス
    を動かす仕組み
    ● 隔離 = chroot よりは強固だが VM よりは弱い
    ● Namespace や cgroup などリソースを分離する既存の技術を組み合
    わせることで実現している
    

    View Slide

11. Container Runtime Architecture
    

    View Slide

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

    View Slide

13. リソース分離のための主要素
    ● Namespace
    ● Capability
    ● seccomp
    ● cgroup
    ● LSM
    ● chroot / pivot_root
    

    View Slide

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]'
    

    View Slide

15. 主要な Namespace
    ● UTS Namespace
    ○ ホスト名の分離
    ● PID Namespace
    ○ プロセスの分離
    ● Network Namespace
    ○ ネットワークの分離
    ● IPC Namespace
    ○ IPC の分離
    ● Mount Namespace
    ○ マウントテーブルの分離
    

    View Slide

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
    

    View Slide

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
    

    View Slide

18. seccomp
    ● Firefox や Snap などを始め様々なアプリケーションで利用されている
    ● コンテナではホスト側に影響を与えかねないシステムコールを禁止してい
    る
    ○ kexec_file_load
    ○ mount
    ○ ptrace
    Docker のデフォルトのプロファイルについては
    https://docs.docker.com/engine/security/seccomp/#significant-syscalls-blocked-by-the-default-profile を参照
    

    View Slide

19. seccomp bypass
    https://asciinema.org/a/jTJmL1VVyCcFk387isJXPOENk
    

    View Slide

20. LSM
    ● SELinux / AppArmor などが利用されている
    ● seccomp や Capability などが破られた場合に最後の砦として機能す
    る
    ○ 具体的には procfs などへのアクセス制御をしている
    ● コンテナごとに適用するプロファイルを生成することで、より堅牢にするこ
    とができる
    

    View Slide

21. chroot と pivot_root
    ● コンテナのファイルシステムをホストと分離する
    ● chroot は条件によって脱獄可能なので、多くのコンテナランタイムでは
    pivot_root が使われている
    ○ Mount Namespace と組み合わせることで古い(ホストの) root
    ディレクトリにアクセスできなくなる
    

    View Slide

22. User Namespace / ID Mapping
    ● 非特権コンテナで利用される機能
    ● User Namespace を分離した際に、ホストとコンテナでのユーザーID /
    グループID の mapping を行う
    ● もし Break Out されても非特権ユーザーの権限となる
    

    View Slide

23. # コンテナのセキュリティ
    

    View Slide

24. Sensitive File Mount
    ● コンテナから読み書きできてはいけないファイルが多数ある
    ○ 主に /proc や /sys 配下
    ○ ReadOnly にする, bind-mount するなどの対応が必要
    ● /var/run/docker.sock などもマウントすると Docker API 経由でホスト
    側で任意のコマンドが実行できる
    

    View Slide

25. Privileged Container
    ● 特権(Privileged Container)は非常に強力な権限を持っている
    ○ CAP_SYS_ADMIN, CAP_SYS_PTRACE など
    ○ mount(2) の呼び出しによるファイルシステムマウント
    ● Privileged Container への侵入 = ホストへの侵入と同じ
    ● call_usermodehelper_exec() を利用したホスト側へのエスケープ
    

    View Slide

26. Breakout with uevent_helper
    https://asciinema.org/a/KbToy20RnDlycB0tkh4v8HGhP
    

    View Slide

27. # Kubernetes の仕組み
    

    View Slide

28. Kubernetes とは
    ● 複数のマシン(ノード)でクラスタを作り、その上でコンテナを管理するオー
    ケストレーションツール
    ● manifest と呼ばれる YAML や JSON 等でコンテナの状態を定義し、そ
    れを維持してくれる宣言的なアーキテクチャ
    ● 拡張性が高く様々なデプロイ方式をサポートしているのが特徴
    

    View Slide

29. クラスタの構成
    

    View Slide

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

    View Slide

31. クラスタの構成
    ● (構成に依存するが) 実際には他のアプリケーションも動作している
    ○ CoreDNS などの DNS Server
    ○ Prometheus や cAdvisor などのリソース監視ツール
    ○ ダッシュボード (kube-dashboard / Grafana)
    ○ td-agent などの Log Collector
    ● これらすべて Pod で動いていることが多い
    

    View Slide

32. # Kubernetes Attack Surfaces
    

    View Slide

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

    View Slide

34. ● コンテナから Node への Break out
    ○ コンテナの設定不備 (Privileged Container など)
    ○ カーネルの脆弱性 (Dirty CoW など)
    ○ ランタイムの脆弱性 (CVE-2019-5736 など)
    Runtime Security
    

    View Slide

35. Image Vulnerability
    ● イメージに含まれるパッケージの脆弱性
    ● クレデンシャルを誤ってイメージに含めてしまう
    ● レジストリの不正操作
    

    View Slide

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

    View Slide

37. API
    ● Kubernetes API と kubelet API の2つがある
    ● 認証不要な場合、クラスタの制御や Information
    Leak が可能
    ● パブリッククラウドだと Metadata API から
    Information Leak も可能
    

    View Slide

38. Secret
    ● Base64 でエンコードされた値となっている
    ○ うっかり git push しちゃった...... というケースも
    

    View Slide

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

    View Slide

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
    

    View Slide

41. etcd
    ● Secret やクラスタの情報を格納している KVS
    ● クライアント証明書を使って接続するのが普通だが...
    

    View Slide

42. Metadata API
    ● クラウドプロバイダーが提供しているエンドポイント 169.254.169.254
    ● IAM のクレデンシャルや Kubernetes クラスタに必要な環境変数などが
    格納されている
    ● アプリケーションレイヤからは SSRF などを利用して窃取されるケースも
    考えられる
    

    View Slide

43. EKS
    ● インスタンス情報の取得
    ● VPC, SecurityGroup 情報の取得
    ● ECR リポジトリからイメージの取得
    https://docs.aws.amazon.com/eks/latest/userguide/restrict-ec2-credential-access.html
    

    View Slide

44. GKE
    ● kube-env に bootstrap 処理で仕様される証明書等を保持
    ● そのクレデンシャルを使ってクラスタにノードとして Join できる
    ● これを利用して kubelet になりすますことが可能
    

    View Slide

45. # How to Kubernetes cluster
    

    View Slide

46. How to protect Kubernetes cluster
    ● Kubernetes はコンポーネントが多いので、守るところも多い
    ● Pod が一つ侵害されるとクラスタ全体が危険になることがある
    

    View Slide

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 など、より分離レベルの強いランタイムへの変更。
    

    View Slide

48. Service Mesh
    

    View Slide

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
    

    View Slide

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
    

    View Slide

51. Training
    ● 守るべきところが増えたので、トレーニングも重要
    ○ CKS (Certified Kubernetes Security Specialist) の取得
    ○ https://github.com/madhuakula/kubernetes-goat
    ○ https://github.com/kubernetes-simulator/simulator
    ○ https://github.com/mrtc0/kubectf
    

    View Slide

52. Sec ができることはガードレールを作ること
    ● 崖から落ちないような仕組みを用意する
    ○ Gatekeeper や Open Policy Agent による保護
    ○ Dev / Ops / Sec でポリシーを育てていく
    ○ CI での manifest のテスト
    ● CIS Benchmark や NIST SP 800-190 などへの準拠
    ○ 「そこまでするの...」という内容もあるので、脅威分析をした上で、妥
    協点を決めるのが良い
    

    View Slide

53. インシデントへの対応
    ● Kubernetes API の auditd ログを取得しておく
    ○ リソースの作成や削除などを追跡できるように
    ● falco などを用いたコンテナの監査
    ○ auditd では Pod / コンテナ名などを取得できない
    ○ セキュリティイベント発生時に自動でノードを切り離すなど
    ○ https://github.com/falcosecurity/kubernetes-response-en
    gine
    ● ノードのセキュリティモニタリングにも falco や Wazuh を利用
    

    View Slide

54. まとめ
    ● コンテナは多層防御の仕組みを取っている
    ● Kubernetes は複雑で守るところも多く、攻撃を受けた場合の影響が深
    刻になるケースがある
    ● しかし、これまでとは少し違うアプローチの対策も取れて、Security に加
    えて Observability の向上も期待できる
    ● OPA を始めとしたポリシー言語は波が来ている
    

    View Slide

55. 参考文献
    ● イラストでわかる Docker と Kubernetes / 技術評論社
    ● Docker / Kubernetes 開発・運用のためのセキュリティ実践ガイド / マ
    イナビ出版
    ● コンテナ型仮想化概論 / カットシステム
    

    View Slide