Стандартные эксплойты редко работают без изменений или настроек базового кода эксплойта. Некоторые инструменты могут обнаружить недостатки десериализации, но помощь человека часто необходима для подтверждения проблемы. Ожидается, что данные о распрастранении недостатков десериализации будут увеличиваться по мере разработки инструментария, который поможет выявить и устранить его. Влияние недостатков невозможно переоценить. Эти недостатки могут привести к атакам на удаленное выполнение кода (одной из самых серьезных атак). Влияние на бизнес зависит от требований защиты приложения и данных.
Является ли приложение уязвимым?
Приложения и API будут уязвимы, если они десериализуют враждебные или поддельные объекты, предоставленные злоумышленником. Это может привести к двум основным типам атак:
- Атаки, связанные с объектами и структурой данных, когда злоумышленник изменяет логику приложения или достигает произвольного удаленного выполнения кода, если приложению доступны классы, которые могут изменить поведение во время или после десериализации.
- Типичные атаки с фальсификацией данных, такие как атаки, связанные с контролем доступа, когда используются существующие структуры данных, но содержимое изменяется.
Сериализация может использоваться в приложениях для:
- Удаленное и межпроцессное взаимодействие (RPC / IPC)
- Проводные протоколы, веб-сервисы, брокеры сообщений
- Кэширование / Постоянство
- Базы данных, кеш-серверы, файловые системы
- HTTP cookie, параметры формы HTML, токены аутентификации API
Как предотвратить
*Единственный безопасный архитектурный шаблон — не принимать сериализованные объекты из ненадежных источников или использовать среды сериализации, которые допускают только примитивные типы данных. Если это невозможно, рассмотрите одно из следующих:
- Реализация проверок целостности, таких как цифровые подписи, на любых сериализованных объектах для предотвращения создания враждебных объектов или подделки данных.
- Обеспечение строгих ограничений типов во время десериализации перед созданием объекта, так как код обычно ожидает определяемый набор классов. Обходные пути для этой техники были продемонстрированы, поэтому полагаться исключительно на это не рекомендуется.
- Выделение и запуск кода, который по возможности десериализуется в средах с низким уровнем привилегий.
- Записывать исключения и сбои десериализации, например, когда входящий тип не является ожидаемым типом, или десериализация генерирует исключения.
- Ограничение или мониторинг входящих и исходящих сетевых подключений от контейнеров или серверов, которые десериализуются.
- Мониторинг десериализации, оповещение о постоянной десериализации пользователя.
Полезные ссылки
- https://www.owasp.org/index.php/DeserializationCheatSheet
- https://www.owasp.org/index.php/OWASPProactiveControls#4:ValidateAll_Inputs
- https://www.owasp.org/index.php/Category:OWASPApplicationSecurityVerificationStandard_Project#tab.3DHome
- https://speakerdeck.com/pwntester/surviving-the-java-deserialization-apocalypse
- https://speakerdeck.com/pwntester/friday-the-13th-json-attacks
