MITRE勉強会で使った資料その2です。 This document is what I used in the MITRE study group.

1. MITRE ATT&CK - T1611
Privilege Escalation
Escape to Host
May 24, 2021 kataokaw

2. T1611 - Escape to Hostの立ち位置
MITRE ATT&CKマトリックスでの立ち位置
a

3. TACTICS - Privilege Escalation (TA0004)
ATT&CKマトリックスの列名「Privilege Escalation」は、
攻撃者がシステムまたはネットワークにおいて、
より高いレベルのアクセス権を取得するために使用する手法で構成されている。
一般的なアプローチは、システムの弱点/構成の誤り/脆弱性の利用とされている。
権限昇格後に利用される権限の例
 SYSTAM/root
 local administrator
 管理者のようなアクセス権を持つユーザーアカウント
 特定システムへのアクセスや、特定機能を実行するユーザーアカウント
[MITER ATT&CK TACTICS (Enterprise) – Privilege Escalation] https://attack.mitre.org/tactics/TA0004/

4. TECHNIQUES - Escape to Host (T1611)
ID 名前
T1548 - 不正な昇格制御機構
.001 SetuidとSetgid
.002 ユーザーアカウント制御のバイパス
.003 SudoとSudoキャッシング
.004 プロンプトによる高度な実行
.010 ポートモニタ
.011 Plistの変更
.012 プリントプロセッサ
.013 XDG オートスタートの入力
.014 アクティブセットアップ
～省略～
T1611 ホストへのエスケープ
～省略～
「Privilege Escalation」には、
13のテクニックと82のサブテクニックがあるが、今回はT1611にフォーカスする。
[MITER ATT&CK TACTICS (Enterprise) – Privilege Escalation] https://attack.mitre.org/tactics/TA0004/

5. TECHNIQUES - Escape to Host (T1611)
T1611の詳細
攻撃者はコンテナを抜け出し、基盤となるホストにアクセスすることがあります。
これにより、攻撃者は、ホスト層から他のコンテナ化されたリソースへのアクセスや、ホスト自体へのアクセスが可能になります。
原則、コンテナ化されたリソースは、アプリの機能を明確に分離し、ホスト環境から隔離されている必要があります。
攻撃者が、ホスト環境へ抜け出す方法は複数あります。
bindパラメータを利用してホストのFSをマウントするよう構成したコンテナを作成し、
ホスト上で、ペイロードのダウンロードや、制御ユーティリティ(cron等)の実行などができます。
また、特権付きのコンテナを利用して、基盤となるホスト上でコマンドを実行することもできます。
ホストにアクセスできるようになると、
攻撃者は、永続性の確立、環境内での横移動、ホスト上でのC＆Cチャネルの設定など、
次の目的を達成する機会を得ることができます。
->コンテナに何かしらの権限を付与する機会は無いのか？
[MITER ATT&CK TECHNIQUES (Enterprise) –Escape to Host] https://attack.mitre.org/techniques/T1611/

6. Dockerコンテナの権限を変更する事例
 openvpnの利用
「ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)」
”Linux capabilities”の「CAP_NET_ADMIN」が必要なので、オプション「--cap-add NET_ADMIN」を使用する。
 mountの利用
「mount: permission denied」
”Linux capabilities”の「CAP_SYS_ADMIN」が必要なので、オプション「--cap-add SYS_ADMIN」を使用する。
tmpfsのマウント等では、下記エラーが出力されるが、
オプション「--security-opt apparmor:unconfined」か、AppArmorのカスタムプロファイルで回避可能とのこと。
「mount: tmpfs is write-protected, mounting read-only
mount: cannot mount tmpfs read-only」
コンテナ起動コマンドの例
docker run --cap-add NET_ADMIN --cap-add SYS_ADMIN --name <C-NAME> -itd -p <HOST-PORT>:<C-
PORT> <REPO-NAME>:<TAG-NAME>
[Linux capabilities] https://man7.org/linux/man-pages/man7/capabilities.7.html
[Google Cloud Platform - AppArmor によるコンテナの保護] https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor?hl=ja
権限付与の事例 コンテナの起動時のオプションで各種権限が
付与できるが、その分リスクも高まるので注意。

7. 特権でコンテナを
起動したらどうなるの？

8. Dockerコンテナを特権で実行
[情シスNavi. - セキュリティブログ：Dockerコンテナを特権モードで実行することが危険な理由]
https://josys-navi.hiblead.co.jp/tmsb_21jan20_docker-in-docker
[paloalto - コンテナでプログラムをrootとして実行することがなぜ問題なのか KubernetsのCVE-2019-11245を例に考える]
https://unit42.paloaltonetworks.jp/non-root-containers-kubernetes-cve-2019-11245-care/
特権コンテナを起動した際のリスク
特権コンテナは、ホストに対してルート権限を備えたコンテナのため、
コンテナ内のユーザは、ホストのリソースへの高度なアクセス権限を持つことになる。
よって、考えられるリスクは下記となる。
 AppArmor、 cgroups、SECcomp等のセキュリティ機構の無効化
 C＆Cサーバの設定
 コンテナブレイクアウト（ホスト上のコマンド実行/バイナリ変更）
 システムファイルの変更
 特権プロセスの停止・起動
etc.

9. コンテナを対象とした攻撃ツール
脅威グループ「TeamTNT」は、下記ツールを利用していた。
 BotB
->一般的なコンテナの脆弱性を悪用し、コンテナブレイクアウトを実行する。
その結果として、ホストでのコマンド実行やバイナリの変更などが可能となる。
CVE-2019-5736を利用している。
 Peirates
->Peiratesは複数のインフラストラクチャとクラウドの資格情報を収集できる。
Kubernetesクラスタからサービスアカウントトークンを検索する際に使えるらしい。
[paloalto - Hildegard: Kubernetesを標的とする新たなTeamTNTのクリプトジャックマルウェア] https://unit42.paloaltonetworks.jp/hildegard-malware-teamtnt/
[Github -brompwnie/botb] https://github.com/brompwnie/botb
[Github - inguardians/peirates] https://github.com/inguardians/peirates
攻撃ツールの事例

10. どうやって防ぐのか
対策方法
[Github - brompwnie/botb] https://github.com/brompwnie/botb
[Paloalto - runCによるDockerコンテナブレークアウト: CVE-2019-5736の解説]https://unit42.paloaltonetworks.jp/breaking-docker-via-runc-explaining-cve-2019-5736/
[Qiita - Dockerコンテナを本番環境で使うためのセキュリティ設定] https://qiita.com/muff1225/items/4edea7b039dd9f26098f#root%E6%A8%A9%E9%99%90%E3%82%92%E5%89%A5%E5%A5%AA%E3%81%99%E3%82%8B
[docker-docs-ja] https://docs.docker.jp/engine/security/rootless.html
 信頼できる公開元のイメージのみ利用する/content trust機能を利用する(バックドアやファイルレスマルウェアの回避)
 特権コンテナを外部公開しない
 外部公開するコンテナには、不要な権限を付与しない(CAP_SYS_ADMINなど)
 外部公開するコンテナ内サービスは、特権で実行しない
->コンテナ起動オプション「-u <uid>」でUIDを指定する方法や、DockerfileのUserディレクティブ、KubernetesのSecurityContextを利用する。
 不要なコンテナ間通信を閉じる
->Docker daemon起動時に--icc=falseオプションを利用する
 コンテナにファイルをマウントする場合はRead-onlyを指定する
docker run -v .:/src/app:ro <C-ID>
 Docker自体や外部公開するコンテナ内のOSSを常にアップデートしておく(特にrunCなど)
 Docker-in-Dockerしない
 (番外)kubletへのAnonymousアクセスを禁止する
実験的なものではあるが、将来的にはRootless Dockerの利用が推奨されるかもしれない(Docker 19.03以降)。
なお、現時点ではcgroupを利用できないなどの制約がある。

11. おわり