A8:Software and Data Integrity Failures
Наступний вид вразливості OWASP TOP 10 розглянемо Insecure Deserialization, він на восьмому місці. Не думайте якщо він на цьому місці він менш критичний ніж інші, тому що за допомогою нього можна і прокачати свого користувача в ролі аплікейшена і змусити аплікеші виконувати якісь дії за якогось користувача.
Дивимося вище, що ж у результаті вийшло. Цей хлопець, змінивши в об'єкті куки, ім'я та роль, потім закодував у той стан у якому сприймається кука на серваку, відправив видозмінену куку просто у браузер, у відкритій консолі у вкладці application. Все правильно ви подумали, на серваку, його існуючий користувач не став адміном на завжди, але він просто обдурив фронт-енд аплікейшену і в рамках цієї сесії він може творити будь-що, як адміністратор цього сайту.
2) Другий приклад, наведу з прикладу Java. Є програма написана на React, що викликають набір мікросервісів Spring Boot. Було ухвалено рішення, яке полягало в серіалізації стану користувача та передачі його даних туди та назад з кожним запитом. Якщо зловмисник помітить сигнатуру Java-об'єкта «R00», то зможе підміняти її і навіть завдання в неї інших видів уразливостей, ті ж sql injection і XSS.
Зробимо приклад на грі змійка в Інтернеті)))
Експлуатація десеріалізації досить складна, оскільки готові експлойти рідко працюють без змін чи налаштувань базового коду готовому експлойті.
Ця проблема включена до Топ-10 на основі галузевого опитування, а не кількісних отриманих звітів. Деякі інструменти можуть виявити недоліки десеріалізації, але без допомоги людини важко підтвердити цю проблему. Але забивати на таку вразливість не варто, якщо її важко відтворити))) Вплив недоліків десеріалізації неможливо переоцінити. Ці недоліки можуть призвести до атак на віддалене виконання коду, а це одна з найсерйозніших атак. Хочу додати, що ця вразливість поширюється тільки C-подібні мови програмування, це і java, і PHP і тд.
Як зрозуміти що ви вразливі до цієї вразливості:
1) Програми та API будуть уразливими, якщо вони десеріалізують ворожі або підроблені об'єкти, надані зловмисником. Це може призвести до двох основних типів атак:
- Атаки, пов'язані з об'єктами та структурою даних, коли зловмисник змінює логіку програми або досягає довільного віддаленого виконання коду, якщо додатку доступні класи, які можуть змінити поведінку під час або після десеріалізації.
- Типові атаки з фальсифікацією даних, такі як атаки, пов'язані з контролем доступу, коли використовуються існуючі структури даних, але вміст змінюється на потрібні щодо атак.
2) Серіалізація може використовуватися у додатках для:
- Видаленої та міжпроцесної взаємодії (RPC/IPC)
- Дротових протоколів, веб-сервісів, брокерів повідомлень
- Кешування - баз даних, кеш-серверів, файлових систем
- HTTP cookie, параметрів форм HTML, токенів аутентифікації API
Приклади сценаріїв атаки:
1) Візьмемо за приклад PHP мову. Допустимо у нас є сайт, який написаний на PHP і він використовує серіалізацію об'єктів, для збереження "супер" cookie, в якій міститься ідентифікатор користувача, його роль, пароль хеш і тд.
Що робить у свою чергу зловмисник:
- Для початку йому треба зареєструвати користувача на цьому сайті
- Потім знайти куку, яку надав йому цей сайт
- Зрозуміти її побудову, як її розкодувати (адже вона не лежить, сподіваюся у вас, у відкритому вигляді, як показано вище:-))
- Після того як шахрай провів аналіз цієї куки, він розуміє, що йому треба замінити тут, щоб підняти його роль до адміну, щоб творити дива на цьому сайті.
Після того, як гра закінчиться програшем, нам виведеться якийсь алерт. А цей параметр передається значення користувача, це може бути і не тільки параметр, можна і через POST запит, але для наочності я покажу це на GET.
Зрештою, при відправці на сервер цього запиту, він буде виглядати так як на верхньому скрині. А у відповідь від сервера ми отримаємо окрім цієї сторінки, ще й попап в якому буде 1
Тут подивимося на те що передалося в урлі
Як я вже казав цю вразливість, важко шукати сканерами, і потрібно застосовувати і ручні методології, для коригування запитів. Є хороший плагін в Burp Suite, називається Java Deserialization Scanner, який допомагає трохи прибрати рутину ручного пошуку, але все одно там потрібні ручне налаштування при кожному налаштуванні сканера, для задання тих даних, які будуть підставлятися всі пейлоуди в запиті на сервак.
Як захиститися від цієї вразливості:
- Повинна бути перевірка на цілісність, такі як цифрові підписи, на будь-яких серіалізованих об'єктах для запобігання створенню ворожих об'єктів або підробки даних.
- Повинні бути суворі обмеження типу під час десеріалізації перед створенням об'єкта, оскільки код чекає на певні класи.
- Записувати винятки та збої десеріалізації, наприклад, коли вхідний тип не є очікуваним типом, або десеріалізація генерує винятки.
- Обмеження або моніторинг вхідних та вихідних мережевих підключень від контейнерів або серверів, що десеріалізуються.
Кука в даному випадку це наш об'єкт, який при серіалізації перетворюється на байти, які в свою чергу розподіляються за файлами, базами даних та пам'яттю, при десеріалізації цей об'єкт проходить зворотну стадію, де і працює зловмисник, якщо в нашому аплікейшені не вжито заходів щодо безпечної десеріалізації даних
Тут ми бачимо, що в параметр state - передалося:
- ім'я користувача
- Витрачений час на гру
- і скільки набрав очок
Ці параметри можна спробувати замінити на пейлоуди, які спричинять вразливість. Давайте в параметр ім'я заюзаєм пейлоуд який викликає sql injection. Передамо туди замість "Gamer42" такий пейлоуд "or" = "", який у свою чергу перетворюється в encoding.
При виконанні поточного реквесту ми отримаємо таку відповідь від сервера на сторінку нашого аплікейшену, тому що він не знає кого точно нам повернути він нам повернув решту. Можна також було використати й інші пейлоуди, для тієї ж відповіді типу % і тд.
А тепер давайте в цей урл заюзаємо ще й XSS. Тепер ми передамо в GET параметр значення Score, замість 1442 свій пейлоуд "", який викличе попап, на цій сторінці, а в попапі буде та інфа яку ми передамо в пейлоуді.
