Microsoft word application dcom

Время на прочтение
10 мин

Количество просмотров 6.8K

Программы электронного документооборота совершили настоящий прорыв, значительно облегчив работу офисных сотрудников. Но вскоре стало понятно, что можно продвинуться еще дальше, автоматизировав рутинные действия пользователей. У программируемых офисных приложений было явное преимущество на рынке. Visual Basic For Applications не удовлетворял всех потребностей: требовалась поддержка различных «внешних» языков, в том числе и скриптовых.

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

Конечно же, в основу новой программной платформы, которую назвали объектная модель (Microsoft Office Object Model), или Автоматизация Microsoft Office (Microsoft Office Automation), легла технология COM/OLE (последняя, в свою очередь, разрабатывалась в немалой степени с оглядкой на потребности пакета Office).

Вкратце суть технологии автоматизации Office можно описать следующим образом: сами приложения, их детали (например, меню или настройки безопасности), открытые документы и содержимое документов представляют собой для программы-клиента набор объектов, имеющих определенные свойства и методы. Например, объект Приложение может иметь свойство Коллекция Документов, отдельный Документ из которой имеет свойство Текст и метод Найти.

Объекты Microsoft Office доступны не только из макросов, но и из внешних программ на любых языках, поддерживающих COM. Последние могут быть компилируемыми программами на языках C++ или Delphi, управляемыми приложениями на Java или .Net, или же скриптами на VBScript и PowerShell.

try {
    using namespace Word;

    _ApplicationPtr word(L"Word.Application");
    word->Visible = true;
    word->Activate();

    _DocumentPtr wdoc1 = word->Documents->Add();
    RangePtr range = wdoc1->Content;
    range->LanguageID = wdRussian;
    range->Tables->Add(range,5,5);

    wdoc1->SaveAs(&_variant_t("C:\1test.doc"));
    wdoc1->Close();
}
catch (_com_error& er) {}

Пример использования на C++

$word = New-Object -ComObject "Word.application"
$word.Visible = $true
$document = $word.documents.Add()
$selection = $word.selection
$selection.font.size = 14
$selection.font.bold = 1
$selection.Style ="Title"
$selection.typeText("Nice Title")
$selection.ParagraphFormat.Alignment = "wdAlignParagraphCenter"

Пример использования на PowerShell

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

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

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

msoAutomationSecurity

С автоматизацией связан интересный момент, упоминавшийся ранее. Настройки безопасности приложений (те, что определяют возможность автозапуска макросов и другого активного содержимого из документов) в программной модели Office определяются переменной-«свойством» Application.AutomationSecurity. По умолчанию это свойство имеет значение msoAutomationSecurityLow, что позволяет запуск любого активного содержимого из открываемых автоматически документов. Настройки безопасности, выставленные пользователем в Trust Center или администратором при помощи административных шаблонов, сохраненные в реестре, не оказывают влияния на настройки безопасности приложений Microsoft Office, запущенных в режиме автоматизации. Для безопасной автоматической обработки документов свойство AutomationSecurity должно быть целенаправленно изменено программно во время исполнения.
Такая небольшая деталь может иметь огромное значение для компаний, в которых настроена автоматическая обработка получаемых извне (по электронной почте, из облачных хранилищ и т.п.) документов.

Доступ к объектной модели VBA

Как и для большинства других элементов приложений Microsoft Office,
возможность управления и модификации проектов и кода Visual Basic for Applications программным путем доступна через интерфейсы автоматизации. По умолчанию она отключена для повышения безопасности пакета и защиты от макровирусов. При попытке программно создать объект, имеющий отношение к VBA, вызывающей программе вернется ошибка:

Error: 6068
Programmatic access to Visual Basic Project is not trusted.

Если пользователю все же необходим программный доступ к VBA, он может разрешить эту возможность в настройках Trust Center:

Недостаток этого решения в том, что заданная таким образом настройка сохраняется в ветке реестра, доступной пользователю для модификации, например для Microsoft Word это:

HKEY_CURRENT_USERSoftwareMicrosoftOffice >> Версия Office << WordSecurityAccessVBOM

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

'получаем версию Office и путь к ключу реестра AccessVBOM
Set objWord = CreateObject("Word.Application")
dim regpath
regpath = "HKCUSoftwareMicrosoftOffice" & objWord.Version & "WordSecurityAccessVBOM"

objWord.Quit
'пауза для закрытия предыдущего экземпляра Word
WScript.Sleep 1000

'записываем значение, открывающее программный доступ к проектам VBA
Set myWS = CreateObject("WScript.Shell")
myWS.RegWrite regpath, 1, "REG_DWORD"

'получаем запущенный экземпляр Word...
On Error Resume Next
Set objWord = GetObject(,"Word.Application")
If Err Then
'...или создаем новый
    wscript.echo "app not running, starting..."
    Set objWord = CreateObject("Word.Application")
    objWord.Visible = True
    objWord.Documents.Add()
End If
Err.Clear


Set objDoc = objWord.ActiveDocument

On Error Resume Next
set prj = objDoc.VBProject
If Err Then

    wscript.echo "Error: " & Err.number & Err.Description

End If
Err.Clear
prj.VBComponents("ThisDocument").CodeModule.AddFromString ("Sub AutoOpen()"&vbCRLF&"MsgBox ""Hello world!"""&vbCRLF&"End Sub")

Настройка программного доступа к VBA может определяться также ключами реестра

HKLMSoftwareMicrosoftOffice>> Версия Office <<WordSecurityAccessVBOM

и

HKLMSOFTWAREPoliciesMicrosoftOffice>> Версия Office <<WordSecurityAccessVBOM

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

Удаленное выполнение/DCOM

Технология COM изначально проектировалась в расчете на прозрачность местоположения: вызываемые компоненты могут являться библиотеками (DLL), загружаемыми в вызывающий процесс, либо в отдельный процесс-прокси, локально исполняемыми программами (EXE) или компонентами, расположенными на каком-либо другом компьютере (DCOM).

В зависимости от настроек методы вызова конкретного компонента могут быть различными, причем это может быть реализовано прозрачно и для клиента, и для сервера. Определенные изменения в реестре могут сделать любой зарегистрированный в системе компонент доступным для удаленного управления, в том числе анонимного. Однажды получив доступ к уязвимой системе, в дальнейшем злоумышленник может воспользоваться этой технологией для выполнения каких-либо действий от имени легального пользователя без необходимости сохранять на диске какие-либо исполняемые или интерпретируемые программы. Что касается Microsoft Office, то возможные действия включают чтение, создание и редактирование документов, добавление макросов и другого активного содержимого, чтение и рассылку электронной почты, получение содержимого адресной книги Outlook.

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

Для настройки вручную необходимо выполнить следующие шаги:

1. открыть порт DCOM в брандмауэре и добавить Microsoft Word в список разрешенных программ
2. при помощи утилиты Dcomcnfg настроить удаленный доступ для компонента Microsoft Word 97 — 2003 Document

Один из этапов настройки компонента DCOM для Word

Естественно, те же настройки можно выполнить и программно.
Таким образом, объектная модель Microsoft Word доступна для удаленного управления.

hr = CoCreateInstanceEx (CLSID_Word,
                         NULL,
                         CLSCTX_REMOTE_SERVER,
                         &si, 1, rgmqi);
IUnknown* pUnknown = 0;
if (hr == S_OK)
{
    pUnknown  = (IUnknown*)rgmqi[0].pItf;
    printf ("CoCreateInstanceEx OKn");
}
else
{
    printf ("CoCreateInstanceEx failed, error: 0x%Xn", hr);
    return;
}

_Application* pApp;
hr = pUnknown->QueryInterface(__uuidof(_Application), (void**)&pApp);
pUnknown->Release ();
if(FAILED(hr))
{
    printf ("QueryInterface (_Application) failed, error: 0x%Xn", hr);
    return;
}
printf ("DCOM server on remote machine started!n");
WCHAR* wszDocFileName = L"C:\Users\administrator\Desktop\important.docx";
VARIANT varResult;
DISPPARAMS dp = {0};
dp.cArgs = 1;
dp.cNamedArgs = 0;
dp.rgvarg = new VARIANT[dp.cArgs];
dp.rgvarg[0].vt = VT_BSTR;
dp.rgvarg[0].bstrVal = SysAllocString (wszDocFileName);
ZeroMemory(&varResult,sizeof(varResult));
hr=CallMethod(pApp->Documents,OLESTR("Open"),&dp,&varResult);
SysFreeString(dp.rgvarg[0].bstrVal);
delete []dp.rgvarg ;
IDispatch* IDWordDoc = varResult.pdispVal;
struct _Document * Copy = NULL;
IDWordDoc->QueryInterface (__uuidof(_Document), (LPVOID*)&Copy);
RangePtr pContent = Copy->Content;
printf (pContent->Text);
Copy->Close ();
pApp->Quit ();

Пример кода для Visual Studio, читающего содержимое заданного файла на удаленном компьютере

Отслеживание действий пользователя/События

Для отслеживания изменений в программах Microsoft Office объектная модель предоставляет стандартную для COM технологию точки соединения (Connection Points), экспортируя интерфейс IConnectionPointContainer. Поддерживаются различные типы событий: открытие, закрытие, сохранение документа, отправка почтовых сообщений, и т.д.
Подписаться на уведомления о событиях могут как подключаемые модули (плагины), так и клиенты автоматизации, работающие вне процесса программы Microsoft Office. Помимо легальных программ, призванных автоматизировать работу пользователя с документами, воспользоваться этой функциональностью скрыто может и вредоносное ПО.

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

CoInitializeEx(NULL, COINIT_MULTITHREADED);

CLSID    CLSID_Word;
hr = CLSIDFromProgID(L"Word.Application",&CLSID_Word);
    IUnknown* pUnk = NULL;
do {
    hr = GetActiveObject (CLSID_Word, NULL, &pUnk);
    Sleep (500);
    }
while (hr != S_OK);
hr = OleRun(pUnk);
IConnectionPointContainer *pConnPtContainer;
hr = pUnk->QueryInterface(IID_IConnectionPointContainer,
                                        (void **)&pConnPtContainer);
IConnectionPoint *pConnectionPoint;
hr = pConnPtContainer->FindConnectionPoint(__uuidof(Word::ApplicationEvents2),
                                                                  &pConnectionPoint);
MyEventSink MySink;
DWORD dwSinkCookie =0;
hr = pConnectionPoint->Advise (&MySink, &dwSinkCookie);
pConnPtContainer->Release();

Применение для закрепления/выполнения кода в уязвимой системе

В пентестерской (и не только) практике иногда появляется необходимость оставить возможность доступа к компьютеру, которая не вызовет подозрений у пользователя или администраторов и не будет обнаружена антивирусом. Компонентная модель Office прекрасно подходит для таких целей. Хорошие описания некоторых вариантов составил Matt Nelson (@enigma0x3) (Excel, Outlook).

В первом случае используется программный доступ к Excel для запуска макроса, во втором Outlook для запуска произвольного приложения.

Предупреждения Outlook

Объектная модель Microsoft Outlook очень удобна для создателей malware тем, что позволяет легко редактировать и распространять почтовые сообщения, добавлять вложения, использовать адресную книгу, выполняя эти действия от лица легального пользователя. Также она дает возможность отслеживать действия пользователя, изменяя, например, созданное пользователем сообщение в момент отправки.

Использование возможностей DCOM позволяет производить эти действия удаленно, не сохраняя на уязвимом компьютере какой-либо исполняемый код, который может быть обнаружен антивирусными программами.

Для снижения вероятности использования программных интерфейсов Microsoft Outlook злонамеренным ПО, разработчики добавили пользовательские сообщения о программном доступе к Microsoft Outlook при попытках изменения или отправки сообщений, доступа к адресной книге.

Пользовательское сообщение о программном доступе к Microsoft Outlook

По умолчанию сообщение будет появляться только в том случае, если антивирусное ПО не установлено. То есть при установленном и обновленном антивирусе Outlook уже не будет предупреждать пользователя о подозрительной активности. Дело за малым — осуществить задуманное, не привлекая внимания антивируса.

В реестре эта опция сохраняется в подключе Security программы Microsoft Outlook, к примеру для Microsoft Office версии 2016 32-битной с платформой ClickToRun полный путь ключа:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftOfficeClickToRunREGISTRYMACHINESoftwareWow6432NodeMicrosoftOffice16.0OutlookSecurity

Чтобы отключить предупреждения о подозрительной программной активности, необходимо добавить значение:ObjectModelGuard (DWORD) 0x2.
Изменить эти настройки в последних версиях Microsoft Office возможно средствами группового администрирования, либо через реестр. Возможность менять их через пользовательский интерфейс по умолчанию отключена.

В заключение

Ни одна из описанных выше особенностей Microsoft Office не является в полном смысле этого слова уязвимостью, а следовательно, и исправления их вряд ли стоит ожидать в обозримом будущем. Что может предпринять в этом случае бдительный системный администратор?
Если используется автоматизированная обработка документов Office, особенно из недоверенных источников, желательно убедиться, что настройки безопасности выставлены верно. Это можно сделать «скормив» автоматизированной системе документ с макросом. Заметим, что использование автоматизации может быть неочевидным, к примеру, сторонняя программа может вызывать приложения Microsoft Office для импорта данных из форматов .docx или .xlsx.
Желательна тщательная настройка пакета при помощи административных шаблонов.
Избежать серьезных последствий поможет обычное разграничение прав доступа, работа с Office исключительно из-под аккаунта, имеющего пользовательские привилегии. Брандмауэр и User Access Control — непременное условие безопасности Windows.
Полностью отключить автоматизацию, не нарушив функциональность пакета Microsoft Office, практически невозможно.

If you’ve stumbled upon this post you’re most likely dealing with the Microsoft Office primary interop assemblies (PIAs), also known as Microsoft.Office.Interop library set. This is a neat collection of libraries, released by Microsoft through NuGet, which can be used to programmatically access — open, edit, save, create and so on — Microsoft Office files such as: xls / xlsx (Excel), doc / docx (Word), mdb (Access) and so on.

In case you also need a tutorial / coding sample about how to implement Microsoft.Office.Interop library set in a typical ASP.NET C# application, we suggest to read this post: here we’ll take for granted that you’ve already did something like that and you’re trying to publish it onto a production IIS server machine — arguably, without success.

The problem(s)

As soon as you install these assemblies in your developer machine you’ll be able to deal with the Office files without issues. However, when you’ll eventually want to publish your efforts in a production server (Windows Server + IIS), you might deal with one of the following errors:

System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

or:

System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access denied. (Eccezione da HRESULT: 0x80070005 (E_ACCESSDENIED))

or:

System.Runtime.InteropServices.COMException: The message filter indicated that the application is busy. (Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER))

or:

System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

or:

System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file

These are the most common errors you might encounter when dealing with Microsoft.Office.Interop: luckily enough, there’s a quick solution for each one of them.

The Fix(es)

Let’s start with the easy one.

80040154 Class not registered

If you’re hitting the 80040154 Class not registered error, it probably just means that Microsoft Office isn’t installed on your IIS server machine. Yeah, that’s about it! If you thought that you could avoid installing it, you were wrong: a locally-installed instance of Microsoft Office is required to use the Microsoft.Office.Interop libraries, because they basically launch the actual MS Office apps in background to handle the calls.

As a matter of fact, they also do that in an highly-inefficient way, often messing up with the multi-thread context of a typical Web Application — that’s why you should use
lock ,
Monitor.TryEnter  or other similar methods to synchronize access to these kind of calls. We won’t expand such topic here any further, but you can see a sample lockers implementation / tutorial / code sample in this post.

80070005 Access denied

This error basically means that the web site is definitely finding the COM objects related to the MS Office application you want to execute, but the Application Pool in charge of the running process doesn’t have permissions to use them. In order to fix that, follow these steps:

• Open IIS Manager > Application Pools and identify the identity assigned to the Application Pool assigned to the web application (it’s in the Advanced Properties tab). Keep a note of that user (or system) account, because you’ll need it later on. If you fond the ApplicationPoolIdentity there, you need to do some little extra-work: as you might know, that user it’s a dynamically created, unprivileged account: to change its permissions in the following steps, you’ll need to look-up for the IIS AppPool[AppPoolName] role. If that’s too much for you to handle, you can change the identity to a «static» account… but you shouldn’t do that, as the ApplicationPoolIdentity usage is a best practice to deal with IIS7+ / IIS8+ Application Pools in a secure way. For additional info on that topic, read this StackOverflow thread.
• Launch the
  dcomcnfg  command from Windows > Start > Run or from a command-prompt: go to Component Services > Computers > My Computer > DCOM Config, then locate the various «Microsoft XYZ Document» and/or «Microsoft XYZ Application» entries, where XYZ are Word, Excel and/or Access — depending on what you need to access programmatically from your ASP.NET web application: you’ll need to perform the following tasks for each one of them.
• Right-click the entry and select Properties:
  • Go to the Identity tab, where you’ll see three radio buttons: The Interactive User, The Launching User and This User. Select This User, then put the credentials of the account who installed MS Office — or an administrative account.
  • Go to the Security tab, where you’ll find three group boxes: for the first two of them — Launch and Activation Permissions and Access Authorization —  select the Customize radio button, then add the same identity that runs your web site’s Application Pool — the one which you took note of few minutes ago. In some scenarios, depending on the Windows Server version, you’ll also need to add the IUSR and IUSR_[MACHINENAME] accounts.

IMPORTANT: in case the DCOM Config panel does not contain any «Microsoft XYZ Document» and/or «Microsoft XYZ Application«, it’s most likely due to the fact that a 32-bit MS Office version has been installed on a 64-bit server machine: if that’s the case, we’ll need to launch the snap-in in 32-bit mode by using the following command:

For additional info regarding this topic, you can take a look at this MS TechNet article.

RPC_E_SERVERCALL_RETRYLATER

This error message is strictly related to the fact that we’re trying to use the Microsoft.Office.Interop libraries in a multi-thread environment: if you see this, it probably means that two (or more) users are trying to create an instance of the same Office.Interop object, which cannot be done. The fix is to just implement a way to queue such requests by using  
lock ,
Monitor.TryEnter  or other similar methods (see this post for a quick implementation / code sample).

The RPC server is unavailable

The error 0x800706BA usually happens when the RPC Locator / RPC Endpoint Mapper windows service is not running. To fix that, just open Control Panel > Administrative Tools > Services and manually launch it. In case this is enough to fix your issue, remember to switch its starting behavior from Manual to Automatic to prevent your Web Application’s interop-based feature from ceasing to work (again) upon the next machine reboot.

0x800A03EC Cannot access the file

The 0x800A03EC Cannot access the file is arguably the worst error you can experience, as the given error message is completely misleading. To fix that, you have to do the following:

• Create the following new folders on your Windows Server + IIS machine:
  • C:WindowsSysWOW64configsystemprofileDesktop (for 64-bit Servers only)
  • C:WindowsSystem32configsystemprofileDesktop (for both 32-bit and 64-bit Servers)
• Set Full control permissions for these Desktop folders for the Application Pool user (IIS AppPoolDefaultAppPool if you’re using the ApplicationPoolIdentity dynamic account).

That’s it for now: I sincerely hope that this post will help most developers who’re struggling against the adversities of the dreadful Microsoft.Office.Interop ASP.NET library package!

Conclusion

That’s it: we hope that this post will help other software developers to get rid of these nasty interop-based issues: if you found this post useful for your scenario, don’t forget to let us know in the comments section below (and like us on Facebook and Twitter, if you don’t mind): doing that won’t cost you a penny, and will greatly help us to keep writing these guides. Thanks in advance!

Знаю, что legacy, и что надо отказываться, но пока нет возможности. В общем, ситуация такая, что нужно на сервере создать Com Объект Word.Application, а он, зараза, не создается (-2147467262(0x80004002): Интерфейс не поддерживается).

Я добавил пользователя USR1CV8 в группу «Пользователи DCOM»

Дал этому юзеру права на DCOM приложение «Документ Microsoft Word 97–2003» (ОС на сервере 64х битная, сервер 1С 32х битный, поэтому давал права через оснастку mmc comexp.msc /32)

Создал папку Desktop в WindowsSystem32configsystemprofile и дал на нее права

А он, зараза, все равно не создается. Хотя процесс winword запускается на сервере.

Аналогичные действия для Экселя (DCOM приложение «Microsoft Excel Application») помогли — COM-интерфейс экселя нормально создается и функционирует.

Если включить пользователя USR1CV8 в группу Администраторы, DCOM приложение Word’а работает нормально (!) Но, понятно, хотелось бы решить проблему нормально, а не такими радикальными методами.

Вот на что еще ему надо права дать?

Программы электронного документооборота совершили настоящий прорыв, значительно облегчив работу офисных сотрудников. Но вскоре стало понятно, что можно продвинуться еще дальше, автоматизировав рутинные действия пользователей. У программируемых офисных приложений было явное преимущество на рынке. Visual Basic For Applications не удовлетворял всех потребностей: требовалась поддержка различных «внешних» языков, в том числе и скриптовых.

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

Конечно же, в основу новой программной платформы, которую назвали объектная модель (Microsoft Office Object Model), или Автоматизация Microsoft Office (Microsoft Office Automation), легла технология COM/OLE (последняя, в свою очередь, разрабатывалась в немалой степени с оглядкой на потребности пакета Office).

Вкратце суть технологии автоматизации Office можно описать следующим образом: сами приложения, их детали (например, меню или настройки безопасности), открытые документы и содержимое документов представляют собой для программы-клиента набор объектов, имеющих определенные свойства и методы. Например, объект Приложение может иметь свойство Коллекция Документов, отдельный Документ из которой имеет свойство Текст и метод Найти.

Объекты Microsoft Office доступны не только из макросов, но и из внешних программ на любых языках, поддерживающих COM. Последние могут быть компилируемыми программами на языках C++ или Delphi, управляемыми приложениями на Java или .Net, или же скриптами на VBScript и PowerShell.

try {
    using namespace Word;

    _ApplicationPtr word(L"Word.Application");
    word->Visible = true;
    word->Activate();

    _DocumentPtr wdoc1 = word->Documents->Add();
    RangePtr range = wdoc1->Content;
    range->LanguageID = wdRussian;
    range->Tables->Add(range,5,5);

    wdoc1->SaveAs(&_variant_t("C:1test.doc"));
    wdoc1->Close();
}
catch (_com_error& er) {}

Пример использования на C++

$word = New-Object -ComObject "Word.application"
$word.Visible = $true
$document = $word.documents.Add()
$selection = $word.selection
$selection.font.size = 14
$selection.font.bold = 1
$selection.Style ="Title"
$selection.typeText("Nice Title")
$selection.ParagraphFormat.Alignment = "wdAlignParagraphCenter"

Пример использования на PowerShell

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

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

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

msoAutomationSecurity

С автоматизацией связан интересный момент, упоминавшийся ранее. Настройки безопасности приложений (те, что определяют возможность автозапуска макросов и другого активного содержимого из документов) в программной модели Office определяются переменной-«свойством» Application.AutomationSecurity. По умолчанию это свойство имеет значение msoAutomationSecurityLow, что позволяет запуск любого активного содержимого из открываемых автоматически документов. Настройки безопасности, выставленные пользователем в Trust Center или администратором при помощи административных шаблонов, сохраненные в реестре, не оказывают влияния на настройки безопасности приложений Microsoft Office, запущенных в режиме автоматизации. Для безопасной автоматической обработки документов свойство AutomationSecurity должно быть целенаправленно изменено программно во время исполнения.
Такая небольшая деталь может иметь огромное значение для компаний, в которых настроена автоматическая обработка получаемых извне (по электронной почте, из облачных хранилищ и т.п.) документов.

Доступ к объектной модели VBA

Как и для большинства других элементов приложений Microsoft Office,
возможность управления и модификации проектов и кода Visual Basic for Applications программным путем доступна через интерфейсы автоматизации. По умолчанию она отключена для повышения безопасности пакета и защиты от макровирусов. При попытке программно создать объект, имеющий отношение к VBA, вызывающей программе вернется ошибка:

Error: 6068
Programmatic access to Visual Basic Project is not trusted.

Если пользователю все же необходим программный доступ к VBA, он может разрешить эту возможность в настройках Trust Center:

Недостаток этого решения в том, что заданная таким образом настройка сохраняется в ветке реестра, доступной пользователю для модификации, например для Microsoft Word это:

HKEY_CURRENT_USERSoftwareMicrosoftOffice >> Версия Office << WordSecurityAccessVBOM

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

'получаем версию Office и путь к ключу реестра AccessVBOM
Set objWord = CreateObject("Word.Application")
dim regpath
regpath = "HKCUSoftwareMicrosoftOffice" & objWord.Version & "WordSecurityAccessVBOM"

objWord.Quit
'пауза для закрытия предыдущего экземпляра Word
WScript.Sleep 1000

'записываем значение, открывающее программный доступ к проектам VBA
Set myWS = CreateObject("WScript.Shell")
myWS.RegWrite regpath, 1, "REG_DWORD"

'получаем запущенный экземпляр Word...
On Error Resume Next
Set objWord = GetObject(,"Word.Application")
If Err Then
'...или создаем новый
    wscript.echo "app not running, starting..."
    Set objWord = CreateObject("Word.Application")
    objWord.Visible = True
    objWord.Documents.Add()
End If
Err.Clear


Set objDoc = objWord.ActiveDocument

On Error Resume Next
set prj = objDoc.VBProject
If Err Then

    wscript.echo "Error: " & Err.number & Err.Description

End If
Err.Clear
prj.VBComponents("ThisDocument").CodeModule.AddFromString ("Sub AutoOpen()"&vbCRLF&"MsgBox ""Hello world!"""&vbCRLF&"End Sub")

Настройка программного доступа к VBA может определяться также ключами реестра

HKLMSoftwareMicrosoftOffice>> Версия Office <<WordSecurityAccessVBOM

и

HKLMSOFTWAREPoliciesMicrosoftOffice>> Версия Office <<WordSecurityAccessVBOM

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

Удаленное выполнение/DCOM

Технология COM изначально проектировалась в расчете на прозрачность местоположения: вызываемые компоненты могут являться библиотеками (DLL), загружаемыми в вызывающий процесс, либо в отдельный процесс-прокси, локально исполняемыми программами (EXE) или компонентами, расположенными на каком-либо другом компьютере (DCOM).

В зависимости от настроек методы вызова конкретного компонента могут быть различными, причем это может быть реализовано прозрачно и для клиента, и для сервера. Определенные изменения в реестре могут сделать любой зарегистрированный в системе компонент доступным для удаленного управления, в том числе анонимного. Однажды получив доступ к уязвимой системе, в дальнейшем злоумышленник может воспользоваться этой технологией для выполнения каких-либо действий от имени легального пользователя без необходимости сохранять на диске какие-либо исполняемые или интерпретируемые программы. Что касается Microsoft Office, то возможные действия включают чтение, создание и редактирование документов, добавление макросов и другого активного содержимого, чтение и рассылку электронной почты, получение содержимого адресной книги Outlook.

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

Для настройки вручную необходимо выполнить следующие шаги:

1. открыть порт DCOM в брандмауэре и добавить Microsoft Word в список разрешенных программ
2. при помощи утилиты Dcomcnfg настроить удаленный доступ для компонента Microsoft Word 97 — 2003 Document

Один из этапов настройки компонента DCOM для Word

Естественно, те же настройки можно выполнить и программно.
Таким образом, объектная модель Microsoft Word доступна для удаленного управления.

hr = CoCreateInstanceEx (CLSID_Word,
                         NULL,
                         CLSCTX_REMOTE_SERVER,
                         &si, 1, rgmqi);
IUnknown* pUnknown = 0;
if (hr == S_OK)
{
    pUnknown  = (IUnknown*)rgmqi[0].pItf;
    printf ("CoCreateInstanceEx OKn");
}
else
{
    printf ("CoCreateInstanceEx failed, error: 0x%Xn", hr);
    return;
}

_Application* pApp;
hr = pUnknown->QueryInterface(__uuidof(_Application), (void**)&pApp);
pUnknown->Release ();
if(FAILED(hr))
{
    printf ("QueryInterface (_Application) failed, error: 0x%Xn", hr);
    return;
}
printf ("DCOM server on remote machine started!n");
WCHAR* wszDocFileName = L"C:UsersadministratorDesktopimportant.docx";
VARIANT varResult;
DISPPARAMS dp = {0};
dp.cArgs = 1;
dp.cNamedArgs = 0;
dp.rgvarg = new VARIANT[dp.cArgs];
dp.rgvarg[0].vt = VT_BSTR;
dp.rgvarg[0].bstrVal = SysAllocString (wszDocFileName);
ZeroMemory(&varResult,sizeof(varResult));
hr=CallMethod(pApp->Documents,OLESTR("Open"),&dp,&varResult);
SysFreeString(dp.rgvarg[0].bstrVal);
delete []dp.rgvarg ;
IDispatch* IDWordDoc = varResult.pdispVal;
struct _Document * Copy = NULL;
IDWordDoc->QueryInterface (__uuidof(_Document), (LPVOID*)&Copy);
RangePtr pContent = Copy->Content;
printf (pContent->Text);
Copy->Close ();
pApp->Quit ();

Пример кода для Visual Studio, читающего содержимое заданного файла на удаленном компьютере

Отслеживание действий пользователя/События

Для отслеживания изменений в программах Microsoft Office объектная модель предоставляет стандартную для COM технологию точки соединения (Connection Points), экспортируя интерфейс IConnectionPointContainer. Поддерживаются различные типы событий: открытие, закрытие, сохранение документа, отправка почтовых сообщений, и т.д.
Подписаться на уведомления о событиях могут как подключаемые модули (плагины), так и клиенты автоматизации, работающие вне процесса программы Microsoft Office. Помимо легальных программ, призванных автоматизировать работу пользователя с документами, воспользоваться этой функциональностью скрыто может и вредоносное ПО.

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

CoInitializeEx(NULL, COINIT_MULTITHREADED);

CLSID    CLSID_Word;
hr = CLSIDFromProgID(L"Word.Application",&CLSID_Word);
    IUnknown* pUnk = NULL;
do {
    hr = GetActiveObject (CLSID_Word, NULL, &pUnk);
    Sleep (500);
    }
while (hr != S_OK);
hr = OleRun(pUnk);
IConnectionPointContainer *pConnPtContainer;
hr = pUnk->QueryInterface(IID_IConnectionPointContainer,
                                        (void **)&pConnPtContainer);
IConnectionPoint *pConnectionPoint;
hr = pConnPtContainer->FindConnectionPoint(__uuidof(Word::ApplicationEvents2),
                                                                  &pConnectionPoint);
MyEventSink MySink;
DWORD dwSinkCookie =0;
hr = pConnectionPoint->Advise (&MySink, &dwSinkCookie);
pConnPtContainer->Release();

Применение для закрепления/выполнения кода в уязвимой системе

В пентестерской (и не только) практике иногда появляется необходимость оставить возможность доступа к компьютеру, которая не вызовет подозрений у пользователя или администраторов и не будет обнаружена антивирусом. Компонентная модель Office прекрасно подходит для таких целей. Хорошие описания некоторых вариантов составил Matt Nelson (@enigma0x3) (Excel, Outlook).

В первом случае используется программный доступ к Excel для запуска макроса, во втором Outlook для запуска произвольного приложения.

Предупреждения Outlook

Объектная модель Microsoft Outlook очень удобна для создателей malware тем, что позволяет легко редактировать и распространять почтовые сообщения, добавлять вложения, использовать адресную книгу, выполняя эти действия от лица легального пользователя. Также она дает возможность отслеживать действия пользователя, изменяя, например, созданное пользователем сообщение в момент отправки.

Использование возможностей DCOM позволяет производить эти действия удаленно, не сохраняя на уязвимом компьютере какой-либо исполняемый код, который может быть обнаружен антивирусными программами.

Для снижения вероятности использования программных интерфейсов Microsoft Outlook злонамеренным ПО, разработчики добавили пользовательские сообщения о программном доступе к Microsoft Outlook при попытках изменения или отправки сообщений, доступа к адресной книге.

Пользовательское сообщение о программном доступе к Microsoft Outlook

По умолчанию сообщение будет появляться только в том случае, если антивирусное ПО не установлено. То есть при установленном и обновленном антивирусе Outlook уже не будет предупреждать пользователя о подозрительной активности. Дело за малым — осуществить задуманное, не привлекая внимания антивируса.

В реестре эта опция сохраняется в подключе Security программы Microsoft Outlook, к примеру для Microsoft Office версии 2016 32-битной с платформой ClickToRun полный путь ключа:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftOfficeClickToRunREGISTRYMACHINESoftwareWow6432NodeMicrosoftOffice16.0OutlookSecurity

Чтобы отключить предупреждения о подозрительной программной активности, необходимо добавить значение:ObjectModelGuard (DWORD) 0x2.
Изменить эти настройки в последних версиях Microsoft Office возможно средствами группового администрирования, либо через реестр. Возможность менять их через пользовательский интерфейс по умолчанию отключена.

В заключение

Ни одна из описанных выше особенностей Microsoft Office не является в полном смысле этого слова уязвимостью, а следовательно, и исправления их вряд ли стоит ожидать в обозримом будущем. Что может предпринять в этом случае бдительный системный администратор?
Если используется автоматизированная обработка документов Office, особенно из недоверенных источников, желательно убедиться, что настройки безопасности выставлены верно. Это можно сделать «скормив» автоматизированной системе документ с макросом. Заметим, что использование автоматизации может быть неочевидным, к примеру, сторонняя программа может вызывать приложения Microsoft Office для импорта данных из форматов .docx или .xlsx.
Желательна тщательная настройка пакета при помощи административных шаблонов.
Избежать серьезных последствий поможет обычное разграничение прав доступа, работа с Office исключительно из-под аккаунта, имеющего пользовательские привилегии. Брандмауэр и User Access Control — непременное условие безопасности Windows.
Полностью отключить автоматизацию, не нарушив функциональность пакета Microsoft Office, практически невозможно.

Автор: ormoulu

Источник

Modified on: Wed, 22 Sep, 2021 at 1:58 PM

---

When DocConverter fails to convert files, you may need to change the DCOM permissions for specific applications.

 Note: The steps in the following procedure vary slightly depending on your environment. Please review the instructions in their entirety before proceeding:

 Make sure to use an Administrator account when setting the DCOM permissions. 

1. Click Start > Run
2. Type mmc -32, click OK
3. Select File > Add/Remove Snap-in.

4. Select Component Services, and then click Add.

5. Click Close, and then click OK.

6. Once you click OK, Expand Component Service > Computers > My Computer > DCOM

DCOM will need to be setup for MS Word, Excel, Power Point, depending on what type of Office document you are converting

Scroll down in DCOM and set security for each below:

• Microsoft Excel Application
• Microsoft PowerPoint Slide
• Microsoft Word 97 — 2003 Document

Right Click each Office product and click Properties 

Within the application properties you will set the security and confirm the correct Administrator user is being used in the identity tab

1. Within the Application properties > Click Security

2. Select Customize for Lunch and Activation Permissions, Access Permissions and Configuration Permissions 

3. Click Edit for each one

4. Click Add 

5. Add an Administrator user and click check names to verify that the user exist and than click OK

6. Once the user has been added Highlight the user you just added

7. Click all check boxes under allow and click OK

8. Click on the Identity tab 

• If using «This User» make sure to use an Administrator account, if conversions still fail switch to «The interactive user»
• See this Microsoft article explains the purpose of the Interactive User

Noted: If «This User» still fails with conversions, that mean the Users specified does not have correct permissions.

9. Once set, click OK 

10. Click close mmc -32 console > File Exit

11. If prompted to «SAVE» make sure to save by clicking «YES»

12. Click «SAVE»

13. If prompted to to replace it, click «YES»

14. Once the mmc -32 console closes, retest by dropping your files into default watch folder

---

Did you find it helpful?
Yes
No

Send feedback

Sorry we couldn’t be helpful. Help us improve this article with your feedback.

Related Articles