🎆 Тригерим alert без использования круглых скобок

WAF фильтрует скобки? Вот как это обойти 👆

onerror=alert назначает alert глобальным обработчиком ошибок, а затем throw 1 выбрасывает ошибку. Эта ошибка перехватывается обработчиком onerror… которым и является alert!

Таким образом, alert(1) срабатывает без использования скобок 😎

⤴️ Моделируйте, прежде чем хантить

1️⃣ Начните с вопроса: какие данные для компании самые важные? Именно они и будут направлять ваше тестирование и моделирование угроз.

2️⃣ Разделите приложение на фронт, middleware и бэк. Определите JS-фреймворки (например, Next.js), где хранится логика и то, как технически реализована аутентификация. Соберите максимум информации о стеке.

3️⃣ Не тестируйте эндпоинты вслепую. Наблюдайте за процессом входа, переадресациями, поведением cookie, жизненным циклом токенов и процессом создания сессий. Моделирование того, как каждое действие проходит через стек, дает идеи для эксплуатации уязвимостей.

4️⃣ Обратите внимание на такие вещи, как кэширование контента, маршрутизация виртуальных хостов, API gateways и балансировщики нагрузки. Эти слои часто неправильно настроены, особенно при передаче запросов между внутренними сервисами.

5️⃣ Отдельные функции редко бывают опасны сами по себе. Посмотрите, как могут взаимодействовать два обычных флоу, например гость-оплата + создание аккаунта. Именно здесь скрываются логические ошибки. Сочетайте это с особенностями используемого технологического стека, чтобы предсказать баги.

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

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

💜ИИ-функциональность нередко использует 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