-August 2007: Espionage case of China against German chancelery. 163 Gb of Gouvernemental data stolen through a Trojan-infected Office document.
-2009 to 2010: Chinese hackers succeeded in stealing economic and financial data from European Banks, through malicious PDFs.
Document as cyberweapons
-(Open)Office document are good vectors
-PDF documents are also used nowadays
The Cyberwarfare Show
-PWN2KILL, May 2010 Paris, challenge has proved the risk is real and high.
http://www.esiea-recherche.eu/iawacs2010.html
-Huge technical possibilities on one side, quite no protection and detection capability on the other side.
-Many critical systems are rather secure with a strong security policy enforced.
-Classical approaches are less and less possible, not say impossible.
Which applications are concerned?
-Office 2010
-OpenOffice 3.x
-All other office applications
What is the Purpose?
-To install malicious payload into the operating system, whithout being detected by any AV.
-We do not want to exploit any vulnerability (target = secure sensitive systems e.g. combat systems).
Macro Security in MSO
Possible level of security:
Level 4 (0x00000004): Disable all macros without notification.
Level 3 (0x00000002): Disable all macros with notifiation.
Level 2 (0x00000003): Disable all macros except digitally signed macros.
Level 1 (0x00000001): Enable all macros.
Location of settings:
Registery key : HKEY_CURRENT_USER\Software\Microsoft\Office\ 12.0\
Application = {Word, Excel, Powerpoint, Access}
Trusted location:
A trusted location is a directory where macros of documents stored inside are allowed to be executed automatically.
Macro Security in OpenOffice
Security settings:
Both Macro security level and trusted location are defined in "Common.xcu" file at:
Openoffice.org\3\user\registery\data\org\openoffice\Office
Example:
1: <node oor:name="Security">
2: <node oor:name="Scripting">
3: <prop oor:name="MacroSecurityLevel" oor:type="xs:int">
4: <value>0</value></prop></node></node>
Trusted Location:
Set the root directory as Trusted location
1: <node oor:name="Security">
2: <node oor:name="Scripting">
3: <prop oor:name="SecureURL" oor:type="oor:string-list">
4: <value>file:///C:/</value></prop></node></node>
The use of 'AutoExec' event with MSO:
-Able to naturally bypass the level 2 of execution.
-Several events are available: AutoNew, Open, Close, Exit, Exec
-Applied on template named Normal.dotm and stored inside MSO's users settings file.
-Execute the macro at opening event even if any macro are not allowed to be executed (Level 2).
MSO and OO: The integration
-Both are based on the W3C specification. But the integration is totally different.
MSO’s integration:
-Office makes it easier to create signatures.
-It is possible to create self-signed certificates.
-They are stored inside _rel\.rel file within the document.
Openoffice’s integration:
No significant change about signature since 2006, the first study.
Black Hat 2009, Amstersdam, E.Filiol J.-P. Fizaine, Openoffice v3.x Security Design Weaknesses.
MSO Case
+Change to the lowest level: 0
Interesting Keys: HKEY_CURRENT_USER
Path: Software\\Microsoft\\Office\\12.0\\Word\\Security
Windows API: RegOpenKeyEx, RegSetValueEx, RegCreateKeyEx, RegCloseKey
+Set the directory c:\Users as a Trusted Location.
KEY: HKEY_CURRENT_USER
Path: Software\\Microsoft\\Office\\12.0\\Word\\Security\\Trusted\\Locations
Path2: Software\\Microsoft\\Office\\12.0\\Word\\Security\\Trusted\\Locations\\Location3
OpenOffice Case
+Change the Macro security level to the lowest: 0
-Settings are stored in only one file! No use of specific library is needed, the C Standard Library is sufficient.
-Forge the Path
-Locate the position inside the file
-Insert the value:
1: <node oor:name="Security"> <node oor:name="Scripting">
2: <prop oor:name="MacroSecurityLevel" oor:type="xs:int">
3: <value>0</value> </prop> </node> </node>
+Trusted Locations
-Insert the value:
1: <node oor:name="Security"> <node oor:name="Scripting">
2: <prop oor:name="SecureURL" oor:type="oor:string-list">
3: <value>file:///C:/</value> </prop> </node> </node>
K-ary Malware
Malware made of k-different, innocent-looking (from the AV point of view). Each of them can (inter)act independently or not and can either be executed in parallel or in sequential. Not all the parts are necessarily executable. The cumulative action of each part defines the malware action.
Proof of Concept (PoC):
E. Filiol, Journal in Computer Virology, 2007.
Hack.lu 2009, A. Desnos, Implementation of K-ary viruses in Python.
Two waves of attack: The use of 2-ary malware
Suppose the security level is set to the paranoid mode, it is impossible to change the level from inside the macro.
Journal in Computer Virology, 2006, D. de Drézigué, J.- P. Fizaine, N. Hansma, In-depth Analysis of the Viral Threats with OpenOffice.org Documents
Why this approach?
-Attacking (secure) systems becomes really complex. Just exploiting one or more vulnerability does no longer suffice. Installing a functionnally sophisticated program is less and less easy. The solution is to split the viral information into many pieces!
-Real case: secure systems generally filter and forbid packed binaries/shellcodes.
-Using 2-ary malware is a powerful alternative.
-The first executable performs a innocent, generally legitimate simple action.
-The office document then installs more complex malware transparently and silently.
Protection and Countermeasures
-Use of Public Key Infrastructure
-Whenever self-signed certificates are used. Check the serial number, timestamp and validity systematically. The serial number is supposed to be unique.
