Docker Breakout / Privilege Escalation
Вивчайте та практикуйте хакінг AWS: Навчання AWS Red Team Expert (ARTE) від HackTricks
Вивчайте та практикуйте хакінг GCP:
Навчання GCP Red Team Expert (GRTE) від HackTricks
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2585115637-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FhAv2kYoPrT3n8552GaQU%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=55a3d9f2&sv=1)
Використовуйте Trickest для легкої побудови та автоматизації робочих процесів за допомогою найбільш продвинутих інструментів спільноти у світі. Отримайте доступ сьогодні:
Автоматичне перелічення та втеча
linpeas: Він також може перелічити контейнери
CDK: Цей інструмент досить корисний для переліку контейнера, в якому ви знаходитесь, навіть спробуйте втечу автоматично
amicontained: Корисний інструмент для отримання привілеїв, які має контейнер, щоб знайти способи втечі з нього
deepce: Інструмент для переліку та втечі з контейнерів
grype: Отримайте CVE, які містяться в програмному забезпеченні, встановленому в зображенні
Втеча через підключений Docker Socket
Якщо ви якимось чином виявите, що сокет 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
...
Втеча від зловживання можливостями
Вам слід перевірити можливості контейнера, якщо він має будь-які з наступних, ви можете втекти з нього: 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
Ви можете перевірити поточні можливості контейнера, використовуючи зазначені раніше автоматичні інструменти або:
На наступній сторінці ви можете дізнатися більше про можливості Linux та як їх зловживати для втечі/підвищення привілеїв:
Linux CapabilitiesВтеча з привілейованих контейнерів
Привілейований контейнер можна створити з прапорцем --privileged
або вимкненням конкретних захистів:
--cap-add=ALL
--security-opt apparmor=unconfined
--security-opt seccomp=unconfined
--security-opt label:disable
--pid=host
--userns=host
--uts=host
--cgroupns=host
Mount /dev
Прапорець --privileged
значно знижує безпеку контейнера, надаючи необмежений доступ до пристроїв та обхід кількох захистів. Для докладного розбору дивіться документацію щодо повного впливу --privileged
.
Привілейований + hostPID
З цими дозволами ви можете просто перейти до простору імен процесу, що працює на хості як root, наприклад init (pid:1), просто виконавши: nsenter --target 1 --mount --uts --ipc --net --pid -- bash
Перевірте це в контейнері, виконавши:
Привілейований
Лише з прапорцем privileged ви можете спробувати отримати доступ до диска хоста або спробувати втечі, зловживаючи release_agent або іншими втечами.
Перевірте наступні обхідні шляхи в контейнері, виконавши:
Підключення диска - Poc1
Налаштовані належним чином контейнери Docker не дозволять виконання команди, наприклад fdisk -l. Однак при неправильній конфігурації команди Docker, де вказано прапорці --privileged
або --device=/dev/sda1
з правами, можливо отримати привілеї для перегляду диска хоста.
Отже, для заволодіння хост-машини це тривіально:
І ось! Тепер ви можете отримати доступ до файлової системи хоста, оскільки вона змонтована в папці /mnt/hola
.
Монтування диска - Poc2
У контейнері зловмисник може спробувати отримати додатковий доступ до базової операційної системи хоста за допомогою записного тома hostPath, створеного кластером. Нижче наведено деякі загальні речі, які ви можете перевірити у контейнері, щоб побачити, чи використовуєте ви цей вектор атаки:
Привілейоване втеча за допомогою існуючого release_agent (cve-2022-0492) - PoC1
Привілейоване уникнення за допомогою створеного release_agent (cve-2022-0492) - PoC2
Знайдіть пояснення техніки за посиланням:
Docker release_agent cgroups escapeПривілейоване втеча, використовуючи release_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
Якщо ви можете отримати доступ до процесів хоста, ви зможете отримати доступ до багато чутливої інформації, збереженої в цих процесах. Запустіть тестову лабораторію:
Наприклад, ви зможете перелічити процеси, використовуючи щось на зразок ps auxn
та шукати чутливі деталі в командах.
Потім, оскільки ви можете отримати доступ до кожного процесу хоста в /proc/, ви можете просто вкрасти їхні секрети середовища, запустивши:
Ви також можете отримати доступ до файлових дескрипторів інших процесів та прочитати їх відкриті файли:
Ви також можете вбити процеси та спричинити DoS.
Якщо ви якимось чином маєте привілейований доступ до процесу поза контейнером, ви можете запустити щось на кшталт nsenter --target <pid> --all
або nsenter --target <pid> --mount --net --pid --cgroup
для запуску оболонки з тими ж обмеженнями ns (сподіваємося, ні) як у цьому процесі.
hostNetwork
Якщо контейнер був налаштований з використанням драйвера мережі Docker host (--network=host
), стек мережі цього контейнера не ізольований від хоста Docker (контейнер ділить простір мережі хоста), і контейнер не отримує власну IP-адресу. Іншими словами, контейнер прив'язує всі служби безпосередньо до IP-адреси хоста. Крім того, контейнер може перехоплювати ВСІ мережовий трафік, який хост відправляє та отримує на спільному інтерфейсі tcpdump -i eth0
.
Наприклад, це можна використовувати для перехоплення та навіть підробки трафіку між хостом та екземпляром метаданих.
Як у наступних прикладах:
Ви також зможете отримати доступ до мережевих служб, прив'язаних до localhost всередині хоста або навіть отримати доступ до прав метаданих вузла (які можуть відрізнятися від тих, які може отримати контейнер).
hostIPC
З hostIPC=true
ви отримуєте доступ до ресурсів міжпроцесного зв'язку (IPC) хоста, таких як спільна пам'ять в /dev/shm
. Це дозволяє читати/записувати там, де ті самі ресурси IPC використовуються іншими процесами хоста або підпроцесами. Використовуйте ipcs
, щоб докладніше дослідити ці механізми IPC.
Огляд /dev/shm - Шукайте файли в цьому місці спільної пам'яті:
ls -la /dev/shm
Огляд існуючих засобів IPC - Ви можете перевірити, чи використовуються які-небудь засоби IPC за допомогою
/usr/bin/ipcs
. Перевірте це за допомогою:ipcs -a
Відновлення можливостей
Якщо системний виклик unshare
не заборонено, ви можете відновити всі можливості, запустивши:
Зловживання простором користувача через символічні посилання
Друга техніка, пояснена в пості https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/, показує, як ви можете зловживати прив'язками монтування з використанням просторів користувача, щоб впливати на файли всередині хоста (у цьому конкретному випадку - видаляти файли).
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2585115637-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FhAv2kYoPrT3n8552GaQU%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=55a3d9f2&sv=1)
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, які працюють за допомогою найбільш розвинутих інструментів спільноти у світі. Отримайте доступ сьогодні:
CVEs
Використання уразливості Runc (CVE-2019-5736)
У випадку, якщо ви можете виконати docker exec
як root (імовірно, з sudo), ви можете спробувати підняти привілеї, вибравши втечу з контейнера, зловживаючи CVE-2019-5736 (експлойт тут). Ця техніка в основному перезапише бінарний файл /bin/sh хоста з контейнера, тому будь-хто, хто виконує docker exec, може викликати вразливість.
Змініть навантаження відповідно та зіберіть main.go за допомогою go build 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
Поверхня втечі Docker
Простори імен: Процес повинен бути повністю відокремлений від інших процесів за допомогою просторів імен, тому ми не можемо втекти взаємодіючи з іншими процесами через простори імен (за замовчуванням не може спілкуватися через IPC, unix сокети, мережеві служби, D-Bus,
/proc
інших процесів).Користувач root: За замовчуванням користувач, який запускає процес, є користувачем root (проте його привілеї обмежені).
Можливості: 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
Syscalls: Це syscalls, які користувач root не зможе викликати (через відсутність можливостей + Seccomp). Інші syscalls можуть бути використані для спроби втечі.
Цей код використовує прямі системні виклики для виконання привілейованої інструкції у контейнері 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%2F2585115637-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FhAv2kYoPrT3n8552GaQU%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=55a3d9f2&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