Docker Breakout / Privilege Escalation
AWSハッキングを学び、実践:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F4226785378-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FpWAf1y9UWEMh8PEO1vPV%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=44418454&sv=1)
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。 今すぐアクセスしてください:
自動列挙と脱出
linpeas: コンテナを列挙することもできます
CDK: このツールは、現在のコンテナを列挙し、自動的に脱出を試みるのに非常に便利です
amicontained: コンテナが持つ権限を取得し、それから脱出する方法を見つけるための便利なツール
deepce: コンテナからの列挙と脱出のためのツール
grype: イメージにインストールされているソフトウェアに含まれるCVEを取得する
マウントされたDockerソケットの脱出
もし何らかの理由で、dockerソケットがDockerコンテナ内にマウントされていることがわかった場合、それから脱出することができます。 これは通常、何らかの理由でdockerコンテナがdockerデーモンに接続してアクションを実行する必要がある場合に発生します。
この場合、通常のdockerコマンドを使用してdockerデーモンと通信できます:
docker ソケットが予期しない場所にある場合は、docker
コマンドを使用してそれと通信することができます。パラメータは -H unix:///path/to/docker.sock
です。
Docker デーモンはデフォルトでポート(2375、2376)でリスニングされている可能性があり、Systemd ベースのシステムでは Docker デーモンとの通信が Systemd ソケット fd://
を介して行われることがあります。
さらに、他のハイレベルランタイムのランタイムソケットにも注意してください:
dockershim:
unix:///var/run/dockershim.sock
containerd:
unix:///run/containerd/containerd.sock
cri-o:
unix:///var/run/crio/crio.sock
frakti:
unix:///var/run/frakti.sock
rktlet:
unix:///var/run/rktlet.sock
...
Capabilities Abuse Escape
コンテナの権限をチェックする必要があります。以下の権限のいずれかがある場合、それから脱出することができるかもしれません: CAP_SYS_ADMIN
, CAP_SYS_PTRACE
, CAP_SYS_MODULE
, DAC_READ_SEARCH
, DAC_OVERRIDE, CAP_SYS_RAWIO
, CAP_SYSLOG
, CAP_NET_RAW
, CAP_NET_ADMIN
以前に言及した自動ツールまたは次の方法で現在のコンテナの権限を確認できます:
特権付きコンテナからの脱出
特権付きコンテナは、次のようなフラグを使用して作成できます: --privileged
または特定の防御を無効にすることによって:
--cap-add=ALL
--security-opt apparmor=unconfined
--security-opt seccomp=unconfined
--security-opt label:disable
--pid=host
--userns=host
--uts=host
--cgroupns=host
/dev
をマウント
--privileged
フラグは、コンテナのセキュリティを著しく低下させ、制限のないデバイスアクセスを提供し、いくつかの保護をバイパスします。詳細な説明については、--privileged
の完全な影響に関するドキュメントを参照してください。
特権 + hostPID
これらの権限を持っていると、単に次のように実行するだけで、ホストで root として実行されているプロセス(init (pid:1) のような)の名前空間に移動できます: nsenter --target 1 --mount --uts --ipc --net --pid -- bash
コンテナでテストを実行します:
特権
特権フラグだけで、ホストのディスクにアクセスを試みたり、release_agentを悪用したりして脱出を試みることができます。
コンテナで以下のバイパスをテストしてください:
ディスクのマウント - Poc1
適切に構成されたDockerコンテナは、fdisk -lのようなコマンドを許可しません。ただし、--privileged
フラグや--device=/dev/sda1
というキャップが指定されたミス構成のDockerコマンドでは、特権を取得してホストドライブを表示することが可能です。
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fbestestredteam.com%2Fcontent%2Fimages%2F2019%2F08%2Fimage-16.png&width=768&dpr=4&quality=100&sign=45b35987&sv=1)
したがって、ホストマシンを乗っ取ることは簡単です:
そして、ホストのファイルシステムにアクセスできるようになりました。なぜなら、それが /mnt/hola
フォルダにマウントされているからです。
ディスクのマウント - Poc2
コンテナ内では、攻撃者はクラスターによって作成された書き込み可能な hostPath ボリュームを介して、基礎となるホスト OS へのさらなるアクセスを試みるかもしれません。以下は、この攻撃ベクトルを利用できるかどうかを確認するためにコンテナ内でチェックできる一般的な項目です:
特権エスケープ 既存の release_agent を悪用 (cve-2022-0492) - PoC1
技術の説明は以下で見つけることができます:
Docker release_agent cgroups escaperelease_agentを悪用した特権エスケープ - 相対パスが不明な場合の PoC3
以前の攻撃では、ホストのファイルシステム内のコンテナの絶対パスが公開されていました。ただし、常にそうとは限りません。ホスト内のコンテナの絶対パスがわからない場合には、この技術を使用できます:
release_agent exploit - Relative Paths to PIDs特権付きコンテナ内でPoCを実行すると、次のような出力が得られるはずです:
特権エスケープ:機密マウントの悪用
いくつかのファイルがマウントされる可能性があり、基礎となるホストに関する情報を提供することがあります。それらの中には、ホストが何かが起こったときに実行されるべきものを示すことさえあるかもしれません(これにより攻撃者がコンテナから脱出することが可能になります)。 これらのファイルの悪用により、次のことが可能になるかもしれません:
release_agent(以前にカバー済み)
ただし、このページでチェックすべき他の機密ファイルを見つけることができます:
Sensitive Mounts任意のマウント
何度かの機会に、コンテナがホストからのボリュームをマウントしていることがあります。このボリュームが正しく構成されていない場合、アクセス/変更が可能になる機密データがあるかもしれません:シークレットの読み取り、sshのauthorized_keysの変更...
2つのシェルとホストマウントを使用した特権昇格
もし、ホストからマウントされたフォルダを持つコンテナ内のrootとしてのアクセス権を持っており、非特権ユーザーとしてホストに脱出し、マウントされたフォルダに読み取りアクセス権がある場合、 コンテナ内のマウントされたフォルダにbash suidファイルを作成し、それをホストから実行することで特権昇格が可能です。
2つのシェルを使用した特権昇格
もし、コンテナ内でrootアクセスを持ち、かつ特権のないユーザーとしてホストに脱出できた場合、コンテナ内でMKNODの権限(デフォルトで使用可能)があれば、この投稿で説明されているように、ホスト内で特権昇格を悪用することができます。 この権限を持つと、コンテナ内のrootユーザーはブロックデバイスファイルを作成することが許可されます。デバイスファイルは、基礎となるハードウェアやカーネルモジュールにアクセスするために使用される特別なファイルです。例えば、/dev/sdaのブロックデバイスファイルは、システムディスク上の生データを読むためのアクセスを提供します。
Dockerは、コンテナ内でのブロックデバイスの誤用を防ぐために、ブロックデバイスの読み書き操作をブロックするcgroupポリシーを強制しています。しかし、もしコンテナ内でブロックデバイスが作成された場合、それは**/proc/PID/root/ディレクトリを介してコンテナ外からアクセス可能になります。このアクセスには、コンテナ内外のプロセス所有者が同じ**である必要があります。
この解説からの悪用の例:
hostPID
ホストのプロセスにアクセスできる場合、それらのプロセスに格納されている多くの機密情報にアクセスできるようになります。テストラボを実行します:
For example, you will be able to list the processes using something like ps auxn
and search for sensitive details in the commands.
Then, as you can access each process of the host in /proc/ you can just steal their env secrets running:
あなたは他のプロセスのファイルディスクリプタにアクセスし、それらのオープンされたファイルを読むこともできます。
あなたはまたプロセスを終了させ、DoSを引き起こすことができます。
もしコンテナの外部のプロセスに特権アクセスを持っている場合は、nsenter --target <pid> --all
やnsenter --target <pid> --mount --net --pid --cgroup
のようなコマンドを実行して、そのプロセスと同じns制限(たぶんなし)を持つシェルを実行できます。
hostNetwork
もしコンテナがDockerのホストネットワーキングドライバ(--network=host
)で構成されている場合、そのコンテナのネットワークスタックはDockerホストから分離されていません(コンテナはホストのネットワーキング名前空間を共有しており、コンテナには独自のIPアドレスが割り当てられません)。言い換えると、コンテナはすべてのサービスを直接ホストのIPにバインドします。さらに、コンテナは共有インターフェース上でホストが送受信しているすべてのネットワークトラフィックを傍受できます tcpdump -i eth0
。
例えば、これを使用してホストとメタデータインスタンス間のトラフィックをスニッフィングやスプーフィングすることができます。
以下の例のように:
また、ホスト内でlocalhostにバインドされたネットワークサービスにアクセスしたり、ノードのメタデータ権限にアクセスすることもできます(これはコンテナがアクセスできるものと異なる場合があります)。
hostIPC
hostIPC=true
を使用すると、ホストのプロセス間通信(IPC)リソースにアクセスできます。たとえば、/dev/shm
内の共有メモリにアクセスできます。これにより、他のホストやポッドプロセスが使用している同じIPCリソースを読み取り/書き込みできます。これらのIPCメカニズムをさらに調査するには、ipcs
を使用します。
/dev/shmの調査 - この共有メモリの場所にあるファイルを確認します:
ls -la /dev/shm
既存のIPC施設の調査 -
/usr/bin/ipcs
を使用して、IPC施設が使用されているかどうかを確認できます。次のコマンドを使用して確認します:ipcs -a
機能の回復
シスコール unshare
が禁止されていない場合、次のコマンドを実行してすべての機能を回復できます:
シンボリックリンクを介したユーザー名前空間の悪用
https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/ で説明されている2番目のテクニックは、ユーザー名前空間でバインドマウントを悪用して、ホスト内のファイルに影響を与える方法を示しています(特定のケースでは、ファイルを削除します)。
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F4226785378-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FpWAf1y9UWEMh8PEO1vPV%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=44418454&sv=1)
Trickest を使用して、世界で最も先進的なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。 今すぐアクセスを取得:
CVEs
Runc exploit (CVE-2019-5736)
docker exec
をrootとして実行できる場合(おそらくsudoで)、CVE-2019-5736を悪用してコンテナから特権を昇格させることを試みることができます(こちらにエクスプロイトがあります)。このテクニックは基本的に、ホスト内の/bin/shバイナリをコンテナから上書きするものであり、docker execを実行すると誰でもペイロードをトリガーできます。
ペイロードを適切に変更し、go build main.go
でmain.goをビルドします。生成されたバイナリは、実行のためにdockerコンテナに配置する必要があります。
実行時に、[+] Overwritten /bin/sh successfully
と表示されると、ホストマシンから次のコマンドを実行する必要があります:
docker exec -it <container-name> /bin/sh
これにより、main.goファイルに存在するペイロードがトリガーされます。
詳細については: https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
コンテナが脆弱である可能性のある他のCVEについては、https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-listでリストを見つけることができます。
Docker Custom Escape
Docker Escape Surface
名前空間: プロセスは名前空間によって他のプロセスから完全に分離される必要があります。そのため、名前空間によって他のプロセスとのやり取りを回避することはできません(デフォルトでは、IPC、Unixソケット、ネットワークサービス、D-Bus、他のプロセスの
/proc
を介して通信できません)。ルートユーザー: プロセスを実行するデフォルトのユーザーはルートユーザーです(ただし、権限は制限されています)。
機能: Dockerは次の機能を残します:
cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
シスコール: これらはルートユーザーが呼び出せないシスコールです(機能の不足+Seccompのため)。他のシスコールを使用して脱出を試みることができます。
syscall_bf.cファイルは、Dockerコンテナ内で実行される特権昇格攻撃のためのシェルコードを含んでいます。この攻撃は、Linuxカーネルのシステムコールを悪用して、Dockerコンテナからホストマシンに特権昇格することを可能にします。攻撃者はこの手法を使用して、Dockerコンテナのセキュリティを回避し、ホストシステムに侵入することができます。
Container Breakout through Usermode helper Template
If you are in userspace (no kernel exploit involved) the way to find new escapes mainly involve the following actions (these templates usually require a container in privileged mode):
Find the path of the containers filesystem inside the host
You can do this via mount, or via brute-force PIDs as explained in the second release_agent exploit
Find some functionality where you can indicate the path of a script to be executed by a host process (helper) if something happens
You should be able to execute the trigger from inside the host
You need to know where the containers files are located inside the host to indicate a script you write inside the host
Have enough capabilities and disabled protections to be able to abuse that functionality
You might need to mount things o perform special privileged actions you cannot do in a default docker container
References
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F4226785378-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FpWAf1y9UWEMh8PEO1vPV%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=44418454&sv=1)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated