SuperSerial — хакерский инструмент для поиска Java сериализации

Стоило нам начать подробно разбирать Java-сериализацию, как этот вектор атаки стал настолько модным, что ломают с его помощью все подряд. Я знаю как минимум с десяток продуктов, в которых была найдена соответствующая уязвимость, и с пяток случаев нахождения таких уязвимостей участниками разных bug bounty. А ведь то же самое могло начаться еще примерно год назад!

Надеюсь, в одной из следующих статей я смогу заново осознать эксплоит и объяснить его простыми славами, без дебрей Java. А посему сегодня мы коснемся сугубо практической части: поговорим о том, как же выискивать уязвимое ПО.

На самом деле задачи обычно две. Во-первых, обнаружить дырку в ПО, в которую мы можем слать сериализованный объект, чтобы он был десериализован. А во-вторых, понять, использует ли программа уязвимую версию библиотеки.

Вторая задача хоть и важна, но не особенно. Решается она чисто экспериментально (нужно послать сериализованный запрос с пейлоадом) или путем анализа либ (когда есть доступ к исходникам). Если нет уязвимой либы, то приложение всегда можно задосить, но это уже нехорошо.

Для решения задачи с поиском уязвимости позволь предложить тебе специальный плагин для Burp Suite — SuperSerial. Он прост, но полезен. Он пытается отыскать в запросах и ответах от сервера сериализованные объекты, в том числе представленные как Base64.

С таким инструментом ты не пропустишь момента, когда один из кучи сервисов системы отдаст тебе маленький сериализованный объект (реальный случай из жизни). Один нюанс: у меня есть некоторые сомнения в том, что плагин умеет выделять Java-объекты, когда они перемешаны с другими данными.

У SuperSerial есть собрат SuperSerial-Active. Он расширяет возможности активного сканера Burp, добавляя проверку на Java-сериализацию. Фактически он тупо шлет сериализованный объект с пейлоадом (используется ysoserial) на каждый URL. Пейлоад представляет собой простую команду для отстука на наш веб-сервер. Типичный метод Out of band (OOB). Плагин отображает, по какому из URL произошла обработка объекта и какой из запросов ее вызвал. Топорно, конечно, но это может сработать. Обычно для таких целей лучше использовать не внешний веб-сервер, а DNS-сервер, так как исходящие подключения часто заблокированы на файрволе, а вот DNS-туннель блокируют редко.

Получаем RCE в SAML через XSLT

Мы уже рассматривали атаки с использованием XSLT, но все равно стоит напомнить, что это за технология. Она позволяет с помощью XSL-стиля поменять структуру XML. Но для нас XSLT интересен тем, что позволяет напрямую писать код в стилях XSL, и этот код будет выполняться в процессе преобразования. В классическом случае проблема такой атаки в том, что чаще всего мы контролируем только сам XML-документ, но не XSL-стиль, по которому он будет преобразован. Однако на самом деле это не всегда так.

Есть ряд ситуаций, когда XSL-стиль может находиться прямо внутри самого XML. Да-да, в документе указывается описание того, как его необходимо преобразовать. Делается это за счет добавления в документ еще одного namespace (xmlns:xsl=http://www.w3.org/1999/XSL/Transform). Предостерегаю тебя от того, чтобы пихать XSLT-вектор в каждый XML по аналогии c XXE. Поддержка XSLT на принимающей стороне (в XML-парсере) не появляется просто так.

Увидеть, есть ли в браузере поддержка XSL внутри документов XML, мы можем при обработке файлов SVG, а также при использовании «глубоких» XML-технологий — таких как XML Digital Signature.

XML DSig используется для подписи XML-документов. Этот стандарт позволяет указывать XSLT-преобразования для документа до того, как будет проверена подпись. По идее, это было сделано для более гибкого взаимодействия. Когда есть разница между тем, как подпись считается на принимающей и на отправляющей стороне (разные кодировки, учет переносов и лишних пробелов — проблем возникает много), с помощью XSL-стиля можно компенсировать эту разницу. Для описания преобразования используется элемент Transform (в Transforms). Пример ты можешь увидеть на картинке.

Получается, что у нас есть технология, которая из коробки поддерживает XSLT-трансформацию. Если видишь какой-то сервис, использующий XML DSig, значит, можешь попробовать заслать на него что-нибудь хорошее. При этом помни, что твой документ должен быть валидным и все элементы подписи тоже должны присутствовать. Сама она может и не быть валидной, но она нужна, чтобы пройти первичный парсинг на корректность документа. А далее выполнятся наши действия из стиля, и только после этого произойдет проверка подписи.

Если вспомнить, где XML DSig используется постоянно, то на ум приходит Security Assertion Markup Language (SAML). Это такой открытый стандарт на базе XML, который используется для создания централизованной аутентификации и авторизации. Сам по себе он непрост, так что подробно разбирать его не будем. Важно, что он часто используется в крупных компаниях.

Что мы имеем в итоге? Есть протокол аутентификации SAML, в котором используется технология XML DSig, которая, в свою очередь, поддерживает XSLT-трансформацию. Эта длинная цепочка дает нам возможность до аутентификации получить RCE. Очень удобно! Конечно, в реальности все не всегда так просто: если разработчики или админы в курсе проблемы, то кастомные стили для XML DSig могут быть и отключены.