Insecure deserialization

Всем привет! С вами wr3dmast3r, и сегодня я познакомлю вас с интересной уязвимостью, связанной с небезопасной десериализацией данных.

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

Содержание:

1) Что же такое сериализация данных?

2) Что же такое тогда десериализация данных?

3) Что такое небезопасная десериализация?

4) Как возникают небезопасные уязвимости десериализации?

5) Как может повлиять небезопасная десериализация?

6) Несколько простых примеров небезопасной десериализации данных.

Начнём с того, что же такое сериализация данных?

Сериализация — это процесс преобразования сложных структур данных, таких как объекты и их поля, в «более плоский» формат, который может быть отправлен и принят в виде последовательного потока байтов. Сериализация данных значительно упрощает:

• запись сложных данных в межпроцессную память, файл или базу данных
• отправку сложных данных, например, по сети, между различными компонентами приложения или в вызове API

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

Что же такое тогда десериализация данных?

Десериализация — это процесс восстановления этого байтового потока до полнофункциональной записи исходного объекта в точно такое же состояние, как и до сериализации. Логика веб-сайта может взаимодействовать с этим десериализованным объектом, как и с любым другим объектом.

Многие языки программирования предлагают встроенную поддержку сериализации. То, как именно сериализуются объекты, зависит от языка. Некоторые языки сериализуют объекты в двоичные форматы, в то время как другие используют различные строковые форматы с различной степенью удобочитаемости. Обратите внимание, что все атрибуты исходного объекта хранятся в сериализованном потоке данных, включая любые закрытые поля. Чтобы предотвратить сериализацию поля, оно должно быть явно помечено как «переходное» в объявлении класса.

Имейте в виду, что при работе с различными языками программирования сериализация может называться маршаллингом (Ruby) или маринованием (Python). Эти термины являются синонимами «сериализации» в данном контексте.

Что такое небезопасная десериализация?

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

Можно даже заменить сериализованный объект объектом совершенно другого класса. Вызывает опасение тот факт, что объекты любого класса, доступные веб-сайту, будут десериализованы и инстанцированы, независимо от того, какой класс ожидался. По этой причине небезопасную десериализацию иногда называют уязвимостью «внедрения объектов».

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

Как возникают небезопасные уязвимости десериализации?

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

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

Уязвимости могут также возникать из-за того, что десериализованные объекты часто считаются заслуживающими доверия. Особенно при использовании языков с двоичным форматом сериализации разработчики могут подумать, что пользователи не могут эффективно читать или манипулировать данными. Однако злоумышленник может использовать двоичные сериализованные объекты так же, как и использовать строковые форматы.

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

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

Как может повлиять небезопасная десериализация?

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

Даже в тех случаях, когда удаленное выполнение кода невозможно, небезопасная десериализация может привести к эскалации привилегий, произвольному доступу к файлам и атакам типа «отказ в обслуживании».

Попытаюсь раскрыть данную уязвимость на примере нескольких лаб с PortSwigger.

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

На примере лаб постараюсь донести основную мысль данной уязвимости.

Lab: Modifying serialized objects

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

1. Логинимся с кредами, которые нам были предоставлены.

2. Перехватываем запрос после успешного входа и видим сериализованный объект в хэдере куки.

3. Воспользуемся встроенным декодэром в берпе и попробуем использовать кодировку base64.

Как мы видим, у нас есть несколько параметров, что передаются в cookie. По задаче нам нужно получить привилегии администратора и удалить учетную запись другого пользователя. Обращаем внимание на передаваемый параметр b:0, который, скорее всего, является способом манипулировать привилегиями пользователя.
Вернемся на секунду к теории. Передаваемые данные всегда имеют определенный формат, который записывается, например так:

O:4:"User":2:{s:8:"username";s:6:"carlos";s:7:"isAdmin";b:0;}

Поэтому, чтобы манипулировать привилегиями, нужно будет исправить пару символов и модернизировать параметр b.

Окончательная модернизация параметра будет выглядеть примерно так:

4. Попробуем воспользоваться кукой, что у нас получилась.

Подменяем куку в перехваченном запросе:

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

5. Удаляем пользователя и также подменяем куку.

Так мы смогли воспользоваться уязвимостью и получить привилегии администратора, которые позволили нам удалить пользователя.

Lab: Using application functionality to exploit insecure deserialization

В этой лаборатории используется механизм сеансов на основе сериализации. Определенная функция вызывает опасный метод для данных, предоставленных в сериализованном объекте. Чтобы решить лабу, нужно удалить указанный файл в домашнем каталоге пользователя.

Приступим.

Известно, что файл который нужно удалить, находится по пути /home/carlos/morale.txt

1) После авторизации у нас появляется несколько функций, и одна из интересных для нас - это удаление аккаунта, перехватываем запрос с ней:

2) Модернизируем cookie, как и в предыдущей лабе, заменив директорию удаления аватара на директорию нашего файла, не забываем заменить длину параметра s:23

3) Подменяем cookie в запросе удаления аккаунта - и лаба решена, мы смогли удалить файл.

С любовью, ваши wr3dmast3r и RESOLUTE ATTACK! До новых встреч!