Эксплуатация уязвимости десериализации

Следующий вид уязвимости из OWASP TOP 10 рассмотрим Insecure Deserialization, он на восьмом месте. Не думайте если он на этом месте то он менее критичен чем остальные, так как с помощью него можно и прокачать своего юзера в роли апликейшена и заставить апликеше выполнять какие то действия за какого-то пользователя.

Эксплуатация десериализации довольно сложна, так как готовые эксплойты редко работают без изменений или настроек базового кода в готовом эксплойте.

Эта проблема включена в Топ-10 на основе отраслевого опроса, а не количественных полученных отчетах. Некоторые инструменты могут обнаружить недостатки десериализации, но без помощи человека подтвердить эту проблему сложно. Но забивать на такую уязвимость не стоит, если ее трудно воспроизвести))) Влияние недостатков десериализации невозможно переоценить. Эти недостатки могут привести к атакам на удаленное выполнение кода, а это одна из самых серьезных атак. Хочу добавить, что эта уязвимость распространяется только на C-подобные языки программирования, это и java, и PHP и тд.

Как понять что вы уязвимы к этой уязвимости:

1) Приложения и API будут уязвимы, если они десериализуют враждебные или подделанные объекты, предоставленные злоумышленником. Это может привести к двум основным типам атак:

- Атаки, связанные с объектами и структурой данных, когда злоумышленник изменяет логику приложения или достигает произвольного удаленного выполнения кода, если приложению доступны классы, которые могут изменить поведение во время или после десериализации.

- Типичные атаки с фальсификацией данных, такие как атаки, связанные с контролем доступа, когда используются существующие структуры данных, но содержимое в них изменяется на нужные для проведения атак.

2) Сериализация может использоваться в приложениях для:

- Удаленного и межпроцессного взаимодействие (RPC / IPC)

- Проводных протоколов, веб-сервисов, брокеров сообщений

- Кэширования

- Баз данных, кеш-серверов, файловых систем

- HTTP cookie, параметров форм HTML, токенов аутентификации API

Примеры сценариев атаки:

1) Возьмем в пример PHP язык. Допустим у нас есть сайт, который написан на PHP и он использует сериализацию объектов, для сохранения "супер" cookie, в которой содержится идентификатор пользователя, его роль, хэш пароля и тд.

Кука в данном случаи это наш объект, который при сериализации преобразовывается в байты, которые в свою очередь распределяются по файлам, базам данных и памятью, при десериализации этот объект проходить обратную стадию, где и работает злоумышленник, если в нашем апликейшене не приняты меры по безопасной десериализации данных

Что делает в свою очередь злоумышленник:

- Для начала ему надо зарегать пользователя на этому сайте

- Затем найти куку, которую предоставил ему этот сайт

- Понять ее построение, как ее раскодировать (ведь она не лежит, надеюсь у вас, в открытом виде, как показано выше:-))

- После того как мошенник провел анализ этой куки, он понимает что ему надо заменить тут, чтоб поднять его роль до админа, чтоб творить чудеса на этом сайте.

Смотрим выше, что же в итоге получилось. Этот паренек, сменил в объекте куки, имя и роль, затем закодил в то состояние в котором воспринимается кука на серваке, отправил видоизмененную куку просто в браузер, в открытой консоле во вкладке application. Все верно вы подумали, на серваке, его существующий юзер не стал админом на всегда, но он просто обманул фронт-энд апликейшена и в рамках этой сессии он может творить что угодно, как администратор этого сайта.

2) Второй пример, приведу на примере Java. Есть приложение написанное на React, вызывающие набор микросервисов Spring Boot. Было принято решение, которое заключалось в сериализации состояния пользователя и передаче его данных туда и обратно с каждым запросом. Если злоумышленник заметит сигнатуру Java-объекта «R00», то сможет подменять ее и даже задачать в нее другие виды уязвимостей, те же sql injection и XSS.

Сделаем пример на игре змейка в вебе)))

После того как игра закончится проигрышем, нам выведется какой-то алерт. А гет параметр передается значение юзера, это может быть и не только гет параметр, можно и через POST запрос, но для наглядности я покажу это на GET.

В тут посмотрим на то что передалось в урле

Тут мы видим что в параметр state - передалось:

- имя юзера

- затраченное время на игру

- и сколько набрал очков

Эти параметры можно попробовать заменить на пейлоуды, которые вызовут уязвимость. Давайте в параметр имя заюзаем пейлоуд который вызовет sql injection. Передадим туда вместо "Gamer42" такой пейлоуд "'or''='", который в свою очередь преобразуется в encoding.

При выполнении текущего реквеста мы получим такой ответ от сервера на страницу нашего апликейшена, так как он не знает кого точно нам вернуть он нам вернул всех остальных. Можно также было употребить и другие пейлоуды, для того же ответа, типа % и тд.

А теперь давайте в этот урл заюзаем еще и XSS. Теперь мы передадим в GET параметр в значение Score, вместо 1442 свой пейлоуд "<svg onload=alert(1)>", который вызовет попап, на этой странице, а в попапе будет та инфа которую мы передадим в пейлоуде.

В конечном итоге при отправке на сервер этого запроса, он будет выглядеть так как на верхнем скрине. А в ответ от сервера мы получим помимо этой страницы, еще и попап в котором будет 1

Как я уже говорил эту уязвимость трудно искать сканерами, и нужно применять и ручные методологии, для корректировки запросов. Есть хороший плагин в Burp Suite, называется Java Deserialization Scanner, который помогает немного убрать рутину ручного поиска, но все равно там нужны ручная настройка при каждом настройке сканера, для задавания тех данных в которые будут подставляться все пейлоуды в запросе на сервак.

Как защититься от этой уязвимости:

- Должна быть проверка на целостность, такие как цифровые подписи, на любых сериализованных объектах для предотвращения создания враждебных объектов или подделки данных.

- должны быть строгие ограничения типа во время десериализации перед созданием объекта, так как код ожидает определенных классов.

- Записывать исключения и сбои десериализации, например, когда входящий тип не является ожидаемым типом, или десериализация генерирует исключения.

- Ограничение или мониторинг входящих и исходящих сетевых подключений от контейнеров или серверов, которые десериализуются.

Источник: m.vk.com

Комментарии: