(Не)документированная особенность Word, используемая злоумышленниками

Некоторое время назад, в процессе исследования деятельности целевой атаки Freakyshelly, мы обнаружили spear-phishing рассылку писем с интересными вложенными документами. Это были файлы в формате OLE2, которые не содержали ни макросов, ни эксплойтов, ни какого-либо другого активного контента. Однако при детальном рассмотрении обнаружилось, что внутри них есть несколько ссылок на PHP-скрипты, расположенные на сторонних ресурсах. При попытке открыть эти файлы в Microsoft Word оказалось, что приложение обращается по одной из этих ссылок. В результате обращения злоумышленники получали информацию об установленном на компьютере ПО.

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

В нашем случае документ выглядел так:

На первый взгляд — ничего подозрительного, просто набор полезных советов на тему повышения эффективности при использовании поиска Google. В документе нет активного контента, нет VBA-макросов, вложенных Flash-объектов и PE-файлов. Но после того, как пользователь открывает документ, Word отсылает следующий GET-запрос по одной из внутренних ссылок. Мы взяли оригинальный документ, используемый в атаке, и заменили подозрительные ссылки на http://evil-*, вот что получилось:

Таким образом к атакующим попадала информация об установленном на машине ПО, в том числе версия Microsoft Office. Мы решили разобраться, почему Office переходит по указанной ссылке и как можно такие ссылки находить в документах.

Внутри документа Word

Первое, что бросается в глаза при рассмотрении документа, – поле INCLUDEPICTURE с одной из подозрительных ссылок. Но, как можно заметить, по факту Word обращается не по ней.

На самом деле блок данных на картинке выше — первый и единственный кусок текста в этом документе. Текст в документах формата Word находится в потоке WordDocument в «сыром виде», т.е. без какого-либо форматирования, за исключением так называемых полей. Поля говорят Word, что определенная часть текста должна быть показана при открытии документа специальным образом, к примеру, благодаря им мы видим активные ссылки на другие страницы документа, URL и т.п.  Поле INCLUDEPICTURE сообщает о том, что к определённым символам в тексте привязана картинка. Байт 0x13 (помечен красным) перед этим полем сигнализирует, что тут кончается «сырой текст» и начинается описание поля. Формат описания примерно таков (согласно [MS-DOC]: Word (.doc) Binary File Format):

Байт-разделитель 0x14 помечен желтым, а байт 0x15, говорящий об окончании поля, — розовым.

Ссылка на картинку в INCLUDEPICTURE должна быть в кодировке ASCII, но в данном случае она в Unicode, и поэтому Word ссылку игнорирует. Но после разделителя 0x14 идет байт 0x01 (помечен зеленым), говорящий о том, что для этой картинки есть так называемый заполнитель (placeholder), который «сообщает» редактору, что в это место должно быть вставлено изображение.  Вопрос: как его найти?

У символов и групп символов в тексте также имеются свойства, которые, как и поля, отвечают за форматирование (к примеру, они определяют, что какой-то кусок текста должен быть отображен курсивом). Свойства символов хранятся в двухуровневой таблице в потоках документа под названием xTable и Data. Не будем вдаваться в подробности разбора свойств символов – они имеют непростой формат, но в результате мы можем найти свойства символов со смещения 0x929 до 0x92C в потоке WordDocument:

Это как раз последовательность байт c picture placeholder’ом 0x14 0x01 0x15. В самом документе эти байты расположены по смещениям 0xB29 – 0xB2C, но поток WordDocument начинается со смещения 0x200, а смещения символов указаны относительно его начала.

Свойства группы символов CP[2] указывают на то, что к ним привязана некая картинка, которая расположена в потоке Data по смещению 0:

Этот вывод сделан с учетом того, что в значении поля INCLUDEPICTURE указан байт 0x01, который говорит о том, что картинка должна располагаться в потоке Data по соответствующему смещению. Если бы этот значение было другим, то нужно было бы либо искать картинку в другом месте, либо проигнорировать это свойство.

Как раз тут мы натолкнулись на недокументированное свойство. Описание поля INCLUDEPICTURE в документации MS фактически отсутствует, вот что там написано:

В стандарте ECMA-376 описана только часть INCLUDEPICTURE до байта-разделителя. Там нет ничего про то, что могут значить данные после него и как их интерпретировать. Это было основной проблемой в понимании того, что же все-таки происходит.

Итак, переходим в поток Data по смещению 0, там расположена так называемая форма SHAPEFILE:

Формы описаны в другом документе Microsoft: [MS-ODRAW]: Office Drawing Binary File Format. У нее есть имя, в данном случае оно тоже представляет собой другую подозрительную ссылку:

Но поскольку это просто имя объекта, ссылка никак не используется. В процессе разбора этой формы посмотрим на поле флагов (обведено красным):

Значение 0x0000000E раскладывается в комбинацию трех флагов:</p style=»»>

• msoblipflagURL 0x00000002
• msoblipflagDoNotSave 0x00000004
• msoblipflagLinkToFile 0x00000008

Это говорит о том, что к форме должны прилагаться дополнительные данные (на рисунке они обведены желтым). И что эти данные представляют собой URL, по которому уже расположено фактическое содержимое формы. Также есть флаг, который препятствует тому чтобы при открытии документа это содержимое сохранилось в самом документе – do not save.

Если посмотреть, что собой представляет этот URL, то мы обнаружим, что это та самая ссылка, по которой переходит Word при открытии документа:

Заметим, что кроме Word для Windows, эта «фича» присутствует в Microsoft Office для iOS и Android, а вот LibreOffice и OpenOffice ее не поддерживают: при открытии документа в этих офисных пакетах, обращения к ссылке не происходит.

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

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