Demonstration of the Windows/Office "Insecure Temporary File Dropping" Vulnerability

As it's described here, recently I discovered a potential RTF-related zero-day in Windows/Office at my daily work. This is really an interesting study for me, thus I took some of my free time digging more on the weekend - specifically, my goal was to find a real-world exploitation example to show how bad guys can really take advantage of this problem. I didn't go too far on this, after reviewing various environments on my computers, I've found the Java update program is a good example.

I wonder there is no better way to demonstrate than recording a video.

As you can find in the video, I made the RTF drop a dll with the filename "VERSION.dll" into the Windows Temp Folder. Later, when the user tries to update his/her Java (when the RTF is still being opened) following the instructions in the RTF document, a "calc.exe" will be popped right away.

The reason the exploitation works is that besides the "Insecure Temporary File Dropping" (let me just call that:P) vulnerability, the Java installation application has a dll-preloading issue, the issue makes the application load the "VERSION.dll" from the temp folder.

The process:

1. Malicious "VERSION.dll" is dropped into the temp folder by exploiting the "Insecure Temporary File Dropping" vulnerability.
2. Java updater downloads the Java installation program, into the temp folder, as well.
3. Java updater runs the downloaded Java installation program from the temp folder.
4. The Java installation program has a dll-preloading problem, which will search and load the "VERSION.dll" in the application directory prioring to the system-default "VERSION.dll" (application directory is the 1st place to be searched), where the application directory is in fact the temp directory, so the previous dropped malicious "VERSION.dll" will be loaded.

Pwned!

I hope this quick post will raise the awareness for this zero-day issue (well, in the hope for a better defense). When you first look at this problem, it sounds not a big deal, but actually if you consider the complexity of the computing environments we are facing these days, the problem can make something bigger than you thought. The interoperability of different programs is the key for this exploitation, this demo requires an user interaction but we can bet there is a chance to do it automatically (for example, if this is an automatic update). For some side thoughts, today we have got so many memory-based mitigations such as ASLR and DEP, while they are all ineffective for such a "behavior/logic"-based attack.:-)

Thanks,
Haifei

* Declaration: this post as well as other posts on this blog site reflects the author's personal opinions only.