Apache, ViewState & Deserialisation

JavaServer Faces

JSF — платформа разработки интерфейса пользователя для веб-приложений Java. Для хранения текущего состояния страницы (например, какие элементы страницы должны отображаться в настоящее время) JSF использует параметр ViewState.

(HTML-форма отправки данных)

ViewState

Он редставляет из себя сериализованный Java-объект, автоматически встраиваемый в HTML-форму как скрытое поле с именем javax.faces.ViewState. При отправке данных из формы мы видим, что также отправляется параметр ViewState. А так как он является сериализованным объектом, вероятно, мы можем попробовать выполнить команду на стороне сервера (RCE), используя собственный заряженный сериализованный объект, который содержит полезную нагрузку.
(Тем, кто хочет углубиться в данную тему, рекомендую почитать вот этот материал). 

Итак, приступим

В данной статье рассмотрим подобную уязвимость и метод её эксплуатации на примере web-приложения уязвимой виртуальной машины с HackTheBox, использующей технологию Apache MyFaces.

В конфигурации Apache MyFaces можно включить шифрование компонента ViewState (в нашем примере, используется шифрование DES-ECB), что повысит безопасность приложения.
Если шифрование отключено, то нам необходимо отправить сериализованный объект через компонент ViewState для выполнения команды на стороне сервера. Но что, если web-приложение использует шифрование, а ключ скомпрометирован? Это немного усложняет задачу, давайте посмотрим, как быть в такой ситуации.

Нам удалось найти бэкап с файлами конфигурации web-приложения:

Отлично! Теперь мы знаем SECRET, MAC_ALGORITHM, MAC_SECRET.
Обратимся к официальной документации. Тут и тут.

Переварив полученную информацию, попробуем дешифровать ViewState. Для этого
с помощью Decoder BurpSuite приведем его в нормальный вид и напишем небольшой скрипт на Python:

На выходе получаем:

Это сериализованный объект, содержащий HmacSHA1-подпись для проверки целостности.

Приступим к созданию «заряженного» VIEWSTATE.

Для создания сериализованной полезной нагрузки мы будем использовать инструмент ysoserial

(попробую пингануть себя (ip: 10.10.14.11) с сервера)

После ysoserial наш payload выглядит следующим образом:

Но просто в таком виде его отправить не получится, мы уже знаем, что сервер использует проверку подлинности на основе HmacSHA1-алгоритма, DES-ECB шифрование и как финал «заворачивает» всё это в base64. Давайте всё это автоматизируем, написав Python-скрипт (спасибо be_a_saint).

Настроив редирект в BurpSuite, мы можем видеть результат выполнения скрипта – наш payload:

Открываем Wireshark, в BurpSuite жмём Forward и ловим входящие ICMP пакеты,
что говорит об успешном выполнении нашей нагрузки на стороне сервера.

Ещё небольшой пример полезной нагрузки и её результат.

Аналогично, полезная нагрузка выполнилась успешно.

А если что-нибудь посерьёзнее? Хорошо, зальём на сервер netcat и прокинем себе реверс шелл:

Готово! Получили шелл от имени веб-сервиса, дальше дело за энумерацией и повышением привилегий.

Эксплуатация данной уязвимости стала возможной в результате получения SECRET’ов сервера, отсюда напрашивается вывод, что несмотря на все принимаемые меры защиты кода/приложения, одним из самых важных критериев безопасности остается сохранение конфиденциальности чувствительных данных приложения (пароли, файлы конфигурации, бэкапы и т.д.).

На этом всё, спасибо за внимание!