Exploiting __VIEWSTATE without knowing the secrets
Last updated
Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Порада для баг-баунті: зареєструйтесь на Intigriti, преміум платформі для баг-баунті, створеній хакерами для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні та почніть заробляти винагороди до $100,000!
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. Ось короткий виклад змісту:
Для будь-якої версії .NET, коли MAC та шифрування вимкнені, MachineKey не потрібен, і, отже, немає застосовного методу для його ідентифікації.
Для версій нижче 4.5, якщо MAC увімкнено, але шифрування вимкнено, потрібен MachineKey. Метод для ідентифікації MachineKey називається "Blacklist3r."
Для версій нижче 4.5, незалежно від того, чи увімкнено MAC, якщо шифрування увімкнено, потрібен MachineKey. Ідентифікація MachineKey є завданням для "Blacklist3r - Future Development."
Для версій 4.5 і вище, всі комбінації MAC та шифрування (незалежно від того, чи обидва істинні, чи один істинний, а інший хибний) вимагають MachineKey. MachineKey можна ідентифікувати за допомогою "Blacklist3r."
Також можливо повністю вимкнути ViewStateMAC, встановивши ключ реєстру AspNetEnforceViewStateMac
в нуль в:
Ідентифікація атрибутів ViewState
Ви можете спробувати визначити, чи захищений ViewState MAC, захопивши запит, що містить цей параметр, за допомогою BurpSuite. Якщо Mac не використовується для захисту параметра, ви можете експлуатувати його, використовуючи YSoSerial.Net
Розробники можуть видалити ViewState з HTTP-запиту (користувач не отримає цей cookie). Можна припустити, що якщо ViewState відсутній, їх реалізація є безпечна від будь-яких потенційних вразливостей, що виникають з десеріалізації ViewState. Однак це не так. Якщо ми додамо параметр ViewState до тіла запиту і надішлемо наш серіалізований вантаж, створений за допомогою ysoserial, ми все ще зможемо досягти виконання коду, як показано в Випадку 1.
Щоб увімкнути ViewState MAC для конкретної сторінки, нам потрібно внести наступні зміни в конкретний файл aspx:
Ми також можемо зробити це для всього застосунку, встановивши це у файлі web.config, як показано нижче:
Оскільки параметр захищений MAC, для успішного виконання атаки спочатку нам потрібен використаний ключ.
Ви можете спробувати використати Blacklist3r(AspDotNetWrapper.exe) , щоб знайти використаний ключ.
Badsecrets - це ще один інструмент, який може ідентифікувати відомі machineKeys. Він написаний на Python, тому, на відміну від Blacklist3r, немає залежності від Windows. Для .NET viewstates є утиліта "python blacklist3r", яка є найшвидшим способом її використання.
Її можна постачати з viewstate та генератором безпосередньо:
Або він може підключитися безпосередньо до цільового URL і спробувати витягти viewstate з HTML:
Щоб шукати вразливі viewstate в масштабах, разом з перерахунком піддоменів, можна використовувати модуль badsecrets
BBOT:
Якщо вам пощастить і ключ буде знайдено, ви можете продовжити атаку, використовуючи YSoSerial.Net:
У випадках, коли параметр _VIEWSTATEGENERATOR
не надсилається сервером, вам не потрібно надавати параметр --generator
, але ці:
У цьому випадку невідомо, чи захищений параметр за допомогою 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, і експлуатація не вдасться.
Ми можемо примусити використання ASP.NET фреймворку, вказавши нижченаведений параметр у файлі web.config, як показано нижче.
Альтернативно, це можна зробити, вказавши нижченаведений параметр у параметрі machineKey
файлу web.config.
Як і в попередньому випадку, значення зашифроване. Тоді, щоб надіслати дійсний payload, зловмиснику потрібен ключ.
Ви можете спробувати використати Blacklist3r(AspDotNetWrapper.exe) , щоб знайти використовуваний ключ:
Для більш детального опису для IISDirPath та TargetPagePath зверніться сюди
Або, з Badsecrets (з значенням генератора):
Якщо дійсний ключ машини ідентифіковано, наступним кроком є генерація серіалізованого корисного навантаження за допомогою YSoSerial.Net
Якщо у вас є значення __VIEWSTATEGENERATOR
, ви можете спробувати використати параметр --generator
з цим значенням і опустити параметри --path
та --apppath
.
Успішна експлуатація вразливості десеріалізації ViewState призведе до запиту з виходом за межі до сервера, контрольованого зловмисником, який міститиме ім'я користувача. Цей тип експлуатації продемонстровано в доказі концепції (PoC), який можна знайти через ресурс під назвою "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET". Для отримання додаткових деталей про те, як працює процес експлуатації та як використовувати інструменти, такі як Blacklist3r для ідентифікації MachineKey, ви можете переглянути наданий PoC успішної експлуатації.
Властивість ViewStateUserKey може бути використана для захисту від CSRF-атаки. Якщо такий ключ було визначено в додатку, і ми намагаємося згенерувати ViewState корисне навантаження за допомогою методів, обговорених до цього часу, корисне навантаження не буде оброблено додатком. Вам потрібно використовувати ще один параметр, щоб правильно створити корисне навантаження:
Для всіх тестових випадків, якщо корисне навантаження ViewState YSoSerial.Net працює успішно, то сервер відповідає з “500 Internal server error”, маючи вміст відповіді “Інформація про стан недійсна для цієї сторінки і може бути пошкоджена” і ми отримуємо OOB запит.
Перевірте додаткову інформацію тут
Порада для баг-баунті: зареєструйтесь на Intigriti, преміум платформі для баг-баунті, створеній хакерами, для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні і почніть заробляти винагороди до $100,000!
Вчіться та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)