Hey, it's Will. I noticed that several blogs, including Trend Micro and McAfee, have been talking about the recent attacks on the Internet Explorer 7 vulnerability that was fixed in MS09-002. An interesting thing about these exploits is the attack vector. The technique used in these attacks has several security impacts that may not be immediately obvious.
Some of the reports about the recent attacks are a little unclear about the location of the vulnerability. The reports discuss a DOC file, an embedded ActiveX control, and a backdoor that is installed. However, the vulnerability at play is an Internet Explorer 7 flaw, which is addressed in Microsoft Security Bulletin MS09-002.
Microsoft Windows opens files based on their file extension. Microsoft Word has the ability to render HTML files. What happens when you combine these two aspects and put a .DOC file extension on an HTML file? You end up with a file that appears to be a DOC file, and opens with Microsoft Word. Because Microsoft Word is treating the document as HTML, it allows ActiveX controls to run. This opens the document up to vulnerabilities. For example, an attacker can exploit the ActiveX capabilities by using an Internet Explorer ActiveX control in what appears to be a DOC file.
Why would somebody choose to go through these steps to attempt to exploit an Internet Explorer vulnerability, instead of simply sending out links to a malicious web page? I was able to come up with a few possibilities:
It is possible that it is simply for social engineering purposes. A user might be more likely to open a carefully constructed email with a DOC attachment than an email with a web link in it. Maybe.
Some people do not use Internet Explorer as their default web browser. They might even think that they don't need to worry about MS09-002 because they don't use IE. This sort of thinking can be dangerous, as demonstrated by this attack. A DOC file will open with Microsoft Word if the system has Microsoft Office installed. And the document described above will always use Internet Explorer to render web pages, regardless of the default browser setting. As mentioned in the CERT/CC Securing Your Web Browser document, it is best to secure every web browser on your system, even if you don't use all of them. If you use Microsoft Windows, you have Internet Explorer, so it would be wise to lock it down. I think that the default-browser scenario seems quite plausible as an explanation for why this attack vector was chosen.
Starting with Windows Vista, Microsoft enables a cool feature in Internet Explorer called Protected Mode. What this means is that regardless of the privileges of the logged-in user, Internet Explorer will run with lower privileges than even a restricted user in Windows. This is great for limiting the impact of an exploited vulnerability.
Consider the scenario where I am able to achieve code execution as the result of a vulnerability in Internet Explorer or an ActiveX control. On systems that use IE Protected Mode, I may be able to execute code, but that code will inherit the same low privileges as the Internet Explorer browser. So the code should not be able to do anything outside of the low integrity (or sandbox) areas of the filesystem or registry. This protection happens when the user runs the Internet Explorer web browser application. But what about when another application such as Microsoft Word uses Internet Explorer components to render web pages? No more Protected Mode! So in the attack vector described above, the code will execute with the privileges of the user that is running Microsoft Word. By indirectly using Internet Explorer by way of Microsoft Word, attackers are able to bypass IE's Protected mode.
What are the lessons to be learned here?
Keep your system up to date with patches and security updates. Attackers quite often do not need to rely on unpatched "zero-day" vulnerabilities to compromise systems. If you are late to install updates, you are at risk.
Any application that is on your system can put you at risk, whether you use it or not. By uninstalling unneeded applications, you reduce the attack surface of your system. For applications that cannot be uninstalled, make sure they are up to date.
Install the update for MS09-002 if you have not done so already.
According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.