Безопасность Microsoft Office: встраиваемые объекты

Изначально архитектура Microsoft Office строилась на основе концепции составных документов, они же документы OLE, активно продвигаемой Microsoft на заре 32-разрядных Windows. В те времена идея «бесшовного» объединения в одном документе данных самых разных форматов казалась заманчивой и увлекательной, и до выявления первых проблем успела прочно врасти во многие масштабные продукты.

«Плохая новость» заключалась в том, что универсальный способ добавления в документы данных (и кода обработки этих данных) стал универсальным путем появления в продукте уязвимостей, который и сегодня постоянно преподносит приятные сюрпризы создателям malware исследователям безопасности.

Впоследствии приложения пакета получили довольно богатый набор инструментов для добавления в документы изображений, графиков и схем, управляющих элементов, которые создаются и обрабатываются самим приложением и являются его частью. С точки зрения безопасности эти элементы представляют несколько меньший интерес, чем элементы, о которых (в основном) пойдет речь в статье — элементы, использующие код внешних приложений, добавляемые в документы при помощи OLE.

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

Формально встраиваемые в документы Microsoft Office объекты можно разделить на следующие группы:

• Управляющие элементы ActiveX (ActiveX Controls)
• Внедренные элементы данных OLE (OLE Embedded Objects)
• Внедряемые файлы (Packages)
• Встроенные элементы не-OLE

Управляющие элементы ActiveX

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

Встраиваемые в вебстраницы ActiveX представляли известную брешь в безопасности Internet Explorer, меры безопасности со временем усиливались. Браузеры других производителей практически сразу отказались от поддержки ActiveX. Новый браузер Microsoft Edge окончательно расстался с этим пережитком прошлого. Встраивание в документы Office, однако, все еще возможно.

ActiveX в документах предназначены для использования в связке с Visual Basic for Applications. Тем не менее, для их загрузки и активации VBA не требуется, а для загрузки элементов из «белого списка» не требуется и разрешение пользователя.

Уязвимости в последних особенно опасны — настройки по умолчанию, задаваемые при установке приложения, не предполагают ни какой-либо защиты от загрузки этих элементов, ни предупреждения пользователя. Администратору необходимо принудительно ужесточить настройки, запретив загрузку любых элементов ActiveX (отметим однако, что в режиме безопасного просмотра ActiveX не загружаются).

Пример: CVE-2012-0158

Одной из самых опасных уязвимостей в документах Office в 2012 году была CVE-2012-0158. Код загрузки элемента Microsoft ListView Control 6.0 из библиотеки MSCOMCTL.OCX содержал возможность переполнения буфера, что позволяло подменить адрес возврата и выполнить произвольный код. Поскольку элемент находился в «белом списке» ActiveX, загрузка начиналась сразу же при открытии документа. На текущий момент уязвимость устранена, элемент ListView Control по-прежнему считается «безопасным».

Добавление ActiveX в документ

Для добавления управляющего элемента в документ Microsoft Office (для простоты возьмем Word) при помощи интерфейса пользователя необходимо открыть вкладку «Разработчик» (ее видимость настраивается в меню «Параметры Word») и выбрать Элементы управления -> Инструменты из предыдущих версий -> элементы ActiveX. Меню продемонстрирует набор значков, соответствующих элементам Microsoft Forms, а также возможность выбрать ActiveX из списка, составленного из имеющихся в системе элементов, отобранных по ряду критериев.

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

Программное представление

Каждый элемент ActiveX по сути является объектом одного из классов COM, отвечающих определенным требованиям. Загрузка элемента происходит при помощи подсистемы COM, а исполняемый код содержится в одном из модулей, как правило, «внешних» по отношению к приложению-контейнеру. Как и любой COM-объект, элемент ActiveX может быть реализован в виде библиотеки DLL, или же в виде исполняемого EXE-файла. В первом случае библиотека будет загружена в адресное пространство контейнера, во втором — элемент будет обрабатываться в отдельном процессе, с передачей данных между контейнером и объектом посредством COM-маршалинга.

Как и любой объект COM, ActiveX имеет Интерфейсы, Свойства и Методы.

Интерфейсы — это прежде всего набор стандартных интерфейсов, которые обязан иметь класс ActiveX для полноценной загрузки и взаимодействия с контейнером, в частности, IOleControl и IOleObject.

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

Пример: CVE-2015-2424
Уязвимость CVE-2015-2424 была связана с элементом TaskSymbol Class из библиотеки mmcndmgr.dll. Элемент не был предназначен для использования в документах, и не экспортировал интерфейс IDispatch. В процессе загрузки элемента запросившая этот интерфейс процедура получала ошибку и разрушала внутреннюю структуру элемента, что приводило к уязвимости типа use-after-free. На данный момент элемент запрещен к загрузке (несмотря на это, его все еще можно обнаружить в списке для добавления в меню «Разработчик»). Сама уязвимость не устранена.

Помимо стандартных, каждый класс ActiveX экпортирует «основной» интерфейс, представляющий его собственную уникальную функциональность. К примеру, для класса Forms.CommandButton.1 это ICommandButton.

Просматривать интерфейсы ActiveX можно при помощи инструмента OleView, входящего в пакет Microsoft Visual Studio.

Интерфейс элемента определяет его Методы и Свойства. Свойства представляют некоторые данные, определяющие вид и работу элемента. Разработчик ActiveX-элемента присваивает каждому свойству определенное имя, скажем BackColor или GridLineWidth, и тип, например, строка, целое или вещественное двойной точности. Для растровых изображений и значков существует такой тип свойства, как картинка. Клиентская программа может устанавливать отдельные свойства элемента управления, задавая их целочисленные индексы и значения.

С точки зрения низкоуровневой реализации деление на методы и свойства формальное, поскольку «свойства» представлены набором методов get/set. Однако есть и значимое отличие: Методы элемента (его основного интерфейса) могут быть вызваны только программно, в случае документов Office — только из выполняющейся программы VBA. С точки зрения безопасности это не представляет большого интереса, так как исполнение VBA это уже компрометация операционной системы. Свойства же сохраняются в документе и при его открытии будут обработаны и загружены в структуры в памяти даже если исполнение VBA запрещено.

С программной точки зрения, со стороны элемента для сохранения его свойств и состояния в документе контейнер предоставляет интерфейсы IStream, IStorage и IPropertyBag. Их реализация и представление данных в дисковом файле уже не забота элемента ActiveX, и целиком зависит от контейнера и формата документа. Нужно заметить, что набор и формат сохраняемых данных может соответствовать «публично» экспортируемому набору свойств, а может быть и совершенно иным. Рассмотрим примеры реализации, имеющие отношение к Microsoft Office.

Составной файл (compound file, CFBF)

Устаревший формат документов Office, где для хранения данных ActiveX выделялось хранилище нижнего уровня ObjectPool и отдельные подкаталоги внутри него. Поток "01CompObj" содержит идентификатор класса, который в конечном итоге и определяет класс загружаемого объекта. Замена идентификатора непосредственно в hex приведет к попытке загрузки объекта совсем другого класса.

Office Open XML

Современный XML формат документов. Файл представляет собой zip-архив. Данные элементов ActiveX хранятся в подкаталоге ActiveX в файлах с немудреными названиями типа activeX1.xml.

Пример файла:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ax:ocx ax:classid="{D7053240-CE69-11CD-A777-00DD01143C57}" ax:persistence="persistPropertyBag" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
<ax:ocxPr ax:name="Caption" ax:value="CommandButton1"/>
<ax:ocxPr ax:name="Size" ax:value="2540;847"/>
<ax:ocxPr ax:name="FontName" ax:value="Calibri"/>
<ax:ocxPr ax:name="FontHeight" ax:value="225"/>
<ax:ocxPr ax:name="FontCharSet" ax:value="204"/>
<ax:ocxPr ax:name="FontPitchAndFamily" ax:value="2"/>
<ax:ocxPr ax:name="ParagraphAlign" ax:value="3"/>
</ax:ocx>

В этих файлах в текстовой форме указаны идентификаторы классов. Замена идентификатора также вызовет попытку загрузки элемента другого класса.

Далее файл содержит указание на тип хранения данных объекта: persistPropertyBag, persistStorage или persistStream. Если элемент поддерживает хранение свойств persistPropertyBag, его данные могут быть сохранены в том же текстовом файле, см. пример выше. Если же ему необходимо хранилище или двоичный поток, данные будут сохранены в файле с именем типа activeX1.bin, представляющем собой файл CFBF.

RTF

В документе rtf элемент ActiveX определяется тэгами objectobjocx. Тэг objdata содержит хранилище свойств элемента в виде hex-представления файла CFBF.

{objectobjocxf37objsetsizeobjw1440objh480{*objclass Forms.CommandButton.1}
{*objdata 010500000200000016000000
466f726d732e436f6d6d616e64427574746f6e2e31000000000000000000000e0000
d0cf11e0a1b11ae1000000000000000000000000000000003e000300feff090006

Загрузка из файла

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

Фильтрация элементов, которые могут быть загружены, имеет множество этапов. Прежде всего отсеиваются классы, указанные в черном списке, известном как Office COM Kill Bit (подветка реестра *OFFICE_KEY*CommonCOM Compatibility). К примеру, флаги, предотвращающие загрузку, имеют такие классы как Microsoft Scriptlet Component и Microsoft Web Browser.

Остальные классы пройдут первоначальную загрузку. Это означает, что библиотека DLL будет загружена в приложение-контейнер, или же будет запущен процесс COM-сервера, реализованного в EXE-файле. Только после этого будут выполняться остальные проверки, включая элементарную — а является ли объект, собственно, представителем ActiveX.

Пример: CVE-2015-6128
В 2015 году исследователь обнаружил, что предварительную загрузку модулей COM можно использовать для обхода ASLR и выполнения произвольного кода за счет загрузки подложных динамических библиотек. В описании вышедшего впоследствии CVE-2015-6128 нет ни слова о Microsoft Office.

Если идентификатор действительно определяет ActiveX, он пройдет еще несколько проверок в нескольких черно-белых списках.

Можно видеть, что значительное место в списке занимают компоненты группы Microsoft Forms. Это набор управляющих элементов, поставляемых с пакетом Office, вы можете видеть их на панели «элементы ActiveX». Изначально все они регистрировались как «безопасные», но со временем выяснилось, что для отдельных элементов это не так. К примеру, элемент Frame загружает любые другие ActiveX, не проверяя никаких списков (в последних версиях это «исправлено», но собственный блэклист Frame отличается от общего Office). По этой причине часть элементов Microsoft Forms может быть загружена в документ только с разрешения пользователя. Microsoft Forms Frame также требует согласия пользователя (при настройках по умолчанию), зато позволяет загрузить некоторые элементы из Kill Bit списка, которые не могли бы быть загружены при других условиях.

Следовательно, если атакующему удается убедить пользователя разрешить загрузку ActiveX, Frame поможет ему существенно расширить «арсенал» за счет таких элементов как, например Web Browser.

Формат хранения свойств Microsoft Forms частично документирован спецификацией [MS-OFORMS].

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

Многие популярные приложения дополняют эти списки собственными ActiveX. В случае обнаружения уязвимости она будет отражена в бюллетене как имеющая отношение к приложению в состав которого входит. При этом единственным путем эксплуатации уязвимости могут оказаться документы Office.

Пример: Flash ActiveX
Flash ActiveX особенно полюбился вирусописателям за стабильно обнаруживаемые уязвимости и постоянное место в «белых списках» IE и Office. Первые известные уязвимости в этом компоненте появились еще в 2008 году, одна из последних CVE-2018-4878 закрыта в феврале этого года. С угасанием популярности IE документы Office стали основным путем распространения эксплойтов для Flash.

Внедряемые элементы данных OLE

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

Добавить OLE-элемент в документ Word можно следующим образом: открыть вкладку «Вставка» и выбрать Текст -> Объект. Программа выведет список типов документов, для которых зарегистрированы OLE-обработчики. Как и в случае с ActiveX, этот список мало соответствует набору классов, которые действительно могут быть загружены в качестве документов OLE.

Программное представление

Как и в случае ActiveX реализация любого OLE-документа представлена соответствующим классом COM, выполненным в виде DLL или EXE. Компонент экспортирует необходимые служебные интерфейсы, а сохранение состояния в документе-контейнере выполняется посредством интерфейсов IPersist*.

В документе формата CFBF данные объектов OLE сохраняются в хранилище второго уровня ObjectPool. Набор потоков в целом похож на соответствующий элементам ActiveX.

В документах Open Office XML данные объекта OLE сохраняются в подкаталоге embeddings, в файле-хранилище CFBF с именем типа oleObject1.bin.

В документах RTF информация об объекте сохраняется под тэгом objectobjemb. Раздел содержит также хранилище, закодированное как hex-представление файла CFBF.

{objectobjembobjw8307objh553{*objclass WordPad.Document.1}
{*objdata 010500000200000013000000576f72645061642e446f63756d656e742e31000000000000000000000a0000
d0cf11e0a1b11ae100000000


Формат RTF выделяется тем, что поддерживает тэг objupdate, вызывающий автоматическую активацию элемента в то время как по умолчанию OLE-элементы неактивны при загрузке.

Пример: CVE-2017-11882
Уязвимость CVE-2017-11882 OLE компонента Equation Editor благодаря обработке объекта в отдельном процессе давала возможность стабильной и универсальной эксплуатации. Тэг objupdate заставлял Word загружать уязвимый компонент сразу при открытии документа.

Пример: встроенные элементы Excel с макровирусом
Исследователями обнаружены вредоносные rtf-документы, не использующие никаких новых уязвимостей. Документы содержат в качестве встроенных объектов несколько документов Excel с макросом. Расчет сделан на то, что пользователь, вынужденный после открытия документа несколько раз подряд отказываться от выполнения макроса, в итоге «сдастся» и разрешит выполнение. На данный момент техника все еще работает.

Значительное отличие от ActiveX в случае внедряемых элементов OLE состоит в том, что идентификатор класса записывается непосредственно в файл хранилища функцией WriteClassStg. Эта методика унаследована из очень давних времен, когда в Microsoft увлеченно развивали концепцию «сериализации» и хранения объектов с их состоянием в формате CFBF. Документ-контейнер также сохраняет идентификатор класса внедряемого элемента, но загружен будет объект именно того класса, который указан в хранилище. Этот идентификатор возможно заменить, заставив приложение загрузить объект вовсе не предназначенный для этих целей.
Возможно отредактировать и данные элемента, что в определенных случаях приводит к выявлению уязвимостей.

Объекты OLE также проходят многочисленные проверки на возможность загрузки, что затрудняет получение полного списка потенциально загружаемых элементов. Набор элементов, которые могут быть загружены как объекты OLE, отличается от списка загружаемых ActiveX. В частности, проверку они проходят по KillBit списку принадлежащему не Office, а Internet Explorer (HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerActiveX Compatibility).

OLE по ссылке

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

Пример: CVE-2017-0199
Уязвимость CVE-2017-0199 заключалась в возможности добавления в документ «объекта по ссылке» формата hta. Последний представляет собой html с возможностью выполнения кода, то есть, фактически является исполняемым файлом. Обработчик автоматически скачивал и выполнял hta, позволяя выполнить произвольный код при открытии документа.

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

Внедряемые файлы (Packages)

Документы Office поддерживают возможность добавления любого файла (Объект -> Создание из файла или просто перетащить иконку файла в поле редактирования). Технически это реализовано добавлением в документ встраиваемого элемента Object Packager, записывающего в собственные данные желаемый файл. Object Packager позволяет заменить иконку и подпись файла, а также задать командную строку для открытия. Может он включать и файлы «по ссылке», когда открытие файла происходит не из собственного хранилища, а по указанному пути, в том числе и сетевому.

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

Пример: файлы в теле сообщения Outlook
Сообщения Outlook, которые также являются составными документами, позволяют добавлять элементы Object Packager в тело письма. Для пользователя элемент выглядит как изображение, произвольно выбранное злоумышленником. Двойной клик по изображению открывает упакованный файл. Злоумышленнику остается подобрать тип данных из тех, что еще не попали под ужесточение политик безопасности.

Встроенные элементы, реализованные не с помощью OLE

На данный момент наибольшую угрозу/интерес из не-OLE элементов могут представлять изображения, добавляемые в документ по ссылке. При открытии документа не в защищенном режиме изображения скачиваются автоматически, что может приводить к раскрытию местоположения и личности пользователя, скачавшего документ через анонимизирующие прокси или получившего конфиденциальный документ из третьих рук. Эта методика, в частности, была реализована в инструменте Scribbles, находящемся на вооружении спецслужб США.
В локальной сети Windows автоматическое скачивание изображений по ссылке делает возможной эксплуатацию уязвимости NTLMRelay. Механизм ссылок на картинки не совместим с требованиями безопасности сетей ActiveDirectory, поскольку администратор, получающий подобный документ по сути исполняет код злоумышленника с полными административными привилегиями.

Методы защиты

Что можно сделать? В целом, немного.

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

Управляющие элементы ActiveX можно отключить в настройках Trust Center

Обратите внимание, что для встроенных элементов OLE это не работает.

Автор: ormoulu

Источник