Сегодня мы погрузимся в ностальгию и разберем, как старенькая, но любимая многими игра "Герои Меча и Магии V" может стать лазейкой для выполнения вредоносного кода.

Вектор атаки: карты — это не то, чем кажутся
В "Героях V" есть редактор карт, с помощью которого игроки могут создавать свои миры и делиться ими. Эти карты имеют расширение .h5m, но на самом деле это обычные ZIP-архивы. Внутри такого архива лежит несколько файлов, но для нас самый интересный — name.txt. Этот файл содержит название карты, и игра считывает его, как только вы заходите в меню выбора карт для начала новой игры.

Игра использует собственную библиотеку для работы с ZIP-архивами. Когда вы открываете список карт, игра должна распаковать name.txt из каждого .h5m файла, чтобы показать вам их названия.

Уязвимость: переполнение кучи на доверии
Проблема возникает в процессе распаковки. Вот как это выглядит на техническом уровне:
➡️Выделение памяти: Игра смотрит на метаданные файла name.txt внутри ZIP-архива, а именно на поле m_UncompressedSize. Это поле говорит, сколько места понадобится для распакованного файла. На основе этого значения игра выделяет буфер в памяти (в куче) с помощью кастомного аллокатора H5_alloc.
➡️Распаковка: Затем вызывается функция Uncompress, которая использует библиотеку zlib, а конкретно функцию inflateBack. Эта функция распаковывает данные.
➡️Копирование: inflateBack вызывает специальную callback-функцию zlib_out, которая и копирует распакованные данные в тот самый буфер, который был выделен на первом шаге.

Ключевая уязвимость заключается в том, что игра слепо доверяет значению m_UncompressedSize из заголовка ZIP-файла. Что, если мы создадим вредоносный архив, где m_UncompressedSize будет маленьким (например, 0x800 байт), а реальный размер распакованных данных — гораздо больше (например, 0x2000 байт)? В этом случае zlib_out попытается записать 0x2000 байт в буфер размером 0x800 байт. Результат — классическое переполнение кучи (heap overflow).

Эксплуатация: от переполнения к RCE
Теперь самое интересное — как превратить это переполнение в выполнение своего кода.

Поиск цели: Наша задача — перезаписать что-то важное в памяти. Идеальная цель — указатель на таблицу виртуальных функций (vtable) какого-нибудь объекта. Если мы заменим этот указатель на свой, то при вызове метода этого объекта управление перейдет к нашему коду.

Исследователи обнаружили, что из-за особенностей работы кастомного аллокатора H5_alloc можно довольно предсказуемо разместить наш вредоносный буфер рядом с определенным объектом. С помощью скрипта для IDA Python они выяснили, что объект типа NGScene::CLightStateNode почти всегда находится на одном и том же расстоянии от буфера, выделяемого для name.txt.

➡️Построение цепочки: У игры не включена рандомизация адресного пространства (ASLR), так что адреса кода и данных известны заранее. Однако мы не контролируем стек напрямую, поэтому классический ROP (Return-Oriented Programming) не подходит. Вместо этого используется техника JOP/COP (Jump/Call-Oriented Programming).

Схема эксплойта выглядит так:
0️⃣Создается карта .h5m со специально подготовленным файлом name.txt. В его ZIP-заголовке указывается маленький размер, а внутри — большой объем данных (шеллкод).
1️⃣Когда игра пытается показать название карты, происходит переполнение кучи.
2️⃣Переполнение перезаписывает vtable объекта NGScene::CLightStateNode, указывая на первый гаджет в нашей JOP-цепочке.
3️⃣Когда игра пытается освободить этот объект, вызывается его деструктор через подмененную vtable, и управление передается нашему первому гаджету.
4️⃣Цепочка гаджетов выполняет "пивот" стека: указатель стека (ESP) перемещается так, чтобы он указывал на контролируемую нами область памяти внутри перезаписанного объекта.
5️⃣Далее выполняется стандартная ROP-цепочка, которая загружает kernel32.dll, находит адрес функции WinExec и запускает calc.exe.

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

🔗Источник

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK | 🌚 Мерч