12.09.2014

Обход Windows ASLR в Microsoft Word при помощи COM-объектов

image

Некоторое время назад для обхода ASLR (Address Space Layout Randomization) эксплуатировалась уязвимость нулевого дня, которая присутствовала в файлах в формате RTF. При этом был задействован модуль MSCOMCTL.OCX, где не была реализована защита ASLR.

Автор: Парвез Анвар (Parvez Anwar)

Некоторое время назад для обхода ASLR (Address Space Layout Randomization) эксплуатировалась уязвимость нулевого дня, которая присутствовала в файлах в формате RTF. При этом был задействован модуль MSCOMCTL.OCX, где не была реализована защита ASLR. Мне захотелось исследовать способ загрузки модуля, а также попробовать найти другие модули, которые можно поэксплуатировать подобным образом после того, как компания Microsoft выпустила бюллетень MS14-024, где, наконец, была реализована защита ASLR в MSCOMCTL.OCX. Я начал с изучения модуля Metasploit, эксплуатирующего уязвимость Microsoft Word RTF Object Confusion (CVE-2014-1761), которая была исправлена в апрельском обновлении MS14-017 . Эксплоит использует MSCOMCTL.OCX для обхода ASLR. Мне нужен был только тот участок кода, который загружает файл OCX, а все остальное необходимо было удалить.

Рисунок 1: Содержимое эксплоита

Толька загрузка файла OCX добавляет к эксплоиту 17018 байт, что слишком много. Я решил поискать способы уменьшения этого размера. Основной объем информации брался из управляющего слова \objdata, которое содержит данные используемые объектом, представленным в шестнадцатеричном формате. При помощи скрипта, написанного на vbs, я структурировал всю информацию и записал ее в отдельный файл для более удобного просмотра в текстовом редакторе.

Рисунок 2: Структура содержимого управляющего слова

В поле FormatID содержится значение 0×00000002, что говорит о том, что за структурой ObjectHeader должна следовать структура EmbeddedObject. Основной параметр – размер данных, значение которого 0x00001E00 (7680 байт). По окончании этого блока находится заголовок OLEVersion. Удалив эту порцию информации (а также некоторые другие управляющие слова) и приведя в порядок код, получаем следующее:

Рисунок 3: Урезанная версия эксплоита

Помимо всего прочего я изменил размер блока данных на значение 0x01 (см. строку 8), так что теперь блок данных содержит значение 0×41, а полный размер файла похудел до 1619 байт.

Рисунок 4: Урезанная версия файла в шестнадцатеричном формате

Исследуя оставшиеся данные, видим еще один заголовок OLEVersion и поле FormatID. Значение 0×00000005 у FormatID говорит о том, что должно присутствовать поле classname, которое в данном случае содержит значение METAFILEPICT. Поле classname определяет тип структуры представленной информации, которая в данном случае соответствует Windows Meta File (WMF). Если в поле FormatID установить значение 0×00000000, то парсер не будет учитывать поле classname, и мы можем удалить всю информацию, которая имеет отношение к этому классу.

Рисунок 5: Содержимое файла после удаления информации, относящейся к полю classname

Управляющее слово \objclass – необязательное, поэтому также удаляем его.

Рисунок 6: Окончательная версия урезанного файла

В итоге мы сократили файл с изначальных 17018 байт до 180 байт. Избыточная информация могла быть добавлена специально для раздувания размера эксплоита и затруднения работы аналитика. За дополнительной информацией по структурам данных обращайтесь к статье «Object Linking and Embedding (OLE) Data Structures».

Поиск новых объектов ActiveX/COM

Теперь, когда вся несущественная информация удалена, необходимо изменить ProgID (programmatic identifier) и размер ProgID. Поскольку объекты ActiveX не используются в Internet Explorer, их не требуется помечать как «safe for initialization» или «safe for scripting». Тестирование будет проводиться на двух системах. На первой системе будет установлена только Windows (обновленная до последней версии). На второй – Microsoft Office. Далее необходимо предпринять следующие шаги:

  • Получить список всех модулей, где еще не реализована защита ASLR.
  • Получить список COM-модулей.
  • Протестировать модули на предмет их загрузки в MS Word.
  • Проверить модули на предмет неизменности адреса загрузки (get rebased).

В процессе поиска я нашел две библиотеки, удовлетворяющие вышеуказанным критериям.

Информация о первой библиотеке:

Библиотека

OTKLOADR.DLL

Путь

C:\Program Files\Microsoft Office\Office14\ADDINS\
C:\Program Files (x86)\Microsoft Office\Office14\ADDINS\ (W64)

Значения ProgID

otkloadr.WRAssembly.1
otkloadr.WRLoader.1

Версии

7.10.2179.0 (msvcr71.dll) 7.10.5077.0 (olkloadr.dll)

Примечание

OTKLOADR.DLL изменяет адрес загрузки, но ссылается на другой модуль без ASLR MSVCR71.DLL, находящийся по тому же самому пути

Информация о второй библиотеке:

Библиотека

SQLCECA35.DLL

Путь

C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\
C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v3.5 (W64)

Значения ProgID

SSCE.DropTableListener.3.5
SSCE.Engine.3.5SSCE.Error.3.5
SSCE.Errors.3.5
SSCE.Param.3.5
SSCE.Params.3.5
SSCE.RemoteDataAccess.3.5
SSCE.Replication.3.5

Версии

3.5.5692.0 (sqlceca35.dll and sqlceer35EN.dll)

Примечание

Загружается еще один модуль sqlceer35EN.dll, но у него изменяется адрес загрузки

Все указанные выше ProgID (кроме одного) успешно загружают модуль без ASLR, однако при выходе из MS Word появляется следующее сообщение «Do you want to save changes you made to {filename}». Также часто возникает ошибка «There is not enough memory or disk space to display or print the picture».

Единственный ProgID, при использовании которого не возникает никаких сообщений и ошибок, - «otkloadr.WRAssembly.1». С этим ProgID не возникает никаких проблем, документ открывается и закрывается без появления каких-либо окон и сообщений. Как оказалось, при компиляции библиотеки «MSVCR71.DLL» не использовалась опция /DYNAMICBASE. В дальнейшем можно было проверить все остальные доступные ProgID на предмет того, загружают ли они модули без ASLR, но эта тема другой статьи. Ниже показан скриншот, показывающий обе библиотеки, загруженные в адресное пространство процесса WINWORD.EXE.

Рисунок 7: Демонстрация загрузки библиотек OTKLOADR.DLL, MSVCR71.DLL в адресное пространство процесса WINWORD.EXE

Тестирование проводилось на полностью пропатченной Windows 7 SP1 Enterprise OS (32bit и 64bit) вместе с Microsoft Office Professional Plus 2010 (32bit) и Word’ом версии 14.0.7116.5000 (32bit). Ниже показан код, использующий ProgID otkloadr.WRAssembly.1.

{\rtf1{\object\objocx{\*\objdata
01050000
02000000
16000000
6f746b6c6f6164722e5752417373656d626c792e3100
00000000
00000000
01000000
41
01050000
00000000
}}}

Использование сторонних модулей

При тестировании других приложений, обнаружилось множество других ProgID, пригодных к использованию. Приложение ITunes и проигрыватель DivX содержат модули, которые могут быть загружены при помощи их ProgID. Однако эти модули используют адрес загрузки 0×10000000, и если по данному адресу уже загружен какой-то другой модуль, то происходит смена адреса. В Yahoo Messenger есть несколько ProgID, которые не изменяют адрес загрузки. Также я нашел несколько старых OCX файлов (без ASLR), установленных на другом компьютере сторонними приложениями или старым программным обеспечением от компании Microsoft. Вот некоторые «рабочие» ProgID: PicClip.PictureClip.1 (PICCLP32.OCX) и MSMAPI.MapiMessage.1 (MSMAPI32.OCX).

C:\Windows\System32\COMCT232.OCX
C:\Windows\System32\COMCTL32.OCX
C:\Windows\System32\COMDLG32.OCX
C:\Windows\System32\MCI32.OCX
C:\Windows\System32\MSCOMCT2.OCX
C:\Windows\System32\MSCOMM32.OCX
C:\Windows\System32\MSFLXGRD.OCX
C:\Windows\System32\MSINET.OCX
C:\Windows\System32\MSMAPI32.OCX
C:\Windows\System32\MSMASK32.OCX
C:\Windows\System32\MSWINSCK.OCX
C:\Windows\System32\PICCLP32.OCX
C:\Windows\System32\SYSINFO.OCX
C:\Windows\System32\TABCTL32.OCX

Способы защиты

Основной способ защиты – установка Microsoft EMET и добавление MSWord (WINWORD.EXE) в его список приложений. В EMET есть несколько способов для защиты от эксплоитов и, к тому же, он бесплатен. Другая полезная утилита - FixIT (тоже от компании Microsoft), при помощи которой можно сконфигурировать Microsoft Office File Block policy для предотвращения открытия файлов RTF. Также можно сконфигурировать блокировку файлов RTF вручную через настройку Trust Center.

File — Options — Trust Center — Trust Center Settings — File Block Settings

Рисунок 8: Настройка Trust Center для блокировки файлов RTF

После выставление флажка «Open», следует выбрать правило при открытии файла RTF.

При помощи опции «Do not open selected file types» выставляется полный запрет на открытие файла:

Рисунок 9: При открытии файла с запрещенным расширением, появляется соответствующее окно с сообщением о запрете

При помощи опции «Open selected file types in Protected View» файл открывается в изолированной среде (создается новый подчиненный процесс WINWORD.EXE).

Рисунок 10: Открытие файла в отдельной среде с повышенным уровнем безопасности

Ниже указаны настройки реестра, отвечающие за блокировку файлов.

Windows Registry Editor Version 5.00
;
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\FileBlock]
"RtfFiles"=dword:00000002
"OpenInProtectedView"=dword:00000001
;
; "RtfFiles"=dword:00000001 - Save checked
; "RtfFiles"=dword:00000002 - Open and Save checked
; "OpenInProtectedView"=dword:00000000 - Do not open selected file types
; "OpenInProtectedView"=dword:00000001 - Open selected file types in Protected View
; "OpenInProtectedView"=dword:00000002 - Open selected file types in Protected View and allow editing

По умолчанию не предусмотрено открытие большинство форматов документов, поддерживаемых MSWord, в защищенной среде, и если однажды будет найдена новая уязвимость, ваша система будет находиться под угрозой компрометирования. Учтите, что даже при блокировании расширения .rtf, злоумышленник может переименовать файл в расширение .doc, который также будет обрабатываться парсером, предусмотренным для формата RTF.

Заключение

Как вы могли убедиться, прочитав эту статью, обход защиты ASLR при помощи RTF-документов не вызывает особых затруднений. Потенциально существует огромное количество ProgID, использование которых может привести к компрометированию системы. До тех пор, пока производители программного обеспечения не начнут компилировать библиотеки с использованием опции /DYNAMICBASE, единственное надежное средство защиты - Microsoft EMET.

В zip архиве находятся некоторые примеры RTF-файлов, перечень ProgID сторонних приложений, vbs-скрипт и т. д.  

comments powered by Disqus