
GromHacks Labs -- Списки полезных нагрузок, которые они не хотят, чтобы у вас были. 1 324 инъекционных зонда, отправленных с материнского корабля, чтобы обнаружить, что поддается инъекции в 20 классах уязвимостей. Мы не эксплуатируем, мы просто стучимся в дверь и смотрим, кто ответит. Каждая нагрузка тестируется на реальных парсерах, потому что пришельцы требуют доказательств. Не доверяй никакому вводу. Подвергай всё сомнению!
Нашли полезную нагрузку, которая не работает? Пожалуйста, откройте задачу с указанием полезной нагрузки, контекста цели и ожидаемого результата. Запросы на исправления или новые полезные нагрузки всегда приветствуются.
Исследование продолжается. Этот проект находится в активной разработке и будет регулярно обновляться новыми полезными нагрузками, классами уязвимостей и улучшениями валидации.
Отказ от ответственности: Эти полезные нагрузки предоставляются только для авторизованного тестирования безопасности, обучения и исследовательских целей. Авторы не несут ответственности за любое неправомерное использование или последующие эффекты. Используйте полностью на свой страх и риск. Используя этот проект, вы принимаете на себя полную ответственность за свои действия.
Лицензия: MIT - см. LICENSE
1,353 проверенных инъекционных полезных нагрузок, охватывающих 20 классов уязвимостей, 31 фреймворк десериализации и 14 шаблонизаторов. Каждая полезная нагрузка дает обнаруживаемый сигнал. Никаких теоретических нагрузок.
Валидация: 1,353 протестировано / 1,353 сработало / 0 сбоев / 0 пропущено на 35 стендах Docker. Строгая валидация доказывает фактическую эксплуатацию (вычисления на сервере, реальные ошибки парсера, измеренные временные задержки, внеполосные обратные вызовы из целевых контейнеров) -- не сопоставление строк.
Большинство общедоступных списков полезных нагрузок организованы по типу уязвимости: один список для SQL-инъекций, другой для XSS, третий для инъекций команд и так далее. Тестер выбирает список, который, по его мнению, соответствует цели, загружает его в инструмент-интрудер и запускает против параметра. Если он ошибается в классе уязвимости, все сканирование не дает результатов. Если бэкенд использует необычную базу данных, нестандартный шаблонизатор или язык, который не учтен в списке, полезные нагрузки молча не срабатывают. Тестер переходит дальше, считая параметр чистым.
У этого подхода есть две фундаментальные проблемы. Во-первых, он требует, чтобы тестер знал, какая уязвимость существует, до того, как он ее найдет. Во-вторых, большинство используемых полезных нагрузок являются теоретическими -- копируются между проектами и блогами, никогда не тестируясь на реальном парсере. Они выглядят правильно. Возможно, они даже синтаксически корректны. Но они не вызывают обнаруживаемого ответа от цели.
Этот проект использует другой подход. Основной единицей работы является полиглот -- одна строка полезной нагрузки, спроектированная так, чтобы быть валидной (или значимо невалидной) одновременно в как можно большем количестве контекстов инъекций. Один полиглот вырывается из одинарных кавычек, двойных кавычек, круглых скобок, блочных комментариев, атрибутов HTML, разделителей шаблонов и контекстов обратных кавычек одновременно. Вместо того чтобы знать, какая уязвимость существует, тестер отправляет полиглоты на каждый параметр и наблюдает за сигналами.
Каждая полезная нагрузка в этой коллекции построена вокруг столпов обнаружения -- наблюдаемых ответов, которые подтверждают наличие уязвимости без необходимости доступа к журналам сервера, исходному коду или файловой системе:
7*191, которое вычисляется в 1337. Если это число появляется в ответе, а полезная нагрузка отправляла только 7*191 (не литерал 1337), то бэкенд вычислил выражение -- доказательство выполнения кода.Если полезная нагрузка не производит хотя бы один из этих сигналов при тестировании в своем целевом контексте, ей не место в списке. Каждая из 1,353 полезных нагрузок здесь была проверена на специально созданных тестовых стендах Docker со строгим доказательством эксплуатации. Никаких теоретических.
Традиционные внеполосные нагрузки и нагрузки для временных задержек полагаются на команды оболочки: curl, nslookup, ping, sleep. Они постоянно ломаются. Они зависят от целевой ОС, доступного PATH, того, какая оболочка интерпретирует команду, и есть ли у процесса разрешение на создание подпроцессов. curl-базированная внеполосная нагрузка, работающая на Ubuntu, не работает на Alpine (нет curl), не работает на Windows (нет curl) и не работает внутри ограниченного контейнера (нет выполнения исходящих процессов).
Этот проект заменяет команды оболочки на встроенные функции языка везде, где это возможно. Полезные нагрузки Python используют urllib.request.urlopen() и time.sleep(). Полезные нагрузки Java используют java.net.URL.openStream() и Thread.sleep(). Ruby использует Net::HTTP.get() и Kernel.sleep. PHP использует file_get_contents() и sleep(). Эти функции существуют в каждой стандартной установке соответствующего языка -- нет поиска PATH, нет подпроцесса, нет зависимости от ОС.
Там, где даже импорты стандартной библиотеки могут быть заблокированы (песочница eval, ограниченный exec), полезные нагрузки отступают к альтернативам без импорта: циклы загрузки ЦП для времени (sum(range(500000000)) в Python, Atomics.wait() в Node) и прямые сокетные соединения для OOB (__import__('socket').create_connection(), fsockopen(), TCPSocket.new()).
Не все может быть полиглотом. Шаблонизаторы используют принципиально несовместимый синтаксис -- {{}} в Jinja2 ничего не значит для <%= %> ERB, и ни один не парсится как ${} Freemarker). Форматы десериализации являются бинарными или структурированными данными, специфичными для одного фреймворка. Для этих категорий проект использует нагрузки для каждого движка, организованные в рамках той же системы столпов обнаружения, охватывая 14 шаблонизаторов и 31 фреймворк десериализации на 7 языках.
Результатом является единый корпус, в котором полиглоты обрабатывают контексты, которые они могут (SQLi, инъекции команд ОС, XSS, инъекции кода), а специально созданные нагрузки для каждого движка обрабатывают остальное, все проверено, все генерирует обнаруживаемые сигналы, все готово для построчного ввода в инструменты инъекций.
83 полезных нагрузки, покрывающие все 35 тестовых стендов, все 55+ конечных точек и все 4 столпа обнаружения для каждой категории. Валидировано: 83 СРАБОТАЛО / 0 НЕ СРАБОТАЛО / 0 ПРОПУЩЕНО.
Каждая категория инъекций получает покрытие по ошибке, математике, времени и OOB, где это архитектурно возможно. Фреймворки десериализации, поддерживающие выполнение кода (Pickle, PyYAML, jsonpickle, node-serialize, XMLDecoder, .NET Json.NET), получают полное многопиллярное покрытие. Фреймворки, ограниченные зондированием (PHP unserialize, Ruby Marshal, SnakeYAML и т.д.), получают обнаружение на основе ошибок. Применяйте это к каждому параметру, прежде чем переключаться на полные списки категорий для углубленного анализа.