⚠️ Про переоценённую безопасность кластеров или как вы сами даёте новые вектора атак

Подготовка к PHDays, работа, проекты, личная жизнь, Hades 2 забирают у меня почти всё время. Я начал замечать, что перестал пить воду, потому что забываю. Думаю, к лету будет проще дарить вам не только смех с мемов, но также продолжить заставлять ваш мозг работать.

🤨 Про что сегодня поговорим

Пост старый, ему уже около пары месяцев, но я так его и не опубликовал. Пора бы уже. Но немного теории не помешает, особенно тем, кто готовится к собесам или хочет вспомнить что-то. Пост будет немного депрессивный или злой, я сам не понял.

❕ Сначала про eBPF

eBPF (extended Berkeley Packet Filter) — это технология в ядре Linux, которая позволяет выполнять безопасный, изолированный код внутри ядра, не изменяя его исходники или загружая модули. eBPF изначально был разработан для фильтрации пакетов, но его возможности значительно расширились со временем и теперь он умеет в:

➖ Сетевой мониторинг и фильтрацию;
➖ Трассировку и отладку системы;
➖ Мониторинг приложений;
➖ Предотвращение атак.

eBPF позволяет писать программы, которые могут перехватывать и анализировать события в ядре Linux, что делает его идеальным инструментом для задач безопасности и мониторинга (либо слежки, но про это мы тут не говорим🥺). Некая грань между стандартными безопасниками и соковцами (может пора их начать записывать в отдельную категорию? 👮‍♂️)

Знакомьтесь, ваш новый папа — Tetragon

💻 Ссылка — ТЫК

Инструмент использующий eBPF для обеспечения безопасности и мониторинга в реальном времени за контейнеризованными приложениями.

Да, не зря упоминал про eBPF 🤗

😜 Основные возможности Tetragon

Всё то, что и так все знают, но немного больше.

💩 Мониторинг событий в реальном времени

💩 Политики безопасности
"Ага, поверил... Ну и бредятина!" — Шрек понимает меня. А теперь о том, как его использовать так, чтобы было интересно.

✅ Блокируем легитимные вызовы

Каспер, сорри, но ты будешь примером плохого использования. тоже самое можете сделать со всеми ненужными процессами:

apiVersion: cilium.io/v2
kind: TetragonPolicy
metadata:
  name: block-kaspersky
spec:
  policyName: "Block Kaspersky Processes"
  policy: |
    trace:
      - syscalls:
          matchArgs:
            - name: "execve"
              args:
                - index: 0
                  value: "/opt/kaspersky/kesl/bin/kesl"
          action: "deny"
      - syscalls:
          matchArgs:
            - name: "execve"
              args:
                - index: 0
                  value: "/opt/kaspersky/kesl/bin/kesl-supervisor"
          action: "deny"

😑 А что ещё можем?
Места в посте нет, но вы держитесь. Я могу отдельно написать и выложить правила.

➖ Обход существующих политик безопасности (политика позволяющая обойти политики)
➖ Саботаж системных процессов (может кто-то помнит мультик "Валиант" — теперь мы та самая мышь)
➖ Кража учетных данных (ssh делает бррррр)

💬 Итоги поста

Ну вот, вы только что узнали о Tetragon — инструменте, который, вероятно, знает о вашем кластере больше, чем вы сами (а может и не только о кластере, но и о вас 😈). Да, потому что мониторинг в реальном времени, отслеживание системных вызовов и контроль сетевых соединений — это, конечно, то, о чем вы всегда мечтали. Забудьте о спокойных ночах и расслабленных выходных, теперь вы будете наслаждаться бесконечными отчетами и политиками безопасности. Впрочем, что ещё делать людям из SOC-а.

А если серьезно, то давайте посмотрим правде в глаза: вам придется разбираться с кучей конфигураций и политик, чтобы получить ту самую защиту, которую обещают разработчики.

Думайте, прежде чем ставить)
#devsecops #blueteam #redteam #бредниавтора

Abusing GitLab Runners
#gitlab #devsecops

Не самая новая техника hijack'а других gitlab runner'ов, но тем не менее эффективная, если вы получаете доступ к gitlab и/или токен раннера. В этой статье автор хотел бы объяснить, что такое Runners, как они работают и как вы можете использовать их во время пентестов.

➡️Research

➡️Github PoC

Использование:

usage: hijack-runner.py [-h] [--target TARGET] [--register REGISTER] [--attack ATTACK] [--tag TAG]
                        [--clone]

Abuse GitLab Runners

optional arguments:
  -h, --help           show this help message and exit
  --target TARGET      The GitLab instance to target
  --register REGISTER  Register a token
  --attack ATTACK      Use Runner token to steal data
  --tag TAG            Taglist separated with commas
  --clone              Will clone the repo locally

🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

Ну что, готовы к крутой лекции по безопасности k8s от отца контейнеров @aleksey0xffd? OWASP k8s TOP 10, RBAC, security context для pod и контейнеров в нем, аутентификация и авторизация, безопасная конфигурация workloads, секреты, сегментация сети внутри кубера и многое другое.

В общем, вся база всего за час, а не за 10, как у практически всех площадок онлайн-образования. Смотрим, впитываем, образовываемся – ютуб и рутуб.

#BaseSecurity #DevSecOps

🧠 Твой Пакет Знаний

Харденинг

Есть такая область безопасности и ДевОпса под названием харденинг. Если коротко, то с помощью этого подхода можно обеспечить дополнительную безопасность чего-угодно (сервера, сети, БД, ОС) за счет уменьшения поверхности атаки = заколачивания окон досками.

Делается это обычно при помощи достаточно сурового затягивания болтов через конфигурации, отключения избыточных функций и доступов. Вещь в работе и на собесах нужная, так что забираем.

⚙ Целый сборник харденинг-годноты – раз и два
⚙ Чеклисты по харденингу всего и вся – ссылка

#BaseSecurity #DevSecOps #Network

🧠 Твой Пакет Знаний | 🛍 Другие каналы

Настало время уязвимостей

Что-то модно (как уязвимости Next.js и GraphQL), что-то вышло из моды (как уязвимости для Adobe Flash Player), а что-то вечно (привет, Битрикс).

Как вы уже догадались, сегодня мы поговорим про уязвимости. А точнее про то, как безопасники вообще следят за их трендами и тем, что сейчас их всего скопления CVE стоит их внимания, а что из этого уже можно забыть.

Человечество уже давно подумало об этой проблеме, ведь новые уязвимости появляются каждый день, а актуальными они остаются разные периоды времени. Часть из них охватывает большие ландшафты (как было с log4j), а некоторые, хоть и критичные, не так страшны, из-за того, что уязвимые элементы не так распространены.

Так вот, существуют специализированные платформы или сервисы, которые собирают, анализируют и предоставляют информацию о наиболее актуальных и опасных уязвимостях в сфере кибербезопасности. И да, к ним также подключаются решения класса TI, чтобы мониторить обстановку.

Ну а вот и эти платформы-агрегаторы 👇

📂 CVE Crowd – один из самых популярных сервисов

📂 CVE Shield – один из самых старых агрегаторов

📂 Vulmon Vulnerability Trends – хороший агрегатор с историей за прошлые дни

📂 CVE Trends – топ10 обсуждаемых в интернетах уязвимостей за сутки

📂 Vulners – целый портал кибербезопасных инфоповодов, включая эксплойты, безопасность AI, BugBounty и прочее

Их на самом деле намного больше, но половина из этих сервисов дублирует друг друга, да и я не уверен, что стоит пользоваться всеми. Что-то себе по вкусу вы из этого списка найти точно сможете.

#BaseSecurity #AppSec #DevSecOps #Pentest

🧠 Твой Пакет Знаний | 🛍 Другие каналы

🛠IngressNightmare или как снова что-то нашли

Всем привет, и да, я снова тут с постом, который никто особо не ждал, ведь выше есть пост, но пройти мимо такой темы я не смог. Сегодня расскажу более подробно про свежий и крайне неприятный инцидент в Kubernetes-мире.

❓Что стряслось и почему все в панике

Короче, ребята из Wiz недавно нашли серию критических уязвимостей в контроллере Ingress-NGINX для Kubernetes. Назвали это всё красиво и драматично – IngressNightmare. И поверьте, название выбрали неспроста: если коротко, то это пять CVE, из-за которых атакующий может спокойно выполнить код на ingress-контроллере и буквально угнать весь кластер со всеми секретами. И самое весёлое, что атакующему даже не нужны учётные записи или пароли, хватит одного кривого HTTP-запроса.

🔍 Технические подробности для тех, кто любит копаться в кишках

Суть этих уязвимостей кроется в недостаточной проверке входящих данных, которые разработчики Ingress-NGINX радостно вставляли напрямую в конфиги NGINX. Из-за этого через безобидные, казалось бы, аннотации (auth-url, auth-tls-match-cn, mirror-target) можно было внедрить произвольные директивы. Ну, например, какую-нибудь такую прелесть:

ssl_engine /tmp/malicious.so;

Именно это использовали исследователи Wiz в своём PoC. Ты просто отправляешь HTTP-запрос с большим телом, NGINX сохраняет это тело как временный файл, а потом через специальный AdmissionReview-запрос (без аутентификации!) загружает твою вредоносную .so библиотеку. И всё, поздравляю, теперь ты внутри контейнера с контроллером. Дальше читаешь секреты, токены и вообще делаешь, что хочешь.

‼️ Кто в опасности и как проверить себя любимого

Если ваша версия Ingress-NGINX ниже v1.12.1 (а ещё 1.11.5 и 1.10.7), то у вас серьёзные проблемы:
🔵 Узнать текущую версию можно через:

kubectl -n ingress-nginx get deploy ingress-nginx-controller -o=jsonpath='{.spec.template.spec.containers[0].image}'

🔵 Или через GitLab, найдя в манифестах YAML или Helm-чартах строку:

image: ingress-nginx/controller:v1.12.0

❔ Как с этим жить дальше

Что делать, если вы попали в этот клуб неудачников с уязвимой версией:

1. Срочно обновляйтесь до v1.12.1;

2. Пока не обновились, отключите admission-контроллер (controller.admissionWebhooks.enabled=false);

3. Ограничьте доступ к admission webhook с помощью Network Policy. Только API-сервер должен туда стучаться;

4. Просмотрите audit-логи Kubernetes и ищите подозрительные Ingress’ы с странными аннотациями.

Если вы не можете обновиться сразу (а кто из нас может?), хотя бы проверьте, что webhook не светит в интернет. В Wiz уже подсчитали, что около 6500 кластеров с открытым admission webhook доступны снаружи. Возможно, среди них есть и ваш.

👀 Личное мнение и мораль сей басни

Вот казалось бы, мелочь – не проверить пару строк кода, не закрыть пару портов, но в итоге получаешь катастрофу, достойную отдельного поста в моём канале. В очередной раз понимаешь, насколько всё хрупко и насколько важна роль команд AppSec и DevSecOps в крупных компаниях. В общем, проверьте свои кластеры, обновитесь и берегите нервы, они вам ещё пригодятся.

Спасибо, что дочитали мой очередной маленький монолог. Обещаю, скоро вернусь с чем-нибудь менее трагичным.

#devsecops #appsec

Сегодня у нас чтиво о защите периметра сети - Архитектура защищённости сетей.

В данной книге разбираются такие типы СЗИ как NGFW, Email Security, WAF и Sandbox. Список самих обозреваемых решений довольно большой, начиная от циски и майкрософта, заканчивая нашими решениями от PT, Usergate и т.д.

Прочитав эту книгу вы сможете понять, цель каждого из описанных СЗИ и в какую часть сети их нужно внедрять.

#AppSec #DevSecOps #SecArch

🧠 Пакет Знаний | 👨‍🏫 Менторство
📂 Другие каналы

Делимся большой картой с сертификатами в ИБ.

Карта разделена на три уровня сложности (Начинающий, Средний, Эксперт) и на большое количество ролей, начиная от ред/блю тим, заканчивая безопасностью сетей и архитектуры.

Сами сертификаты можно фильтровать по стоимости, вендорам и специальностям. И ещё тут есть фича сравнения сертификатов по ключевым параметрам.

Цель на жизнь поставлена, можно начинать собирать.

#AppSec #Pentest #DevSecOps #SecArch #SOC

🧠 Пакет Знаний | 👨‍🏫 Менторство
📂 Другие каналы

PromptPwnd: Как AI-агенты взламывают CI/CD пайплайны
#appsec #llm #prompt #ai #agent #cicd #pipeline #devsecops

Исследователи из Aikido Security продемонстрировали новый класс атак PromptPwnd, который использует уязвимости prompt injection в AI-агентах, интегрированных в CI/CD. Это первая подтвержденная демонстрация компрометации CI/CD в реальных условиях через AI, уже затронувшая как минимум пять компаний из списка Fortune 500.

➡️Механика атаки: Просто, но эффективно

Атака эксплуатирует предсказуемый рабочий процесс: недоверенные данные, такие как заголовки issue или описания pull request, напрямую вставляются в промпт, который обрабатывает AI-агент. Манипулируя этим текстом, злоумышленник может заставить агента выполнить несанкционированные действия. В PoC-атаке на Google Gemini CLI, вредоносные инструкции, спрятанные в issue, заставили агента слить секретные ключи (API keys, токены доступа) прямо в публичный тред.

➡️Три кита уязвимости

PromptPwnd становится возможным при совпадении трех фундаментальных недостатков безопасности:

1. Прямое внедрение недоверенных данных: Пользовательский контент без санации попадает в AI-промпты.
2. Слепое доверие к AI: Вывод AI-модели ошибочно считается доверенным и исполняется в CI/CD.
3. Избыточные привилегии: AI-агентам предоставляются высокопривилегированные токены и доступ к инструментам, включая выполнение shell-команд.

➡️Почему это критично?

• Supply Chain Risk: Атака компрометирует не просто отдельное приложение, а весь пайплайн разработки, открывая возможность для внедрения бэкдоров в код.
• Низкий порог входа: Не требуется сложных эксплойтов — достаточно грамотно составленного текста.
• Широкая поверхность атаки: Любой, кто может создать issue или pull request, потенциально может инициировать атаку.

➡️Как защититься?

Защита от PromptPwnd требует многоуровневого подхода, основанного на принципе Zero Trust по отношению к AI-агентам:

• Ограничивайте права: Предоставляйте агентам минимально необходимые привилегии. Отключайте выполнение shell-команд и модификацию репозиториев, если это не является абсолютно необходимым.
• Контролируйте триггеры: Ограничьте запуск AI-воркфлоу только для доверенных пользователей, избегая автоматического запуска от публичных issue.
• Валидируйте вводы и выводы: Тщательно очищайте все недоверенные данные перед передачей в AI и валидируйте вывод модели перед исполнением.
• Используйте короткоживущие токены: Минимизируйте риски утечки, используя токены с ограниченным сроком действия и узкой областью видимости.
• Внедряйте аудит и мониторинг: Регулярно проверяйте активность AI-агентов, их права и конфигурации.

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч