Небезопасная десериализация = удалённое выполнение кода

Commit Это открыло бэкдор

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

Что такое десериализация в коде, почему она опасна и где она скрывается

Что такое десериализация с точки зрения разработчика? Это процесс преобразования структурированных данных, JSON, XML, двоичных форматов или сериализованных объектов, специфичных для конкретного языка, в объекты в памяти.

Сам по себе, десериализация безвреден и распространен, например:

Java: Чтение объектов с ОбъектИнпутСтрим
Питон: Загрузка данных с помощью pickle.load
Node.js: Анализ JSON с помощью JSON.parse

Риск возникает при десериализации ненадежных данных без проверки. Злоумышленник может создать входные данные, которые запускают цепочку гаджетов, используя существующие пути кода непреднамеренно, что может привести к удалённому выполнению кода.

небезопасный десериализация часто встречается в:

Пакеты с открытым исходным кодом с небезопасными значениями по умолчанию
Пользовательский код который предполагает, что сериализованный ввод заслуживает доверия
Сторонние API возвращают сериализованные объекты без проверки
Создание артефактов , таких как:
- Java .сер файлы, содержащие предварительно сериализованные объекты.
- Питон .pkl файлы моделей в рабочих процессах машинного обучения.
- Сериализованные объекты конфигурации, встроенные в образы Docker или контейнеры развертывания

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

Эти файлы могут быть помещены в репозиторий и автоматически загружены во время тестов или развертываний, что может привести к небезопасным десериализация in CI/CD pipelineеще до того, как код попадет в производство.

От небезопасной десериализации к удаленному выполнению кода: путь атаки

Цепочка эксплуатации небезопасной десериализации часто следует одному из следующих шаблонов:

В приложение попадают ненадежные входные данные.
Небезопасная десериализация воссоздает объекты без ограничений.
Цепочка гаджетов запускает существующие функции непреднамеренными способами.
Злоумышленник повышает привилегии и осуществляет удаленное выполнение кода.

Варианты:

Цепочки гаджетов Java используют старые библиотеки, такие как Apache Commons.
Питон .pkl загрузка модели со встроенными вредоносными объектами.
Парсинг JSON в Node.js с помощью eval () или динамический импорт.

Поток:

Untrusted Input → Deserialization → Gadget Chain → Remote Code Execution

Как обнаружить небезопасную десериализацию перед слиянием

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

Статическое тестирование безопасности приложений (SAST):
- Настройте сканеры для обнаружения рискованных API, таких как ОбъектИнпутСтрим, pickle.load и YAML.load без безопасного погрузчика.
- Сканировать исходный код и артефакты сборки/тестирования на наличие небезопасных элементов. десериализация узоры.
- Отображать результаты непосредственно в pull requests чтобы разработчики могли решить их перед слиянием.
CI/CD интеграцию:

Пример рабочего процесса:

sql

Commit → SAST scan → PR alert → Fix before merge

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

Модульные тесты с имитацией вредоносных входных данных:
- Создавай безвредные, контролируемые полезные нагрузки которые имитируют обычные сериализованные объекты атаки.
- Проверьте, как приложение обрабатывает их: оно должно отклонять, очищать или регистрировать входные данные, а не обрабатывать их вслепую.
- Включить эти тесты в автоматизированный pipeline поэтому они запускаются при каждом PR, выявляя небезопасное поведение десериализации на ранней стадии.
- Убедитесь, что тестовые полезные данные являются неисполняемыми и безопасны для хранения в репозитории, сосредоточившись исключительно на логике обнаружения.

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

Стратегии предотвращения для разработчиков: как предотвратить превращение десериализации в удаленное выполнение кода

Границы доверия: Десериализацию следует выполнять только из аутентифицированных, проверенных источников.
Безопасные API:
- Java: безопасные библиотеки с проверкой.
- Python: использование json.loads () за pickle.loads() где возможно.
- Node.js: избегать eval () или динамическое выполнение кода.
Разрешенные списки и схемы: Ограничить допустимые типы объектов. Обеспечить применение схем JSON.
Гигиена зависимости: Отслеживайте CVE, в которых упоминается десериализация или удаленное выполнение кода.
Кодовые обзоры: Добавлять десериализация проверки безопасности по шаблонам PR-обзоров.

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

Примеры шаблонов обнаружения на разных языках (Безопасный псевдокод)

Все приведенные ниже примеры представляют собой очищенный псевдокод, демонстрирующий шаблоны обнаружения, а не работающие эксплойты:

Java – обнаружение небезопасного использования API:

java
// BAD: Accepting untrusted input without validation
ObjectInputStream in = new ObjectInputStream(userInputStream);
Object obj = in.readObject(); // Unsafe - no class type checks

// GOOD: Validate allowed classes before processing
if (allowedClasses.contains(obj.getClass().getName())) {
    process(obj); // Safe processing of approved classes
}

Python – Как избежать небезопасной десериализации:

python
import pickle

# BAD: Loading untrusted serialized data directly
data = pickle.loads(untrusted_input)  # Unsafe - arbitrary object execution risk

# GOOD: Use JSON with schema validation
import json
data = json.loads(untrusted_input)  # Safe when validated against schema

Node.js – Предотвращение динамического выполнения кода:

javascript
// BAD: Executing code from parsed data
let obj = JSON.parse(untrustedInput);
eval(obj.code); // Unsafe - allows arbitrary code execution

// GOOD: Use fixed logic without dynamic execution
let safeObj = JSON.parse(untrustedInput);
process(safeObj); // Handle only expected properties and values

Автоматизация обнаружения в DevSecOps Pipelines: Отслеживание десериализации до того, как она достигнет стадии производства

Автоматизация обнаружения небезопасной десериализации обеспечивает уязвимости обнаруживаются и устраняются прежде чем они приведут к удаленному выполнению кода в производстве.

Pipeline Сканирование

Run SAST на исходном коде, файлах конфигурации и артефактах сборки на каждом этапе commit.
Обнаружить небезопасные шаблоны десериализации как в коде приложения, так и Зависимости.

Проверка артефактов

Сканировать .ser, .pkl, и другие сериализованные файлы на предмет небезопасных шаблонов перед развертыванием или даже запуском тестов.

Pull Request блокирование

Объединение блоков при обнаружении небезопасной десериализации.
Демонстрируйте действенную обратную связь в PR-заявках для ускорения устранения неполадок.

Обеспечение соблюдения модульного тестирования

Включать модульные тесты с имитацией вредоносных входных данных в CI/CD pipeline
Сборки завершаются ошибкой, если приложение обрабатывает небезопасные сериализованные данные вместо того, чтобы отклонять их.

Избежание ложных срабатываний без ослабления правил

Не отключайте правила обнаружения, чтобы «заглушить» оповещения; это может позволить настоящей небезопасной десериализации пройти незамеченной.
Используйте контролируемый белый список (разрешенный список) для известных безопасных шаблонов или зависимостей.
Требовать проверки безопасности перед одобрением записей в белом списке.
Держите белый список под контролем версий и периодически просматривайте его, чтобы убедиться, что все исключения остаются обоснованными и безопасными.

Роль Ксигени

Интегрируется непосредственно в CI/CD pipelineдля сканирования как исходного кода, так и артефактов сборки.
Обнаруживает небезопасные шаблоны десериализации и рискованные зависимости на ранних этапах жизненного цикла.
Поддерживает белый список на основе политик с обязательной проверкой безопасности, обеспечивая баланс между точностью обнаружения и производительностью труда разработчиков.

Опережение удаленного выполнения кода с помощью безопасной десериализации

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

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

Практическая роль Xygeni в этом процессе:

Сканирование исходного кода: выявляет небезопасные шаблоны десериализации на нескольких языках перед объединением кода.
Анализ артефактов и зависимостей: Обнаруживает опасные сериализованные файлы (.ser, .pkl, встроенная конфигурация) и сторонние компоненты с известными уязвимостями.
Контроль на основе политики: поддерживает контролируемый список разрешенных приложений с проверкой безопасности, гарантируя, что необходимые исключения не представляют реальных рисков.
Отзывы разработчиков в контексте: Отмечает точное место и причину небезопасной десериализации внутри pull requests, что позволяет разработчикам немедленно устранять проблемы и подтверждать меры по их устранению путем повторного сканирования.

Интегрируя такие проверки непосредственно в CI/CD, команды могут обнаружить и исправить небезопасные десериализацию до того, как она успеет перерасти в удаленное выполнение кода в процессе производства.

Как небезопасная десериализация становится удалённым выполнением кода (и как её обнаружить перед слиянием)

Содержание

Обязательно к прочтению посты

Последние интересные публикации