Microsoft Office Automation: Another Macro Virus Hole
The Microsoft Office software package is not only the actual standard of office software, but also a very complex and multifunctional environment that allows you to create solutions designed primarily to use the capabilities of Microsoft Office and automate routine user actions when working with documents. This software platform, called the Microsoft Office Object Model (Microsoft Office Object Model), or Microsoft Office Automation (Microsoft Office Automation) is based on the COM Object Model and contains an extensive set of classes that provide access to virtually any element or action that is available to the user during work. with Microsoft Office through a graphical interface.
Microsoft Word object model (partially)
Speaking of programming for Microsoft Office, they often mean "internal" programs - macros written in VBA (Visual Basic for Applications, the implementation of Visual Basic in Microsoft Office) and embedded in documents.
Create a macro for Microsoft Excel
')
Due to the wide possibilities of the language (due to access to external dll and components almost unlimited) and convenient distribution model (with document files), Microsoft Office macros have been used to create malicious software since the advent of VBA and got their own name - macro viruses. Despite some tightening of settings related to macros (currently the current version of Microsoft Office prohibits automatic execution of macros at default settings, notifying the user of this), malicious programs are actively used by attackers even now. To effectively use this technology with a twenty-year history, it was enough to supplement it with elements of social engineering.
Suggesting that the user allow macros in a document containing malicious code
Microsoft Office objects are accessible not only from macros, but also from “external” programs in any languages ​​that support COM. The latter can be compiled programs in languages ​​like C ++ or Delphi, managed by Java or .Net applications, or by scripts in VBScript and PowerShell — COM technology is available for almost everything that can run under Windows.
Access to the Microsoft Office object model from PowerShell
The Microsoft Office Object Model represents Microsoft Office applications as COM objects. But it is also possible to add documents and other COM objects — ActiveX controls, not related to Microsoft Office, but present in the operating system. Being included in the document, these elements can interact with the macro code, or execute their own code based on the “properties” added to the document - the properties of the object. In skillful hands, embedding ActiveX controls can also lead to the execution of arbitrary code, so in recent versions of Microsoft Office, the launch of embedded ActiveX is prohibited by default, with the exception of some white list elements. However, the user in this case, if desired, can explicitly allow execution.
Embedded ActiveX Warning
The proposal to allow (or prohibit) the launch of active content will go to the user when opening the document in a normal manner in the appropriate application. What happens if you open the same document using the Microsoft Office Object Model?
Examples of such programs - a great many in various languages ​​and for various tasks:
When studying such examples, only once we found an interesting line in the code :
What does it mean, tell the official documentation :
It turns out that if the Microsoft Office application is launched as an automation element, then the macro code in the opened documents will be executed by default. Unless, of course, specifically change the security level of the management program. This default does not depend on the settings made by the user or administrator. In addition to macros, the code of any ActiveX controls added to the document will also be loaded and executed.
Execution of a macro when opening a document through Automation
This non-obvious feature seems to be rarely taken into account. For example, office software from other manufacturers use the Microsoft Office object model to import and export data into Word and Excel documents. Quite often there are examples for 1C:
1C programs, called “treatments,” can also use COM in general and the Microsoft Office object model in particular. Some useful treatments are provided to users by the manufacturer, for example, processing “Loading Data from a Tabular Document. Epf” allows you to load data from external table documents into the database.
Macro execution when opening a document through 1C processing
As you can see, the AutomationSecurity property was also forgotten by 1C programmers.
On the one hand, this is a classic example of what you need to think about security in the programming process, no matter what language is used. On the other hand, what reason made Microsoft, when tightening Microsoft Office security settings, leave the object model unprotected?
A small video demonstrating how an attacker can take control of the accounting computer using the Metasploit Framework and the price of dumplings. The macro contained in the Excel document runs the script for PowerShell, which opens the attacker with access to the command line on the attacked system.
Microsoft Word object model (partially)
Speaking of programming for Microsoft Office, they often mean "internal" programs - macros written in VBA (Visual Basic for Applications, the implementation of Visual Basic in Microsoft Office) and embedded in documents.
Create a macro for Microsoft Excel
')
Due to the wide possibilities of the language (due to access to external dll and components almost unlimited) and convenient distribution model (with document files), Microsoft Office macros have been used to create malicious software since the advent of VBA and got their own name - macro viruses. Despite some tightening of settings related to macros (currently the current version of Microsoft Office prohibits automatic execution of macros at default settings, notifying the user of this), malicious programs are actively used by attackers even now. To effectively use this technology with a twenty-year history, it was enough to supplement it with elements of social engineering.
Suggesting that the user allow macros in a document containing malicious code
Microsoft Office objects are accessible not only from macros, but also from “external” programs in any languages ​​that support COM. The latter can be compiled programs in languages ​​like C ++ or Delphi, managed by Java or .Net applications, or by scripts in VBScript and PowerShell — COM technology is available for almost everything that can run under Windows.
Access to the Microsoft Office object model from PowerShell
The Microsoft Office Object Model represents Microsoft Office applications as COM objects. But it is also possible to add documents and other COM objects — ActiveX controls, not related to Microsoft Office, but present in the operating system. Being included in the document, these elements can interact with the macro code, or execute their own code based on the “properties” added to the document - the properties of the object. In skillful hands, embedding ActiveX controls can also lead to the execution of arbitrary code, so in recent versions of Microsoft Office, the launch of embedded ActiveX is prohibited by default, with the exception of some white list elements. However, the user in this case, if desired, can explicitly allow execution.
Embedded ActiveX Warning
The proposal to allow (or prohibit) the launch of active content will go to the user when opening the document in a normal manner in the appropriate application. What happens if you open the same document using the Microsoft Office Object Model?
Examples of such programs - a great many in various languages ​​and for various tasks:
Set objWord = CreateObject("Word.Application") Set objDoc = objWord.Documents.Add("e:\test\fax.dotx") objDoc.SaveAs("e:\test\temp.docx") objDoc.Close objWord.Quit application = new Word.Application(); Object templatePathObj = " ";; try { document = application.Documents.Add(ref templatePathObj, ref missingObj, ref missingObj, ref missingObj); } catch (Exception error) { document.Close(ref falseObj, ref missingObj, ref missingObj); application.Quit(ref missingObj, ref missingObj, ref missingObj); document = null; application = null; throw error; } _application.Visible = true; C # example 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 ++ Example $word = New-Object -ComObject Word.Application $word.Visible = $True $doc = $word.Documents.Add() PowerShell ExampleWhen studying such examples, only once we found an interesting line in the code :
app.AutomationSecurity = 3 What does it mean, tell the official documentation :
Application.AutomationSecurity Property (Excel)
...
Microsoft Excel uses when it is programmatically opening files.
...
MsoAutomationSecurity can be one of these MsoAutomationSecurity constants.
msoAutomationSecurityByUI. Use the security dialog box |
msoAutomationSecurityForceDisable. Disables all macros in all files.
msoAutomationSecurityLow. Enables all macros. This is the default value when the application is started .
It turns out that if the Microsoft Office application is launched as an automation element, then the macro code in the opened documents will be executed by default. Unless, of course, specifically change the security level of the management program. This default does not depend on the settings made by the user or administrator. In addition to macros, the code of any ActiveX controls added to the document will also be loaded and executed.
Execution of a macro when opening a document through Automation
This non-obvious feature seems to be rarely taken into account. For example, office software from other manufacturers use the Microsoft Office object model to import and export data into Word and Excel documents. Quite often there are examples for 1C:
MSWord = COM("Word.Application"); MSWord.Documents.Add(); ActiveDocument = MSWord.ActiveDocument; Content = ActiveDocument.Content; // Content.InsertParagraphAfter(); Content.InsertAfter(" 1"); Content.InsertParagraphAfter(); Content.InsertAfter(" 2"); Content.InsertParagraphAfter(); // // Content.InsertParagraphAfter(); // ActiveDocument.Range(Content.End - 1, Content.End).InsertFile(, "", , ); Content.InsertParagraphAfter(); Example for 1C1C programs, called “treatments,” can also use COM in general and the Microsoft Office object model in particular. Some useful treatments are provided to users by the manufacturer, for example, processing “Loading Data from a Tabular Document. Epf” allows you to load data from external table documents into the database.
Macro execution when opening a document through 1C processing
As you can see, the AutomationSecurity property was also forgotten by 1C programmers.
On the one hand, this is a classic example of what you need to think about security in the programming process, no matter what language is used. On the other hand, what reason made Microsoft, when tightening Microsoft Office security settings, leave the object model unprotected?
A small video demonstrating how an attacker can take control of the accounting computer using the Metasploit Framework and the price of dumplings. The macro contained in the Excel document runs the script for PowerShell, which opens the attacker with access to the command line on the attacked system.
Source: https://habr.com/ru/post/335222/
All Articles