Настало и мое время подвести итоги года.
В этом году жизнь, в прямом смысле, перевернулась для меня с ног на голову, так как я переехал жить и работать в Австралию ?
Кроме того, были у другие знаменательные моменты и достижения. К примеру - сдача OSWE в разгар одноного из редтимов, первая hight severity CVE в продукте с большим количеством звезд, участие в The Standoff с получением медали за 2ое место, огромное количество RCE на проектах, участие в организации OFFZONE2023 в качестве лида APPSEC.ZONE, выступление на локальных и публичных митапах и так далее.

Этот год стал для меня одним из самых продуктивных в моей карьере. Я бы хотел поблагодарить каждого, кто участвовал в развитии этого канала, но теперь стоит затронуть и недалекое будущее и то, что ждет нас в 2024 году. Как вы могли заметить, количество постов сильно снизилось. Это обусловлено тем, что я стараюсь писать о чем-то интересном, а не о чем-то базовом. Более сложные и интересные вещи требуют больше времени на ресерч, что логично.

В настоящий момент я участвую в проведении Red-Team проектов внутри компании, а также занимаюсь исследованием некоторых вещей, которые бы могли помочь в проведении этих самых Red-Team operations. Проблема заключается в том, что большинство из этих ресерчей относится к вещам, говорить о которых я, к сожалению, не могу, так как это своего рода внутренняя кухня компании, что затрудняет создание новых постов. Из-за этого говорить о будущем этого канала крайне сложно. Посты если и будут выходить, то они будут содержать в себе информацию о каких-то супер-специфических вещах и быть непросты к прочтению, что отпугнет некую аудиторию и, соответственно, выходить они станут куда реже, чем было раннее. Будет своего рода twitter что-ли.

И, в конце-концов, хочется поздравить всех с наступающим 2024 годом и пожелать побольше выплат на бб, более крутых чейнов, CVE и, что не менее важно - здоровья. ?
#new_2024_year

hostPID: true и --pid=host
Два параметра, указанных выше приводят к запуску контейнеров в PID-неймспейсе хоста в kubernetes и docker соответственно.
Запуск в PID-неймспейсе хоста позволяет получать доступ ко всем процессам хоста. Но вот какой доступ? Давайте разбираться.

Во-первых, можно делать ps и посмотреть список процессов с параметрами командных строк.

Во-вторых, можно обращаться к файловой системе /proc/PID/ других процессов. Тут неочевидный момент - при доступе к интересным файлам, например к /proc/PID/environ (содержащим весь environment процесса), ОС проверяет ptrace access mode.* Подробно эта проверка описана в конце мана ptrace .

Выпишу основное.
Есть два уровня доступа:
- менее привилегированный PTRACE_MODE_READ
- более привилегированный PTRACE_MODE_ATTACH

Полный список файлов в /proc/PID/ с указанием того какой уровень доступа к ним требуется перечислен в мане proc

Базовая проверка для обоих уровней доступа на уровне ОС делается примерно одинаково, основное:
- наборы UID и GID запрашивающего и целевого процесса должны совпадать
- набор permitted capabilities целевого процесса должен быть подмножеством набора effective capabilities запрашивающего процесса
- наличие у запрашивающего процесса CAP_SYS_PTRACE позволяет обойти указанные выше ограничения

Также в проверке могут участвовать LSM, например apparmor и yama (последний работает только для PTRACE_MODE_ATTACH), но это мы рассмотрим в следующем посте. CAP_SYS_PTRACE тоже рассмотрим отдельно, с ним тоже есть тонкости.

А вот что мы можем делать если у нас нет CAP_SYS_PTRACE? Так вот, немного утрируя мы можем получить доступ уровня PTRACE_MODE_READ во все контейнеры, запущенные с таким же набором capabilities, как и наш, или более узким, а также они должны быть запущены под тем же UID. Но это ведь обычная история в kubernetes/docker, там все контейнеры/поды как правило стартуют с одним и тем же набором capabilities и зачастую от одинакового пользователя (ниже считаем что это root).

Из интересного можно читать /proc/PID/environ, но даже не это самое прикольное. Под PTRACE_MODE_READ также подпадают /proc/PID/root и /proc/PID/cwd. C их помощью мы можем попасть в файловую систему целевого контейнера. И если мы root, то мы в ней можем не только читать но и писать туда! И это без CAP_SYS_PTRACE и с apparmor/yama запущенными по умолчанию!

А значит мы можем:
1) читать SA-токены из других подов /proc/PID/root/var/run/secrets/kubernetes.io/serviceaccount/token
2) попытаться добиться RCE в другом поде путем записи в /etc/ld.so.preload, /root/.ssh/authorized_keys, /etc/crontab и т.д. и т.п.