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.
In academia, government, and industry, DevOps has become a standard, straightforward option for streamlining efforts and increasing comprehensive participation by all stakeholders in the software development lifecycle (SDLC). In highly regulated environments (HREs) within these three sectors, however, applying DevOps can prove challenging. HREs are mandated by policies for various reasons, the most often being general security and protection of intellectual property thus making the sharing and open access principles of DevOps that much harder to apply. In this blog post series DevOps and HREs, which is based on a published paper, we will discuss the process, challenges, approaches, and lessons learned in implementing DevOps in the software development lifecycle in HREs. In this first post, we will explore challenges (and goals) to implementing DevOps in HREs. The majority of what you will read in the series stems from our experiences in performing these tasks. In addition to presenting challenges, this post gives an overview of what an HRE is, what you should expect to find in these environments, and what DevOps implementation obstacles may be present.