Linux Capabilities
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON є найважливішою подією в галузі кібербезпеки в Іспанії та однією з найважливіших в Європі. З метою просування технічних знань, цей конгрес є гарячою точкою зустрічі для професіоналів у сфері технологій та кібербезпеки в усіх дисциплінах.\
Linux Capabilities
Linux capabilities ділять привілеї root на менші, окремі одиниці, дозволяючи процесам мати підмножину привілеїв. Це мінімізує ризики, не надаючи повні привілеї root без потреби.
Проблема:
Звичайні користувачі мають обмежені дозволи, що впливає на завдання, такі як відкриття мережевого сокета, яке вимагає доступу root.
Набори можливостей:
Inherited (CapInh):
Мета: Визначає можливості, які передаються від батьківського процесу.
Функціональність: Коли створюється новий процес, він успадковує можливості від свого батька в цьому наборі. Корисно для підтримки певних привілеїв під час створення процесів.
Обмеження: Процес не може отримати можливості, яких не мав його батько.
Effective (CapEff):
Мета: Представляє фактичні можливості, які процес використовує в будь-який момент.
Функціональність: Це набір можливостей, які перевіряються ядром для надання дозволу на різні операції. Для файлів цей набір може бути прапором, що вказує, чи слід враховувати дозволені можливості файлу як ефективні.
Значення: Ефективний набір є критично важливим для негайних перевірок привілеїв, діючи як активний набір можливостей, які може використовувати процес.
Permitted (CapPrm):
Мета: Визначає максимальний набір можливостей, які може мати процес.
Функціональність: Процес може підвищити можливість з дозволеного набору до свого ефективного набору, надаючи йому можливість використовувати цю можливість. Він також може скинути можливості зі свого дозволеного набору.
Межа: Він діє як верхня межа для можливостей, які може мати процес, забезпечуючи, щоб процес не перевищував свій попередньо визначений обсяг привілеїв.
Bounding (CapBnd):
Мета: Встановлює межу для можливостей, які процес може коли-небудь отримати під час свого життєвого циклу.
Функціональність: Навіть якщо процес має певну можливість у своєму успадкованому або дозволеному наборі, він не може отримати цю можливість, якщо вона також не в межах набору.
Використання: Цей набір особливо корисний для обмеження потенціалу підвищення привілеїв процесу, додаючи додатковий рівень безпеки.
Ambient (CapAmb):
Мета: Дозволяє зберігати певні можливості під час системного виклику
execve
, який зазвичай призводить до повного скидання можливостей процесу.Функціональність: Забезпечує, щоб програми без SUID, які не мають асоційованих файлових можливостей, могли зберігати певні привілеї.
Обмеження: Можливості в цьому наборі підлягають обмеженням успадкованих і дозволених наборів, забезпечуючи, щоб вони не перевищували дозволені привілеї процесу.
Для отримання додаткової інформації перегляньте:
Процеси та Бінарні Можливості
Можливості Процесів
Щоб побачити можливості для конкретного процесу, використовуйте файл status у каталозі /proc. Оскільки він надає більше деталей, обмежимося лише інформацією, що стосується можливостей Linux. Зверніть увагу, що для всіх запущених процесів інформація про можливості зберігається для кожного потоку, для бінарних файлів у файловій системі вона зберігається в розширених атрибутах.
Ви можете знайти можливості, визначені в /usr/include/linux/capability.h
Ви можете знайти можливості поточного процесу в cat /proc/self/status
або виконавши capsh --print
, а також можливості інших користувачів у /proc/<pid>/status
Ця команда повинна повернути 5 рядків на більшості систем.
CapInh = Спадковані можливості
CapPrm = Дозволені можливості
CapEff = Ефективні можливості
CapBnd = Обмежувальний набір
CapAmb = Набір навколишніх можливостей
Ці шістнадцяткові числа не мають сенсу. Використовуючи утиліту capsh, ми можемо декодувати їх у назви можливостей.
Давайте перевіримо тепер capabilities, які використовуються ping
:
Хоча це працює, є інший і простіший спосіб. Щоб побачити можливості запущеного процесу, просто використовуйте інструмент getpcaps, за яким слідує його ідентифікатор процесу (PID). Ви також можете надати список ідентифікаторів процесів.
Давайте перевіримо можливості tcpdump
після надання бінарному файлу достатніх можливостей (cap_net_admin
та cap_net_raw
) для перехоплення мережі (tcpdump працює в процесі 9562):
Як ви можете бачити, надані можливості відповідають результатам двох способів отримання можливостей бінарного файлу. Інструмент getpcaps використовує системний виклик capget() для запиту доступних можливостей для певного потоку. Цей системний виклик потребує лише PID для отримання додаткової інформації.
Можливості бінарних файлів
Бінарні файли можуть мати можливості, які можна використовувати під час виконання. Наприклад, дуже поширено знаходити бінарний файл ping
з можливістю cap_net_raw
:
Ви можете шукати двійкові файли з можливостями за допомогою:
Скидання можливостей з capsh
Якщо ми скинемо можливості CAP_NET_RAW для ping, тоді утиліта ping більше не повинна працювати.
Крім виходу самого capsh, команда tcpdump також повинна викликати помилку.
/bin/bash: /usr/sbin/tcpdump: Операція не дозволена
Помилка чітко показує, що команді ping не дозволено відкривати сокет ICMP. Тепер ми точно знаємо, що це працює як очікувалося.
Видалити можливості
Ви можете видалити можливості бінарного файлу з
User Capabilities
Очевидно, можливо призначити можливості також користувачам. Це, ймовірно, означає, що кожен процес, виконуваний користувачем, зможе використовувати можливості користувача.
Виходячи з цього, цього та цього, потрібно налаштувати кілька файлів, щоб надати користувачу певні можливості, але той, що призначає можливості кожному користувачу, буде /etc/security/capability.conf
.
Приклад файлу:
Системні можливості
Компіліруючи наступну програму, можливо запустити оболонку bash в середовищі, яке надає можливості.
Всередині bash, виконуваного скомпільованим амбієнтним бінарником, можна спостерігати нові можливості (звичайний користувач не матиме жодної можливості в розділі "поточний").
Ви можете додавати лише ті можливості, які присутні як у дозволених, так і в успадкованих наборах.
Бінарні файли з усвідомленням можливостей/Бінарні файли без усвідомлення можливостей
Бінарні файли з усвідомленням можливостей не використовуватимуть нові можливості, надані середовищем, однак бінарні файли без усвідомлення можливостей використовуватимуть їх, оскільки не відхилять їх. Це робить бінарні файли без усвідомлення можливостей вразливими в спеціальному середовищі, яке надає можливості бінарним файлам.
Можливості сервісу
За замовчуванням сервіс, що працює від імені root, матиме призначені всі можливості, і в деяких випадках це може бути небезпечно. Тому файл конфігурації сервісу дозволяє вказати можливості, які ви хочете, щоб він мав, і користувача, який повинен виконувати сервіс, щоб уникнути запуску сервісу з непотрібними привілеями:
Capabilities in Docker Containers
За замовчуванням Docker призначає кілька можливостей контейнерам. Дуже легко перевірити, які це можливості, запустивши:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON є найактуальнішою подією в галузі кібербезпеки в Іспанії та однією з найважливіших в Європі. З метою просування технічних знань, цей конгрес є гарячою точкою зустрічі для професіоналів у сфері технологій та кібербезпеки в усіх дисциплінах.
Privesc/Container Escape
Можливості корисні, коли ви хочете обмежити свої власні процеси після виконання привілейованих операцій (наприклад, після налаштування chroot і прив'язки до сокета). Однак їх можна експлуатувати, передаючи їм шкідливі команди або аргументи, які потім виконуються від імені root.
Ви можете примусово застосувати можливості до програм, використовуючи setcap
, і запитувати їх, використовуючи getcap
:
+ep
означає, що ви додаєте можливість (“-” видалить її) як Ефективну та Дозволену.
Щоб ідентифікувати програми в системі або папці з можливостями:
Приклад експлуатації
У наступному прикладі двійковий файл /usr/bin/python2.6
виявляється вразливим до підвищення привілеїв:
Можливості, необхідні для tcpdump
, щоб дозволити будь-якому користувачу перехоплювати пакети:
Спеціальний випадок "порожніх" можливостей
З документації: Зверніть увагу, що можна призначити порожні набори можливостей програмному файлу, і таким чином можливо створити програму з set-user-ID-root, яка змінює ефективний та збережений set-user-ID процесу, що виконує програму, на 0, але не надає жодних можливостей цьому процесу. Або, простіше кажучи, якщо у вас є двійковий файл, який:
не належить root
не має встановлених бітів
SUID
/SGID
має порожні набори можливостей (наприклад:
getcap myelf
повертаєmyelf =ep
)
тоді цей двійковий файл буде виконуватись як root.
CAP_SYS_ADMIN
CAP_SYS_ADMIN
є надзвичайно потужною можливістю Linux, часто прирівнюється до рівня близького до root через свої широкі адміністративні привілеї, такі як монтування пристроїв або маніпулювання функціями ядра. Хоча вона є незамінною для контейнерів, що імітують цілі системи, CAP_SYS_ADMIN
створює значні проблеми безпеки, особливо в контейнеризованих середовищах, через свій потенціал для ескалації привілеїв та компрометації системи. Тому її використання вимагає суворих оцінок безпеки та обережного управління, з сильною перевагою для скидання цієї можливості в контейнерах, специфічних для застосунків, щоб дотримуватись принципу найменших привілеїв та мінімізувати поверхню атаки.
Приклад з двійковим файлом
Використовуючи python, ви можете змонтувати модифікований passwd файл поверх реального passwd файлу:
І нарешті монтуйте змінений passwd
файл на /etc/passwd
:
І ви зможете su
як root використовуючи пароль "password".
Приклад з середовищем (вихід з Docker)
Ви можете перевірити увімкнені можливості всередині контейнера docker за допомогою:
Всередині попереднього виходу ви можете побачити, що можливість SYS_ADMIN увімкнена.
Mount
Це дозволяє контейнеру docker монтувати диск хоста та вільно до нього отримувати доступ:
Повний доступ
У попередньому методі ми змогли отримати доступ до диска хоста docker. Якщо ви виявите, що хост працює на сервері ssh, ви можете створити користувача всередині диска хоста docker і отримати доступ до нього через SSH:
CAP_SYS_PTRACE
Це означає, що ви можете втекти з контейнера, інжектуючи shellcode в деякий процес, що виконується всередині хоста. Щоб отримати доступ до процесів, що виконуються всередині хоста, контейнер потрібно запускати принаймні з --pid=host
.
CAP_SYS_PTRACE
надає можливість використовувати функціональність налагодження та трасування системних викликів, що надається ptrace(2)
, а також виклики крос-пам'яті, такі як process_vm_readv(2)
і process_vm_writev(2)
. Хоча це потужний інструмент для діагностики та моніторингу, якщо CAP_SYS_PTRACE
увімкнено без обмежувальних заходів, таких як фільтр seccomp на ptrace(2)
, це може суттєво підірвати безпеку системи. Зокрема, це може бути використано для обходу інших обмежень безпеки, зокрема тих, що накладаються seccomp, як показано в доказах концепції (PoC), таких як цей.
Приклад з бінарним файлом (python)
Приклад з бінарним файлом (gdb)
gdb
з можливістю ptrace
:
Створіть shellcode за допомогою msfvenom для ін'єкції в пам'ять через gdb
Відлагодьте процес root за допомогою gdb та скопіюйте раніше згенеровані рядки gdb:
Приклад з середовищем (вихід з Docker) - Інше зловживання gdb
Якщо GDB встановлено (або ви можете встановити його за допомогою apk add gdb
або apt install gdb
, наприклад), ви можете налагоджувати процес з хоста і змусити його викликати функцію system
. (Ця техніка також вимагає можливості SYS_ADMIN
).
Ви не зможете побачити вихід команди, яка була виконана, але вона буде виконана цим процесом (тому отримайте rev shell).
Якщо ви отримали помилку "No symbol "system" in current context.", перевірте попередній приклад завантаження shellcode в програму через gdb.
Приклад з середовищем (вихід з Docker) - Впровадження Shellcode
Ви можете перевірити активовані можливості всередині контейнера docker, використовуючи:
Список процесів, що працюють на хості ps -eaf
Отримати архітектуру
uname -m
Знайти shellcode для архітектури (https://www.exploit-db.com/exploits/41128)
Знайти програму для впровадження shellcode в пам'ять процесу (https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c)
Змінити shellcode всередині програми та скомпілювати її
gcc inject.c -o inject
Впровадити її та отримати ваш shell:
./inject 299; nc 172.17.0.1 5600
CAP_SYS_MODULE
CAP_SYS_MODULE
надає процесу можливість завантажувати та вивантажувати модулі ядра (init_module(2)
, finit_module(2)
та delete_module(2)
системні виклики), пропонуючи прямий доступ до основних операцій ядра. Ця можливість представляє критичні ризики для безпеки, оскільки дозволяє ескалацію привілеїв та повний компроміс системи, дозволяючи модифікації ядра, тим самим обходячи всі механізми безпеки Linux, включаючи Linux Security Modules та ізоляцію контейнерів.
Це означає, що ви можете вставляти/видаляти модулі ядра в/з ядра хост-машини.
Приклад з бінарним файлом
У наступному прикладі бінарний python
має цю можливість.
За замовчуванням команда modprobe
перевіряє список залежностей та файли мапи в каталозі /lib/modules/$(uname -r)
.
Щоб зловживати цим, давайте створимо підроблену папку lib/modules:
Тоді скомпілюйте модуль ядра, приклади якого ви можете знайти нижче, і скопіюйте його до цієї папки:
Нарешті, виконайте необхідний код python для завантаження цього модуля ядра:
Приклад 2 з бінарним файлом
У наступному прикладі бінарний файл kmod
має цю можливість.
Що означає, що можливо використовувати команду insmod
для вставки модуля ядра. Слідуйте прикладу нижче, щоб отримати reverse shell, зловживаючи цим правом.
Приклад з середовищем (вихід з Docker)
Ви можете перевірити активовані можливості всередині контейнера docker, використовуючи:
Всередині попереднього виходу ви можете побачити, що можливість SYS_MODULE увімкнена.
Створіть ядровий модуль, який буде виконувати зворотний шелл, та Makefile для компіляції його:
Пробіл перед кожним словом make у Makefile повинен бути табуляцією, а не пробілами!
Виконайте make
, щоб скомпілювати його.
Нарешті, запустіть nc
всередині оболонки та завантажте модуль з іншої, і ви захопите оболонку в процесі nc:
Код цієї техніки був скопійований з лабораторії "Зловживання можливістю SYS_MODULE" з https://www.pentesteracademy.com/
Інший приклад цієї техніки можна знайти на https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host
CAP_DAC_READ_SEARCH
CAP_DAC_READ_SEARCH дозволяє процесу обійти перевірки дозволів на читання файлів та на читання і виконання каталогів. Його основне використання - для пошуку або читання файлів. Однак він також дозволяє процесу використовувати функцію open_by_handle_at(2)
, яка може отримати доступ до будь-якого файлу, включаючи ті, що знаходяться поза простором монтування процесу. Ідентифікатор, що використовується в open_by_handle_at(2)
, повинен бути непрозорим ідентифікатором, отриманим через name_to_handle_at(2)
, але він може містити чутливу інформацію, таку як номери inode, які вразливі до підробки. Потенціал для експлуатації цієї можливості, особливо в контексті контейнерів Docker, був продемонстрований Себастьяном Крахмером з експлойтом shocker, як було проаналізовано тут. Це означає, що ви можете обійти перевірки дозволів на читання файлів та перевірки дозволів на читання/виконання каталогів.
Приклад з бінарним файлом
Бінарний файл зможе читати будь-який файл. Отже, якщо файл, наприклад, tar має цю можливість, він зможе читати файл shadow:
Приклад з binary2
У цьому випадку припустимо, що python
бінарний файл має цю можливість. Щоб перерахувати файли root, ви можете зробити:
І щоб прочитати файл, ви можете зробити:
Приклад у середовищі (вихід з Docker)
Ви можете перевірити увімкнені можливості всередині контейнера docker, використовуючи:
Всередині попереднього виходу ви можете побачити, що можливість DAC_READ_SEARCH увімкнена. В результаті контейнер може налагоджувати процеси.
Ви можете дізнатися, як працює наступне експлуатування, за посиланням https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3, але в резюме CAP_DAC_READ_SEARCH не тільки дозволяє нам проходити через файлову систему без перевірок дозволів, але також явно усуває будь-які перевірки для open_by_handle_at(2) і може дозволити нашому процесу отримувати доступ до чутливих файлів, відкритих іншими процесами.
Оригінальний експлойт, який зловживає цими дозволами для читання файлів з хоста, можна знайти тут: http://stealth.openwall.net/xSports/shocker.c, наступне є модифікованою версією, яка дозволяє вам вказати файл, який ви хочете прочитати, як перший аргумент і скинути його в файл.
Експлойт повинен знайти вказівник на щось, що змонтоване на хості. Оригінальний експлойт використовував файл /.dockerinit, а ця модифікована версія використовує /etc/hostname. Якщо експлойт не працює, можливо, вам потрібно встановити інший файл. Щоб знайти файл, який змонтований на хості, просто виконайте команду mount:
![](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-e8bf27d92631c9009d2613b4bac9f501b6290062%252Fimage%2520%28407%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=90027b5b&sv=1)
Код цієї техніки був скопійований з лабораторії "Зловживання можливістю DAC_READ_SEARCH" з https://www.pentesteracademy.com/
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON є найактуальнішою подією в галузі кібербезпеки в Іспанії та однією з найважливіших в Європі. З метою просування технічних знань, цей конгрес є гарячою точкою зустрічі для професіоналів у сфері технологій та кібербезпеки в усіх дисциплінах.
CAP_DAC_OVERRIDE
Це означає, що ви можете обійти перевірки прав на запис для будь-якого файлу, тому ви можете записати будь-який файл.
Є багато файлів, які ви можете перезаписати для підвищення привілеїв, ви можете отримати ідеї звідси.
Приклад з бінарним файлом
У цьому прикладі vim має цю можливість, тому ви можете змінити будь-який файл, наприклад passwd, sudoers або shadow:
Приклад з бінарним файлом 2
У цьому прикладі python
бінарний файл матиме цю можливість. Ви можете використовувати python для перезапису будь-якого файлу:
Приклад з середовищем + CAP_DAC_READ_SEARCH (вихід з Docker)
Ви можете перевірити активовані можливості всередині контейнера docker за допомогою:
По-перше, прочитайте попередній розділ, що зловживає можливістю DAC_READ_SEARCH для читання довільних файлів хоста та скомпілюйте експлойт. Потім скомпілюйте наступну версію експлойту shocker, яка дозволить вам записувати довільні файли всередині файлової системи хоста:
Щоб вийти з контейнера docker, ви можете завантажити файли /etc/shadow
та /etc/passwd
з хоста, додати до них нового користувача і використати shocker_write
для їх перезапису. Потім доступ через ssh.
Код цієї техніки був скопійований з лабораторії "Зловживання можливістю DAC_OVERRIDE" з https://www.pentesteracademy.com
CAP_CHOWN
Це означає, що можливо змінити власність будь-якого файлу.
Приклад з бінарним файлом
Припустимо, що бінарний файл python
має цю можливість, ви можете змінити власника файлу shadow, змінити пароль root і підвищити привілеї:
Або з бінарним файлом ruby
, що має цю можливість:
CAP_FOWNER
Це означає, що можливо змінювати дозволи будь-якого файлу.
Приклад з бінарним файлом
Якщо python має цю можливість, ви можете змінити дозволи файлу shadow, змінити пароль root і підвищити привілеї:
CAP_SETUID
Це означає, що можливо встановити ефективний ідентифікатор користувача створеного процесу.
Приклад з бінарним файлом
Якщо python має цю можливість, ви можете дуже легко зловживати цим для підвищення привілеїв до root:
Інший спосіб:
CAP_SETGID
Це означає, що можливо встановити ефективний ідентифікатор групи створеного процесу.
Є багато файлів, які ви можете перезаписати для ескалації привілеїв, ви можете отримати ідеї звідси.
Приклад з бінарним файлом
У цьому випадку вам слід шукати цікаві файли, які група може читати, оскільки ви можете видавати себе за будь-яку групу:
Якщо ви знайшли файл, який можна зловживати (через читання або запис), щоб підвищити привілеї, ви можете отримати оболонку, імплементуючи цікаву групу за допомогою:
У цьому випадку група shadow була видана за іншу, тому ви можете прочитати файл /etc/shadow
:
Якщо docker встановлений, ви можете вдаватися до групи docker і зловживати нею для зв'язку з docker socket та ескалації привілеїв.
CAP_SETFCAP
Це означає, що можливо встановлювати можливості на файли та процеси
Приклад з бінарним файлом
Якщо python має цю можливість, ви можете дуже легко зловживати нею для ескалації привілеїв до root:
Зверніть увагу, що якщо ви встановите нову можливість для бінарного файлу з CAP_SETFCAP, ви втратите цю можливість.
Якщо у вас є SETUID capability, ви можете перейти до його розділу, щоб дізнатися, як підвищити привілеї.
Приклад з середовищем (вихід з Docker)
За замовчуванням можливість CAP_SETFCAP надається процесу всередині контейнера в Docker. Ви можете перевірити це, виконавши щось на зразок:
Ця можливість дозволяє надавати будь-яку іншу можливість бінарним файлам, тому ми можемо подумати про втечу з контейнера, зловживаючи будь-яким з інших витоків можливостей, згаданих на цій сторінці. Однак, якщо ви спробуєте надати, наприклад, можливості CAP_SYS_ADMIN і CAP_SYS_PTRACE бінарному файлу gdb, ви виявите, що можете їх надати, але бінарний файл не зможе виконуватися після цього:
From the docs: Permitted: Це обмежуючий надмножина для ефективних можливостей, які потік може прийняти. Це також обмежуючий надмножина для можливостей, які можуть бути додані до успадковуваного набору потоком, який не має можливості CAP_SETPCAP у своєму ефективному наборі. Схоже, що дозволені можливості обмежують ті, які можуть бути використані. Однак Docker також за замовчуванням надає CAP_SETPCAP, тому ви можете мати можливість встановити нові можливості всередині успадковуваних. Однак у документації цієї можливості: CAP_SETPCAP : […] додати будь-яку можливість з обмежувального набору викликаного потоку до його успадковуваного набору. Схоже, що ми можемо лише додавати до успадковуваного набору можливості з обмежувального набору. Це означає, що ми не можемо додати нові можливості, такі як CAP_SYS_ADMIN або CAP_SYS_PTRACE в успадкований набір для ескалації привілеїв.
CAP_SYS_RAWIO
CAP_SYS_RAWIO надає ряд чутливих операцій, включаючи доступ до /dev/mem
, /dev/kmem
або /proc/kcore
, зміну mmap_min_addr
, доступ до системних викликів ioperm(2)
та iopl(2)
, а також різні команди диска. FIBMAP ioctl(2)
також активується через цю можливість, що викликало проблеми в минулому. Згідно з мануалом, це також дозволяє власнику описово виконувати ряд специфічних для пристрою операцій на інших пристроях
.
Це може бути корисно для ескалації привілеїв та виходу з Docker.
CAP_KILL
Це означає, що можливо вбити будь-який процес.
Приклад з бінарним файлом
Припустимо, що python
бінарний файл має цю можливість. Якщо ви також могли б змінити деяку конфігурацію служби або сокета (або будь-який конфігураційний файл, пов'язаний зі службою), ви могли б створити бекдор, а потім вбити процес, пов'язаний з цією службою, і чекати, поки новий конфігураційний файл буде виконано з вашим бекдором.
Privesc з kill
Якщо у вас є можливості kill і є node програма, що працює як root (або як інший користувач), ви, напевно, можете надіслати їй сигнал SIGUSR1 і змусити її відкрити нод дебагер, до якого ви можете підключитися.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON є найважливішою подією в сфері кібербезпеки в Іспанії та однією з найважливіших в Європі. З метою просування технічних знань, цей конгрес є гарячою точкою зустрічі для професіоналів у сфері технологій та кібербезпеки в усіх дисциплінах.
CAP_NET_BIND_SERVICE
Це означає, що можливо прослуховувати будь-який порт (навіть привілейовані). Ви не можете безпосередньо підвищити привілеї з цією можливістю.
Приклад з бінарним файлом
Якщо python
має цю можливість, він зможе прослуховувати будь-який порт і навіть підключатися з нього до будь-якого іншого порту (деякі сервіси вимагають підключень з конкретних привілейованих портів)
CAP_NET_RAW
CAP_NET_RAW можливість дозволяє процесам створювати RAW та PACKET сокети, що дозволяє їм генерувати та надсилати довільні мережеві пакети. Це може призвести до ризиків безпеки в контейнеризованих середовищах, таких як підробка пакетів, ін'єкція трафіку та обходження мережевих контрольних механізмів. Зловмисники можуть скористатися цим, щоб втручатися в маршрутизацію контейнерів або скомпрометувати безпеку мережі хоста, особливо без адекватного захисту брандмауера. Крім того, CAP_NET_RAW є критично важливим для привілейованих контейнерів для підтримки операцій, таких як ping через RAW ICMP запити.
Це означає, що можливо перехоплювати трафік. Ви не можете безпосередньо підвищити привілеї з цією можливістю.
Приклад з бінарним файлом
Якщо бінарний файл tcpdump
має цю можливість, ви зможете використовувати його для захоплення мережевої інформації.
Зверніть увагу, що якщо середовище надає цю можливість, ви також можете використовувати tcpdump
для перехоплення трафіку.
Приклад з бінарним 2
Наступний приклад - це python2
код, який може бути корисним для перехоплення трафіку інтерфейсу "lo" (localhost). Код взято з лабораторії "Основи: CAP-NET_BIND + NET_RAW" з https://attackdefense.pentesteracademy.com/
CAP_NET_ADMIN + CAP_NET_RAW
CAP_NET_ADMIN можливість надає власнику право змінювати мережеві конфігурації, включаючи налаштування брандмауера, таблиці маршрутизації, дозволи сокетів та налаштування мережевих інтерфейсів у відкритих просторах імен мережі. Вона також дозволяє увімкнути проміскуїтний режим на мережевих інтерфейсах, що дозволяє перехоплювати пакети через простори імен.
Приклад з бінарним файлом
Припустимо, що бінарний файл python має ці можливості.
CAP_LINUX_IMMUTABLE
Це означає, що можливо змінювати атрибути inode. Ви не можете безпосередньо підвищити привілеї з цією можливістю.
Приклад з бінарним файлом
Якщо ви виявите, що файл є незмінним, і python має цю можливість, ви можете видалити атрибут незмінності та зробити файл змінюваним:
Зверніть увагу, що зазвичай цей незмінний атрибут встановлюється та видаляється за допомогою:
CAP_SYS_CHROOT
CAP_SYS_CHROOT дозволяє виконання системного виклику chroot(2)
, що потенційно може дозволити втечу з середовищ chroot(2)
через відомі вразливості:
CAP_SYS_BOOT
CAP_SYS_BOOT не лише дозволяє виконання системного виклику reboot(2)
для перезавантаження системи, включаючи специфічні команди, такі як LINUX_REBOOT_CMD_RESTART2
, адаптовані для певних апаратних платформ, але також дозволяє використання kexec_load(2)
і, починаючи з Linux 3.17, kexec_file_load(2)
для завантаження нових або підписаних аварійних ядер відповідно.
CAP_SYSLOG
CAP_SYSLOG був відокремлений від ширшого CAP_SYS_ADMIN в Linux 2.6.37, спеціально надаючи можливість використовувати виклик syslog(2)
. Ця можливість дозволяє переглядати адреси ядра через /proc
та подібні інтерфейси, коли налаштування kptr_restrict
встановлено на 1, що контролює відкритість адрес ядра. Починаючи з Linux 2.6.39, значення за замовчуванням для kptr_restrict
становить 0, що означає, що адреси ядра відкриті, хоча багато дистрибутивів встановлюють це на 1 (сховати адреси, крім uid 0) або 2 (завжди ховати адреси) з міркувань безпеки.
Крім того, CAP_SYSLOG дозволяє доступ до виходу dmesg
, коли dmesg_restrict
встановлено на 1. Незважаючи на ці зміни, CAP_SYS_ADMIN зберігає можливість виконувати операції syslog
через історичні прецеденти.
CAP_MKNOD
CAP_MKNOD розширює функціональність системного виклику mknod
за межами створення звичайних файлів, FIFO (іменованих каналів) або сокетів домену UNIX. Він спеціально дозволяє створення спеціальних файлів, до яких належать:
S_IFCHR: Символьні спеціальні файли, які є пристроями, такими як термінали.
S_IFBLK: Блочні спеціальні файли, які є пристроями, такими як диски.
Ця можливість є важливою для процесів, які потребують можливості створювати файли пристроїв, що полегшує безпосередню взаємодію з апаратним забезпеченням через символьні або блочні пристрої.
Це стандартна можливість docker (https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19).
Ця можливість дозволяє здійснювати ескалацію привілеїв (через повний доступ до диска) на хості за таких умов:
Мати початковий доступ до хоста (без привілеїв).
Мати початковий доступ до контейнера (з привілеями (EUID 0) та ефективним
CAP_MKNOD
).Хост і контейнер повинні ділити одне й те саме простір користувачів.
Кроки для створення та доступу до блочного пристрою в контейнері:
На хості як стандартний користувач:
Визначте свій поточний ідентифікатор користувача за допомогою
id
, наприклад,uid=1000(standarduser)
.Визначте цільовий пристрій, наприклад,
/dev/sdb
.
Всередині контейнера як
root
:
Повернення на хост:
Цей підхід дозволяє стандартному користувачу отримати доступ і потенційно прочитати дані з /dev/sdb
через контейнер, експлуатуючи спільні простори імен користувачів та дозволи, встановлені на пристрої.
CAP_SETPCAP
CAP_SETPCAP дозволяє процесу змінювати набори можливостей іншого процесу, що дозволяє додавати або видаляти можливості з ефективних, успадкованих і дозволених наборів. Однак процес може змінювати лише ті можливості, які він має у своєму власному дозволеному наборі, що забезпечує неможливість підвищення привілеїв іншого процесу понад його власні. Останні оновлення ядра посилили ці правила, обмеживши CAP_SETPCAP
лише на зменшення можливостей у власному або у дозволених наборах його нащадків, з метою зменшення ризиків безпеки. Використання вимагає наявності CAP_SETPCAP
у ефективному наборі та цільових можливостей у дозволеному наборі, використовуючи capset()
для модифікацій. Це підсумовує основну функцію та обмеження CAP_SETPCAP
, підкреслюючи його роль у управлінні привілеями та підвищенні безпеки.
CAP_SETPCAP
— це можливість Linux, яка дозволяє процесу модифікувати набори можливостей іншого процесу. Вона надає можливість додавати або видаляти можливості з ефективних, успадкованих і дозволених наборів можливостей інших процесів. Однак існують певні обмеження на те, як ця можливість може бути використана.
Процес з CAP_SETPCAP
може надавати або видаляти лише ті можливості, які є в його власному дозволеному наборі можливостей. Іншими словами, процес не може надати можливість іншому процесу, якщо він сам не має цієї можливості. Це обмеження запобігає підвищенню привілеїв іншого процесу понад його власний рівень привілеїв.
Більше того, в останніх версіях ядра можливість CAP_SETPCAP
була додатково обмежена. Вона більше не дозволяє процесу довільно змінювати набори можливостей інших процесів. Натомість, вона дозволяє процесу лише знижувати можливості у своєму власному дозволеному наборі можливостей або у дозволеному наборі можливостей його нащадків. Це зміна була введена для зменшення потенційних ризиків безпеки, пов'язаних з можливістю.
Щоб ефективно використовувати CAP_SETPCAP
, вам потрібно мати цю можливість у своєму ефективному наборі можливостей і цільові можливості у своєму дозволеному наборі можливостей. Ви можете використовувати системний виклик capset()
для модифікації наборів можливостей інших процесів.
Підсумовуючи, CAP_SETPCAP
дозволяє процесу модифікувати набори можливостей інших процесів, але він не може надавати можливості, яких не має сам. Крім того, через проблеми безпеки, його функціональність була обмежена в останніх версіях ядра, щоб дозволити лише зменшення можливостей у власному дозволеному наборі можливостей або у дозволених наборах можливостей його нащадків.
Посилання
Більшість цих прикладів були взяті з деяких лабораторій https://attackdefense.pentesteracademy.com/, тому якщо ви хочете практикувати ці техніки підвищення привілеїв, я рекомендую ці лабораторії.
Інші посилання:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON — це найважливіша подія в галузі кібербезпеки в Іспанії та одна з найважливіших в Європі. З метою просування технічних знань, цей конгрес є гарячою точкою зустрічі для професіоналів у галузі технологій та кібербезпеки в усіх дисциплінах.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated