2375, 2376 Pentesting Docker
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Docker є передовою платформою в індустрії контейнеризації, що очолює безперервні інновації. Він полегшує безперешкодне створення та розповсюдження додатків, від традиційних до футуристичних, і забезпечує їх безпечне розгортання в різних середовищах.
containerd: Це основний час виконання для контейнерів, що відповідає за всебічне управління життєвим циклом контейнера. Це включає в себе обробку переносу та зберігання образів, а також нагляд за виконанням, моніторингом та мережевими з'єднаннями контейнерів. Більш детальні відомості про containerd досліджуються далі.
container-shim відіграє критичну роль як посередник в обробці безголових контейнерів, безперешкодно беручи на себе функції від runc після ініціалізації контейнерів.
runc: Відомий своїми легкими та універсальними можливостями виконання контейнерів, runc відповідає стандарту OCI. Він використовується containerd для запуску та управління контейнерами відповідно до вказівок OCI, еволюціонуючи з оригінального libcontainer.
grpc є важливим для полегшення комунікації між containerd та docker-engine, забезпечуючи ефективну взаємодію.
OCI є ключовим у підтримці специфікацій OCI для часу виконання та образів, при цьому останні версії Docker є сумісними з обома стандартами OCI для образів та часу виконання.
Containerd був спеціально розроблений для задоволення потреб контейнерних платформ, таких як Docker і Kubernetes, серед інших. Він має на меті спростити виконання контейнерів на різних операційних системах, включаючи Linux, Windows, Solaris та інші, абстрагуючи функціональність, специфічну для операційної системи, та системні виклики. Мета Containerd полягає в тому, щоб включити лише основні функції, необхідні його користувачам, прагнучи уникнути непотрібних компонентів. Однак досягти цієї мети повністю вважається складним завданням.
Ключовим дизайнерським рішенням є те, що Containerd не обробляє мережеві з'єднання. Мережа вважається критично важливим елементом у розподілених системах, з такими складнощами, як програмно визначена мережа (SDN) та виявлення сервісів, які значно відрізняються від однієї платформи до іншої. Тому Containerd залишає управління мережевими аспектами платформам, які він підтримує.
Хоча Docker використовує Containerd для запуску контейнерів, важливо зазначити, що Containerd підтримує лише підмнож функціональності Docker. Зокрема, Containerd не має можливостей управління мережею, присутніх у Docker, і не підтримує створення Docker swarms безпосередньо. Це відмінність підкреслює зосереджену роль Containerd як середовища виконання контейнерів, делегуючи більш спеціалізовані функції платформам, з якими він інтегрується.
Podman — це відкритий контейнерний движок, який відповідає стандартам Open Container Initiative (OCI), розроблений і підтримуваний компанією Red Hat. Він відрізняється від Docker кількома особливими функціями, зокрема архітектурою без демонів та підтримкою контейнерів без прав root, що дозволяє користувачам запускати контейнери без привілеїв root.
Podman розроблений для сумісності з API Docker, що дозволяє використовувати команди Docker CLI. Ця сумісність поширюється на його екосистему, яка включає інструменти, такі як Buildah для створення образів контейнерів і Skopeo для операцій з образами, таких як push, pull і inspect. Більше деталей про ці інструменти можна знайти на їхній сторінці GitHub.
Ключові Відмінності
Архітектура: На відміну від клієнт-серверної моделі Docker з фоновим демоном, Podman працює без демона. Цей дизайн означає, що контейнери працюють з привілеями користувача, який їх запускає, підвищуючи безпеку шляхом усунення необхідності в доступі root.
Інтеграція з Systemd: Podman інтегрується з systemd для управління контейнерами, що дозволяє керувати контейнерами через одиниці systemd. Це контрастує з використанням Docker, який в основному використовує systemd для управління процесом демона Docker.
Контейнери без прав root: Ключовою особливістю Podman є його здатність запускати контейнери під привілеями ініціюючого користувача. Цей підхід мінімізує ризики, пов'язані з порушеннями безпеки контейнерів, забезпечуючи, що зловмисники отримують лише привілеї скомпрометованого користувача, а не доступ root.
Підхід Podman пропонує безпечну та гнучку альтернативу Docker, підкреслюючи управління привілеями користувачів і сумісність з існуючими робочими процесами Docker.
Зверніть увагу, що оскільки podman прагне підтримувати той же API, що й docker, ви можете використовувати ті ж команди з podman, що й з docker, такі як:
Remote API за замовчуванням працює на порту 2375, коли він увімкнений. Сервіс за замовчуванням не вимагатиме аутентифікації, що дозволяє зловмиснику запустити привілейований контейнер docker. Використовуючи Remote API, можна підключити хости / (кореневий каталог) до контейнера та читати/записувати файли середовища хоста.
Порт за замовчуванням: 2375
Зверніть увагу, що для перерахунку docker API ви можете використовувати команду docker
або curl
, як у наступному прикладі:
Якщо ви можете зв'язатися з віддаленим docker API за допомогою команди docker
, ви можете виконати будь-які з docker команд, які були раніше прокоментовані для взаємодії з сервісом.
Ви можете export DOCKER_HOST="tcp://localhost:2375"
і уникнути використання параметра -H
з командою docker
Швидке підвищення привілеїв
Curl
Іноді ви побачите 2376 для кінцевої точки TLS. Мені не вдалося підключитися до нього за допомогою клієнта docker, але це можливо зробити за допомогою curl.
Якщо ви хочете більше інформації про це, більше інформації доступно там, звідки я скопіював команди: https://securityboulevard.com/2019/02/abusing-docker-api-socket/
In the following page you can find ways to вийти з контейнера docker:
Docker SecurityЗловживаючи цим, можливо вийти з контейнера, ви можете запустити слабкий контейнер на віддаленій машині, вийти з нього і скомпрометувати машину:
Якщо ви знаходитесь всередині хоста, який використовує docker, ви можете прочитати цю інформацію, щоб спробувати підвищити привілеї.
Перевірте env (розділ змінних середовища) на наявність секретів, і ви можете знайти:
Паролі.
IP-адреси.
Порти.
Шляхи.
Інше… .
Якщо ви хочете витягти файл:
Ви можете використовувати інструмент https://github.com/docker/docker-bench-security для перевірки вашої поточної установки docker.
./docker-bench-security.sh
Ви можете використовувати інструмент https://github.com/kost/dockscan для перевірки вашої поточної установки docker.
dockscan -v unix:///var/run/docker.sock
Ви можете використовувати інструмент https://github.com/genuinetools/amicontained для перевірки привілеїв, які контейнер матиме при запуску з різними параметрами безпеки. Це корисно для розуміння наслідків використання деяких параметрів безпеки для запуску контейнера:
docker run --rm -it r.j3ss.co/amicontained
docker run --rm -it --pid host r.j3ss.co/amicontained
docker run --rm -it --security-opt "apparmor=unconfined" r.j3ss.co/amicontained
Ви можете використовувати образ docker з https://github.com/quay/clair, щоб сканувати ваші інші образи docker і знаходити вразливості.
docker run --rm -v /root/clair_config/:/config -p 6060-6061:6060-6061 -d clair -config="/config/config.yaml"
clair-scanner -c http://172.17.0.3:6060 --ip 172.17.0.1 ubuntu-image
Ви можете використовувати інструмент https://github.com/buddy-works/dockerfile-linter для перевірки вашого Dockerfile і знаходження всіх видів неправильних налаштувань. Кожному неправильному налаштуванню буде присвоєно ID, ви можете знайти тут https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md, як виправити кожне з них.
dockerfilelinter -f Dockerfile
Ви можете використовувати інструмент https://github.com/replicatedhq/dockerfilelint для перевірки вашого Dockerfile і знаходження всіх видів неправильних налаштувань.
dockerfilelint Dockerfile
Ви можете використовувати інструмент https://github.com/RedCoolBeans/dockerlint для перевірки вашого Dockerfile і знаходження всіх видів неправильних налаштувань.
dockerlint Dockerfile
Ви можете використовувати інструмент https://github.com/hadolint/hadolint для перевірки вашого Dockerfile і знаходження всіх видів неправильних налаштувань.
hadolint Dockerfile
Ви можете використовувати інструмент https://github.com/falcosecurity/falco для виявлення підозрілої поведінки в запущених контейнерах.
Зверніть увагу в наступному фрагменті, як Falco компілює модуль ядра та вставляє його. Після цього він завантажує правила і починає реєструвати підозрілі дії. У цьому випадку він виявив 2 привілейовані контейнери, один з яких мав чутливе монтування, і через кілька секунд виявив, як оболонка була відкрита всередині одного з контейнерів.
Ви можете використовувати auditd для моніторингу docker.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)