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

Команда Commit Це відкрило задні двері

Нова функція була об'єднана для обробки об'єктів, завантажених користувачами. Все проходить тести, але через кілька тижнів пентест показує, що зловмисники можуть виконувати команди на сервері; результат незахищеної десеріалізації прихований у коді. Проміжок часу від десеріалізації до віддаленого виконання коду може бути небезпечно малим, особливо коли серіалізовані дані з пакетів з відкритим кодом або внутрішніх служб довіряються без перевірки.

Що таке десеріалізація в коді, чому вона ризикована та де вона ховається

З точки зору розробника, що таке десеріалізація? Це процес перетворення структурованих даних, JSON, XML, двійкових форматів або серіалізованих об'єктів, специфічних для мови, назад на об'єкти в пам'яті.

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

JavaЧитання об'єктів за допомогою ObjectInputStream
PythonЗавантаження даних за допомогою розсіл.завантаження
Node.jsРозбір JSON за допомогою JSON.parse

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

Небезпечно десеріалізація часто зустрічається в:

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

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

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

Від небезпечної десеріалізації до віддаленого виконання коду: шлях атаки

Ланцюг експлуатації для незахищеної десеріалізації часто відповідає одному з таких шаблонів:

У програму надходять ненадійні дані.
Небезпечна десеріалізація відтворює об'єкти без обмежень.
Ланцюжок гаджетів запускає існуючу функціональність непередбачуваним чином.
Зловмисник підвищує привілеї та отримує можливість віддаленого виконання коду.

Варіанти:

Ланцюжки гаджетів Java використовують старі бібліотеки, такі як Apache Commons.
Python .pkl завантаження моделі з вбудованими шкідливими об'єктами.
Розбір JSON у Node.js за допомогою eval () або динамічний імпорт.

витрата:

				
					Untrusted Input → Deserialization → Gadget Chain → Remote Code Execution

Як виявити небезпечну десеріалізацію перед злиттям

Виявлення небезпечної десеріалізації до злиття коду набагато дешевше, ніж її виправлення після розгортання. Найкраще працює поєднання автоматизованого аналізу та проактивного тестування:

Статичне тестування безпеки додатків (SAST):
- Налаштуйте сканери для виявлення ризикованих API, таких як ObjectInputStream, розсіл.завантаження та 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 Сканування

прогін SAST на вихідному коді, файлах конфігурації та артефактах збірки на кожному commit.
Виявляти небезпечні шаблони десеріалізації як у коді програми, так і залежно.

Огляд артефактів

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

Pull Request Блокування

Блок об'єднується, якщо виявлено небезпечну десеріалізацію.
Відображайте корисні відгуки у звітах про потреби, щоб пришвидшити виправлення.

Застосування модульного тестування

Включити модульні тести з імітацією шкідливих вхідних даних у CI/CD pipeline
Збірки завершуються невдачею, якщо програма обробляє небезпечні серіалізовані дані замість їх відхилення.

Уникнення хибнопозитивних результатів без послаблення правил

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

Роль Ксігені

Інтегрується безпосередньо в CI/CD pipelines для сканування як вихідного коду, так і артефактів збірки.
Виявляє небезпечні шаблони десеріалізації та ризиковані залежності на ранніх етапах життєвого циклу.
Підтримує створення білого списку на основі політик з обов'язковою перевіркою безпеки, балансуючи точність виявлення з продуктивністю розробників.

Випередження віддаленого виконання коду завдяки безпечній десеріалізації

Небезпечна десеріалізація може залишатися непоміченою, доки не стане прямим шляхом до віддаленого виконання коду. Для її запобігання потрібно:

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

Практична роль Xygeni у цьому процесі:

Сканування вихідного кодуВиявляє небезпечні шаблони десеріалізації на кількох мовах перед об'єднанням коду.
Аналіз артефактів та залежностейВиявляє ризиковані серіалізовані файли (.ser, .pkl, вбудована конфігурація) та сторонні компоненти з відомими вразливостями.
Контроль на основі політикПідтримує контрольований список дозволених адрес із перевіркою безпеки, гарантуючи, що необхідні винятки не створюють реальних ризиків.
Відгуки розробників у контекстіПозначає точне місцезнаходження та причину ненадійної десеріалізації всередині pull requests, що дозволяє розробникам негайно виправляти проблеми та підтверджувати їх усунення за допомогою повторного сканування.

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

Як небезпечна десеріалізація перетворюється на віддалене виконання коду (і як це виявити перед злиттям)

Обов'язкові до прочитання публікації