Multipart Parsers: примеры обхода

Всем привет!

Парсеры multipart/form-data не всегда работают корректно и есть разные способы для того, чтобы их обойти.

В статье (~ 27 минут) разбираются некоторые примеры того, как именно это можно сделать.

Начинается статья с того, что Автор описывает стандартные способы проверки (расширение файла, magic bytes, content-type и т.д.) и что такое multipart\form-data.

Дальше – сами техники обхода:
🍭 duplicated name parameter
🍭 breaking the CRLF seuqences
🍭 removing double quotes
🍭 missing closing boundary string
🍭 filename*=utf-8'' in request

Помимо этого, в статье есть информация о том, как можно обходить разные WAF. Каждый пример, приведенный в статье подробно описан, с кодом и пояснениями.

Проверка передаваемых параметров – задача крайне важная и статья может помочь в том, чтобы понять на что обращать внимание и как сделать этот процесс более безопасным.

Использование AI для анализа CVE

Всем привет!

В статье описан опыт NVidia по анализу CVE в контейнеризованных приложениях с использованием AI.

Проблематика известная и понятна: «традиционный подход» -
проанализировать и использовать обновление – на больших масштабах работает не очень хорошо.

Особенно с учетом того, что многие результаты не релевантны: сканер ошибся, уязвимый метод не достижим, не рассматривается контекст (например, используемые меры защиты или окружение, в котором разворачивается ПО).

Если рассматривать процесс управления уязвимостями, как последовательность шагов «Scan», «Investigate», «Decide», «Mitigate» и «Publish», то перед NVidia стояла задача сокращения этапа «Investigate».

На этом этапе как раз и определяется – является ли уязвимость эксплуатируемой или нет, что влияет на следующие шаги процесса и принимаемые решения.

Если кратко, то используется следующий алгоритм:
🍭 Генерируется список действий (проверить наличие уязвимости, наличие JRE и т.д.)
🍭 Каждый элемент списка действий анализируется LLM. При этом используются внешние источники: SBOM-файлы, информация о репозиториях, данные от TI и т.д.
🍭 Завершается все анализом полученных результатов, формирование мнения относительно возможности эксплуатации CVE (в том числе в формате VEX)

Примеры того, как это выглядит можно найти в статье. Кроме того, есть краткое описание процесса по управлению уязвимостями, реализованном в NVidia: от момента помещения нового контейнера в реестр до формирования VEX-файлов.

Плагины и утилиты для Helm

Всем привет!

Helm’a при всем его (не) удобстве не всегда бывает достаточно. Иногда хочется как-то расширить его функционал.

И именно этому посвящена статья – набору плагинов и утилит, которые помогут решить наиболее часто встречающиеся задачи.

Например:
🍭 helm-diff – анализ изменений до их применения
🍭 helm-docs – автоматическая генерация документации для чартов
🍭 trivy – анализ чартов на наличие уязвимостей
🍭 helm-mapkubeapis – анализ устаревших (deprecated) версий API и не только

Для каждого плагина/утилиты Автор кратко описывает назначение, преимущества от использования и ссылки на GitHub Repo.

А чтобы вы добавили/удалили из этого перечня?

Основы Taint Analysis

Всем привет!

SAST это не только «поиск по шаблонам», многие решения включают в себя более сложные механизмы поиска ИБ-дефектов, включая Taint Analysis.

Если упростить, то это нечто вроде анализа «пути жизни данных» - от их передачи в ПО до использования в различных методах.

По ссылке можно прочесть небольшую статью, в которой кратко и просто объясняется, что это такое и как это работает.

Статья содержит разделы:
🍭 Основные концепты: sources, sinks, sanitizers
🍭 Принципы работы Taint Analysis
🍭 Примеры паттернов для уязвимостей (SQLi, XSS, Command Injection, Path Traversal)
🍭 Как писать правила для Taint Analysis

Никакой воды, много примеров и доступных объяснений. Самое «то» для начала погружения в тематику и основы ее работы.

P.S. Помимо описания Taint Analysis на сайте представлен аналогичный материал для Control и Data Flow Analysis.

Alfa CTF: Surfing Edition! 🏄‍♂️

Всем привет!

Alfa CTF – мероприятие от Альфа Банка, в котором можно попробовать новое, испытать себя и прокачаться в кибербезопасности!

Ребята предлагают обширный набор заданий, который включает в себя и безопасную разработку.

Вас ждут:
🍭 Web. Получить доступ к базе сайта, купить товар без денег, скачать файл (доступный только администратору)
🍭 Reversing. Понять алгоритм программы без исходников, обойти проверки в приложении, разобраться в протоколе между приложением и бэкэндом
🍭 Pwn. Переполнение буфера, ошибки при работе с кучей, стеком, перетирание указателей в памяти

Регистрация открыта до 13-ого сентября!

Подробности о сроках, поиске команды, правилах и, конечно же, призах можно найти по ссылке на мероприятие.

P.S. Задания будут разной сложности, опыт в CTF не обязателен, главное – желание!

Netflix и Dependency Confusion

Всем привет!

Зачем смотреть Netflix, когда можно его «сломать»? Примерно такие мысли были у Автора статьи, когда он решил проверить: получится ли использовать атаку Dependency Confusion против IT-гиганта?

Dependency confusion это по сути подмена: вместо «целевой» библиотеки (например, npm илт PyPi) пользователь получает ту, что собрал злоумышленник.

Однако, какую именно библиотеку надо «подменять»? Это можно посмотреть в манифесте (который неоткуда взять) или воспользоваться «доступными средствами». Именно второй путь и выбрал Автор.

Он реализовал следующий алгоритм:
🍭 Запись HAR-файла, в котором были все запросы и ответы веб-сессии
🍭 Анализ полученных данных
🍭 Идентификация скачанных файлов
🍭 Проверка того, что скачанные библиотеки (не) доступны в публичных реестрах, что есть более новые версии и т.д.

Спустя некоторое время Автору повезло и он нашел nf-cl-logger.

«Вряд ли Netflix ходит во вне за пакетами». «А вдруг есть ошибки в настройках ноутбука разработчика или инженера?». Интерес взял верх ☺️

Payload использовался крайне простой – получение обычной информации о рабочей станции. Просто проверка гипотезы. И она была подтверждена. Притом достаточно быстро!

Ну а подробности, как обычно, в статье. Приятного чтения! ☺️

Поиск ИБ-дефектов в исходном коде с использованием LLM

Всем привет!

Команда Semgrep провела небольшое исследование. Они использовали Claude Code и OpenAI Codex для поиска ИБ-дефектов в исходных кодах 11 популярных Python-приложений.

Суммарно было найдено более 400 ИБ-дефектов, которые команда проверила.

Получилось следующее:
🍭 Claude нашел 46 ИБ-дефектов (14% - TPR, 86% - FPR)
🍭 Codex – 21 ИБ-дефект (18% TPR, 82% FPR)
🍭 Лучше всего получалось находить IDOR (Claude) и Path Traversal (Codex)
🍭 Самой большой сложностью был taint-анализ среди нескольких файлов
🍭 И да, нюансы с идемпотентностью никуда не делись. Разные запуски могли давать разные результаты

Детали исследования можно найти в статье (а там много всего интересного).

Из приятного – у Semgrep есть мысли о том, чтобы отдать полученный dataset в «общественное использование» ☺️

KubeGuard: Kubernetes Security Scanner

Всем привет!

Еще-один-open-source-сканер, позволяющий выявлять нарушения в конфигурации ресурсов кластера Kubernetes – KubeGuard.

Он позволяет:
🍭 Производить статический анализ манифестов на наличие ИБ-дефектов
🍭 Сканировать созданные в кластере ресурсы на наличие ИБ-дефектов
🍭 Генерировать отчеты (в формате JSON)
🍭 Автоматизировать работу с использованием REST API

«Из коробки» доступно более 25 правил, включающих, в том числе, проверки на соответствие CIS Benchmark.

Аналитическую информацию можно посмотреть в Grafana. Например, информацию о сканированиях, ИБ-дефектах, потреблении ресурсов KubeGuard’om.

Подробности об установке и настройке можно найти в GitHub-репозитории проекта.

Важно: проект еще очень молодой и не успевший набрать "звезд" от сообщества (первый коммит месяц назад)

Cracking the Vault: как искали и нашли zero-day в HashiCorp Vault

Всем привет! 👋

Команда Cyata обнаружила девять ранее неизвестных zero-day уязвимостей в ядре HashiCorp Vault, некоторые были в коде почти десяток лет. Баги затрагивали как open-source, так и Enterprise версии и уже были исправлены HashiCorp.

Это не memory corruption или race condition, а тонкие логические уязвимости в аутентификации, идентификации и политиках Vault — они подрывают Vault как основу «модели доверия» инфраструктуры. Cyata выявили их вручную, через глубокий анализ логики.

Кратко по находкам:
🎯 Userpass backend:
- CVE-2025-6010: различный ответ при неверном логине → можно узнать, существует ли пользователь
- CVE-2025-6004: изменение регистра (Admin vs admin) сбрасывает счетчик блокировок
- CVE-2025-6011: тайминговая атака через разную обработку несуществующих юзеров
🎯 LDAP backend + MFA:
- CVE-2025-6004 (опять): из-за некорректной нормализации (пробелы, регистр) можно обойти блокировку
- CVE-2025-6003: при username_as_alias=true и MFA по EntityID, MFA может вообще не тригериться
🎯 TOTP MFA — целая цепочка багов:
- Выдаёт разные ошибки по reuse, позволяя узнать, был ли использован код
- Тримминг пробелов отключает защиту one-time-use
- TTL и глобальный кэш позволяют обойти rate-limit через entity-switching или ожидание создав skew window
→ всё это объединено в CVE-2025-6016
🎯 Аутентификация по сертификатам и entity impersonation:
- CVE-2025-6037: в non-CA режиме владелец приватного ключа может подменить CN и аутентифицироваться от имени другой сущности
🎯 Privilege escalation и RCE — самые критичные:
- CVE-2025-5999: позволяет поднять привилегии до root через неверную нормализацию policy
- CVE-2025-6000 — первый публичный RCE в Vault, позволяющий взять систему под полный контроль через каталог плагинов (цепочка из disclosure → запись файла → выставление execute → регистрация плагина)

Статья (≈38 мин) технически глубокая и нацеленная на практику — авторы показывают не только факт находки, но и путь обнаружения через схемы и видео.

10–11 сентября в Москве проходит IT Elements 2025 — крупнейшая конференция об ИТ-инфраструктуре, сетях, кибербезопасности, данных и ИИ. 2000+ участников ежедневно, топовые спикеры и реальные кейсы.

Подготовили для вас подборку выступлений по теме DevSecOps, которые советуем посетить:

Доклад «Keyless commit sign. Как подписывать коммиты без использования секретного ключа?» (Павильон ИБ с 17:00 до 17:30)
СПИКЕР: Саленый Дмитрий, DevSecOps-инженер, Единый ЦУПИС

Доклад «ML-инструменты в безопасности облака» (Павильон ИБ с 16:30 до 17:00)
СПИКЕР: Яньков Павел, Cloud Security Expert, Т-Банк

Круглый стол «Безопасная разработка. От слов к делу» (Зал «Энергия» с 18:00 до 19:00)
МОДЕРАТОР: Антон Конопак, руководитель отдела DevSecOps, «Инфосистемы Джет»
СПИКЕРЫ: Алина Сагирова, TechLead Application Security Business Partner, Альфа-банк
Георгий Старостин, директор дирекции информационной безопасности «Согаз»
Илья Шаров, руководитель центра практик DevSecOps, МТС Web Services
Максим Щедрин, начальник управления тестирования безопасности ГК «Иннотех»

Подробности на сайте конференции.

AspGoat: vulnerable ASP.NET Web App

Всем привет!

В полку «damn vulnerable»-приложений прибыло. Недавно был выпущен проект Asp.Goat – заведомо уязвимое приложение, созданное на базе ASP.NET.

Внутри «все по классике»:
🍭 XSS
🍭 CSRF
🍭 SQLi
🍭 XXE
🍭 LFI
🍭 RCE и не только

Небольшое демо того, как выглядит приложение можно найти в GitHub-репозитории проекта.

Запускается с использованием Docker и сразу доступно для исследования и изучения, альтернативный способ – через dotnet.

P.S. На всякий случай напоминаем, что цель подобных проектов – обучение и только обучение ☺️

Krew — менеджер плагинов kubectl

Всем привет!

Когда-то давно упоминали krew 1, 2, 3. Но так и не рассказали, что это такое. Krew — пакетный менеджер, работает как apt или brew, но для плагинов kubectl.

🎯 Помогает находить, устанавливать и обновлять плагины
🎯 Делает плагины кроссплатформенными и легко управляемыми
🎯 В каталоге более 300 плагинов: от RBAC-аудита до инструментов отладки сети и работы с секретами

Дополнительно можно посмотреть топ 15 kubectl плагинов для security инженеров в 2025 по мнению Sysdig или другие обзоры 1, 2

Однако стоит помнить о рисках безопасности:
Исследование Trend Micro отмечает, что «любой желающий может разработать свой kubectl-плагин и опубликовать его через Krew. При этом нет никакой проверки безопасности»

Используете krew в работе?

Secure Vibe Coding Guide

Всем привет!

Vibe Coding стал уже чем-то обыденным и все больше и больше людей его используют и создают ПО «совместно» с LLM.

И где-где, а вот тут безопасность точно нужна. В соответствии с исследованием, около 40% генерируемого кода не является безопасным.

В статье Автор рассматривает check list, который, по его мнению, может быть полезен при обеспечении ИБ для Vibe Coding.

Например:
🍭 Vibe Coding Security Fundamentals
🍭 Application Security и API Security-практики
🍭 AI Specific Risks
🍭 Secure Vibe Coding Prompts и не только

Для каждого раздела приводятся общие рекомендации и небольшие уточнения по ним.

Чего-то сверх детального вы не найдете, но «общий взгляд» на вопрос получился достаточно интересный.

Погружение в Kubernetes Security Context

Всем привет!

Kubernetes предлагает разные возможности, которые можно использовать для повышения степени защищенности кластера.

Одной из таких возможностей является Security Context. Если вы еще не знакомы с тем, что это такое и зачем оно нужно, то эта статья может вам подойти.

Автор разбирает:
🍭 Что это такое, какие бывают и в чем между ними разница
🍭 Pod-Level Security Context
🍭 Container-Level Security Context
🍭 Различия между Pod-Level и Container-Level
🍭 Рекомендации по использованию и не только

Для каждого отдельно взятого Security Context приводится описание, сценарии использования и небольшой демонстрационный пример.

То, что надо для первичного ознакомления и погружения в тематику 😊

AppSec и реагирование на инциденты ИБ

Всем привет!

Недавно на Tryhackme появилась новая комната, которая объединяет в себе безопасность приложений и реагирование на инциденты ИБ.

«Комната» состоит из 5 основных частей, если не считать Introduction и Conclusion.

Участников ожидает:
🍭 AppSec IR Fundamentals
🍭 Preparing for Application Incidents
🍭 Responding to an Application Incident
🍭 Remediation and Recovery
🍭 Practical

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

«Комната» рассчитана на 60 минут. Удачи! 😊

Kubernetes Copilot

Всем привет!

Еще один пример использования LLM при работе с Kubernetes – небольшая утилита, получившая название Kubernetes Copilot.

Для работы потребуется kubectl, Trivy (об этом чуть позже) и, конечно же, API-ключ для взаимодействия с LLM. На текущий момент поддерживается OpenAI, Gemini и Ollama.

Kubernetes Copilot позволяет:
🍭 Анализировать проблемы, возникающие с определенным ресурсом
🍭 Проводить аудит безопасности выбранного ресурса (как раз тут и используется Trivy)
🍭 Выполнять команды, получаемые из prompt
🍭 Генерировать манифесты Kubernetes и не только

Примеры команд можно найти в GitHub Repo проекта. Все очень минималистично и просто.

Единственное, чего не хватает – примеров результатов работы Kubernetes Copilot.

Надо ли переосмысливать подход к Vulnerability Management?

Всем привет

Процесс управления уязвимостями, если очень сильно упростить, сводится к тому, чтобы найти некую «CVE» и устранить ее путем обновления версии уязвимого компонента.

Да, очень и очень упрощенный сценарий (как поиска, так и устранения уязвимости), но для сегодняшнего поста подойдет.

Как правило, есть некое «окно», в котором отсутствует exploit, что делает уязвимость не такой опасной и дает больше времени на ее устранение.

А что, если… AI научится генерировать exploit для разных CVE за считанные минуты? Именно этому и посвящена статья.

Что сделали Авторы:
🍭 Взяли модель qwen3:8b, впоследствии - openai-oss:20b
🍭 Начали собирать информацию о «CVE» (git repo проекта, уязвимые версии, версии без уязвимости, описание «CVE» и т.д.)
🍭 Собранная информация использовалась в prompts, целью которых было найти уязвимый код и дать детальное описание уязвимости
🍭 Генерация exploit! Но не просто «пример кода», а PoC и уязвимое приложение, на котором он был протестирован

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

Получается, что надо переосмыслить подход к управлению уязвимостями? Что практика «обнаружить и обновить» перестанет работать со временем? Усилить контроль среды исполнения, чтобы даже при наличии CVE эксплуатировать ее было невозможно? …

Что вы думаете по этому поводу?

Advanced GitHub Security Best Practices

Всем привет!

Wiz не остановить! На этот раз команда подготовила небольшой cheatsheet (~ 13 страниц), посвященный вопросам безопасности GitHub.

Материал покрывает такие темы, как:
🍭 Enforce Robust Authentication
🍭 Safeguarding GitHub Organizations
🍭 Safeguarding GitHub Repositories
🍭 Strengthen Security with GitHub Actions

Для каждого раздела приводятся рекомендации о том, как и что можно настроить. Включая практически «пошаговые инструкции» и сриншоты.

Помимо этого, есть «Actionable Tips» - некий набор лучший практик и советов, о том, на что стоит обратить внимание.

Коротко, по делу и без воды. То, что надо!

Runtime анализ с JAR Inspector

Всем привет!

«Используется ли артефакт, содержащий уязвимости, в промышленной среде?» - именно этот вопрос побудил Автора создать JAR Inspector. А еще Log4Shell, куда уж без него ☺️

Идея достаточно простая: создать решение, которое анализирует JVM, получает перечень всех загруженных JAR и подсказывает, какие из них используются, а какие – нет.

Результатом стал JAR Inspector, который:
🍭 Предоставляет информацию о JAR-файлах в режиме реального времени
🍭 Отображает все приложения и их зависимости (включая транзитивные) в едином окне
🍭 Показывает информацию о том, что загружено и что используется
🍭 Архитектура минималистична: небольшой агент, который получает информацию о JAR, HTTP-сервер и Web UI, который отображает информацию.

Запускается, в том числе, и через Docker, если хочется попробовать у себя.

Больше информации можно найти в статье и в GitHub-репозитории проекта.

Использование Canary Tokens: опыт Grafana Labs

Всем привет!

Canary Tokens – некоторая «обманка», которая выглядит, как легитимный API-ключ, URL, файл или еще что-то.

Его задача – максимально рано оповестить ИБ-команду о том, что что-то идет не так.

Например, если злоумышленник пытается проверить «только что найденный API-ключ (который является Canary Token)», то об этом сразу должна узнать ИБ-команда.

В статье рассказывается о том, как этот подход использует команда Grafana Labs и как он помог им в идентификации реальной атаки, произошедшей в мае 2025.

Статья содержит информацию:
🍭 Что такое Canary Tokens
🍭 Инфраструктура Grafana Labs по работе с Canary Tokens
🍭 Жизненный цикл Canary Tokens
🍭 Общее описание стратегии использования Canary Tokens и не только

В результате получилась отличная статья, которая наглядно показывает подход и выгоду от использования Canary Tokens.

А применяете ли вы их у себя?

Погружение в Kubernetes Services

Всем привет!

Services – одна из основных сущностей Kubernetes, которая «нужна» как ИТ, так и ИБ-специалистам.

Если вы искали что-то, что поможет лучше понять их «устройства», отличия, ключевые принципы и т.д., то эта статья может быть вам полезна.

В ней Авторы рассматривают:
🍭 Общие концепты Services
🍭 Типы Services (ClusterIP, NodePort, LoadBalancer и т.д.)
🍭 Основы Service Discovery
🍭 Работа с Services, их настройка, поиск проблем и т.д.

Примеры, конфигурации, пояснения – все это есть в статье. Хороший обзорный материал «для начала».

Рекомендуем!