With the imminent end of support for Windows XP, I take a look at another unsupported Microsoft product. Microsoft's MSXML 4.0 SP2 has been out of support since 2010 but is still widely installed (some estimates are around 39.5 of home PCs in the USA). Yet it hasn't mirrored the perpetual exploits that are expected to occur when patches are no longer released for XP.
Update - 2014-07-15:
All versions of MSXML 4.0 are no longer supported by Microsoft and will not receive any further security updates.
If you don't need MSXML 4.0, you should uninstall it. If you require MSXML 4.0 you should, at a minimum, ensure you've upgraded from SP2 to SP3 (this requires a manual update, and is available from Microsoft).
See my blog post, And it's official, MSXML 4.0 SP3 is out of support! for more information.
And now, back to your original broadcast.....
Part 1 - Where we meet MS12-043 and Nessus####
In July 2012 Microsoft released MS12-0431. MS12-043 fixed a vulnerability that already had a Metasploit module2 and that was being publicly exploited through the Blackhole exploit kit. At the time I was responsible for threat identification, validation, and remediation so I had MS12-043 prioritised for a quick roll out.
After a few iterations of patching Nessus was still showing that MS12-043 was missing from a large number of machines. An investigation found that their plugin was showing MSXML 4.0 SP2 as being unpatched by Windows Update, WSUS, and SCCM. After digging deeper I came across the following statements from Microsoft:
MSXML 4.0 SP3 is a complete replacement of MSXML 4.0, MSXML 4.0 SP1, and MSXML 4.0 SP2. This service pack provides a number of security enhancements and reliability improvements.
Support will end for MSXML 4.0 SP2 in 2010-04-13.
MSXML 4.0 SP3 is not installed or upgraded by default3.
Microsoft weren't releasing MS12-043 for MSXML 4.0 SP2. Most significantly Microsoft deemed MSXML 4.0 SP3 to be a different product, meaning that Windows Update, WSUS, and SCCM won't auto-update SP2 to SP3 and required a manual installation to occur*.
I worked with Tenable and they updated their MS12-043 plugin4 and created a new plugin (627585) so that Nessus could correctly detect versions of MSXML that were affected by MS12-043 and additionally detect versions of MSXML 4.0 that are unsupported.
* MSXML 4.0 SP3 can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=15697
Part 2 - Where Secunia enters the scene####
At home I run Secunia's PSI6, so I checked to see how they were handling MS12-043 and older versions of MSXML. Fortunately they didn't detect any MS12-043 as missing, but unfortunately they didn't detect MSXML 4.0 SP2 as being outdated, unsupported, or potentially vulnerable to exploit. In August 2012 I worked with Secunia and they included detection for unsupported versions of MSXML in both their PSI and CSI products.
This is where things begin to get interesting. In October 2013 I read a report from Secunia stating the following:
MSXML Core Services is the most exposed application for 11 months running7.
I dug a little deeper and discovered that they were talking about my beloved MSXML 4.0 SP2, and it's now been much more than 11 months.
Since Secunia had added detection for unsupported versions of MSXML, MSXML 4.0 SP2 has consistently been the most unpatched software detected in their home user product. Now that Microsoft users are so familiar with Patch Tuesday and automated updates I assume that most users aren't even aware that MSXML 4.0 SP2 is installed or in need or an update.
In that same report Secunia estimated that approximately 39.5% of their US home users were unpatched. They suspect that this number could actually be significantly higher based on the assumption that PSI users are generally more security concious. I also suspect that many organisations who don't have a mature vulnerability management lifecycle and who rely purely on SCCM/WSUS are also largely unpatched.
Part 3 - So what is MSXML?####
It's probably worth taking a quick moment to explore what MSXML is, and why it would be installed. Wikipedia states:
Microsoft XML Core Services (MSXML) is a set of services that allow applications written in JScript, VBScript, and Microsoft development tools to build Windows-native XML-based applications. It supports XML 1.0, DOM, SAX, an XSLT 1.0 processor, XML schema support including XSD and XDR, as well as other XML-related technologies.8
Got that? The important thing to know is that there are multiple versions of MSXML.
- MSXML 3.0 and MSXML 6.0 is essentially part of Windows / Internet Explorer
- MSXML 4.0 is an extra that software developers can include as part of their software installation
- MSXML 5.0 is essentially part of Microsoft Office 2003 and 2007
It's easy to see why MSXML 3.0, 5.0, and 6.0 are getting updated but MSXML 4.0 is being left out.
Part 4 - So where to from here? Microsoft? Metasploit? Bueller? Anyone?####
I'll preface this next section by stating that my use of Metasploit is very limited. In a recent Metasploit survey I responded that my primary use is "Vulnerability Validation" and "Demonstrating systems exposure". I'm comfortable with this and where I sit in relation to HD Moore's Law9.
So where to from here? I've helped get Nessus and Secunia's suite of products updated to detect MSXML 4.0 SP2 as vulnerable software. I've recently spoken with Rapid7 and their development team is currently looking into detecting unsupported versions of MSXML with Nexpose. Qualys detects older versions of MSXML as vulnerable. I've also spoken with the Microsoft Security Response Center and they're aware of the issue, but "will not be able to report on any progress that may have been made". If I was an attacker and looking for insecure and widely deployed software MS XML 4.0 SP2 could be an ideal candidate.
Maybe Metasploit could assist with improving Microsoft's response. One way could be to see an update to the MS12-043 / CVE-2012-1889 Metasploit module to include the exploitation of MS XML 4 SP2. It doesn't specifically have to be Rapid 7 that does this, maybe someone else in the community is able to help.
One thing I'm sure of, is that when an exploit is included in Metasploit it gets noticed - and by noticed I include both defensive and offensive sides of the infosec community. This naturally leads to a discussion around responsible disclosure. Recently @weldpond referred to the some of the old L0pht advisories and proof of concepts that they needed before Microsoft would respond.
In 1997, L0pht needed to publish exploit code to get Microsoft to respond. http://marc.info/?l=bugtraq&m=87919555309014&w=2 16 yrs later some companies need the same.— Chris Wysopal (@WeldPond) January 2, 2014
This tweet led to a discussion about "Responsible Disclosure" and "Responsible Response". So where does this post sit on that scale? In the end I'm not 100% sure. It's certainly not a zero-day vulnerability as Microsoft have already publicly advised of the need to upgrade to MSXML 4.0 SP3 (albeit not in the same way that everyone is used to, i.e. through Windows Update), and they've also released patches for their currently supported versions (such as MS12-043 and MS13-00210). Secunia has already published information on this in their report. The main question here is does Microsoft have a responsibility to give MSXML 4.0 SP2 the same auto-update mechanism as their other products? Do their customers have this expectation?
I understand that Microsoft can't support products indefinitely, and compared with the limited information that Apple give about supported OS X versions, their upcoming end of support for XP is being handled well. That said, I don't believe that MSXML 4.0 SP2 has been handled in a similar manner.
Part 5 - What do I hope to achieve?####
First and foremost I hope to raise awareness of this unsupported software. I know it's touch and go between releasing this type of post and those with malicious intent using it for their purposes. My hope is for Microsoft to change their stance and allow MS XML 4.0 SP2 to be auto-updated to SP3, thereby reducing this exposure.
Microsoft deliver Service Packs for their Operating Systems and other products via Windows Update - can't they do the same for MSXML 4.0 SP2? They even auto-update Internet Explorer to new versions, so I can't imagine why auto-updating MSXML 4.0 SP2 would be such a large concern.
TL;DR There is a large number of machines that are potentially exposed to vulnerabilities in unsupported versions of MS XML 4.0 SP2. I'd like to see an updated exploit for MS12-043 / CVE-2012-1889 that includes MSXML 4.0 SP2 and Microsoft autoupdate SP2 to SP3.
The simplest way to mitigate the risk of MSXML 4.0 SP2 being exploited is to upgrade to MSXML 4.0 SP3. It can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=15697 - after which additional patches such as MS12-043 and MS13-002 should autoupdate.
Some patch management systems have this pre-packaged whilst others will need to have this packaged for deployment.
1 - https://technet.microsoft.com/en-us/security/bulletin/ms12-043
2 - https://www.rapid7.com/db/modules/exploit/windows/browser/msxml\_get\_definition\_code\_exec
3 - http://download.microsoft.com/download/A/2/D/A2D8587D-0027-4217-9DAD-38AFDB0A177E/MSXML4%20SP3%20RTM%20Release%20Note.htm
4 - http://www.tenable.com/plugins/index.php?view=single&id=59906
5 - http://www.tenable.com/plugins/index.php?view=single&id=62758
6 - https://secunia.com/vulnerability_scanning/personal/
7 - http://secunia.com/blog/why-microsoft-xml-core-services-is-the-most-exposed-program-on-private-pcs-for-11-months-running-384/
8 - http://en.wikipedia.org/wiki/MSXML which is released under the [Creative Commons Attribution-Share-Alike License 3.0](http://creativecommons.org/licenses/by-sa/3.0/)
9 - http://blog.cognitivedissidents.com/2011/11/01/intro-to-hdmoores-law/)
10 - https://technet.microsoft.com/en-us/security/bulletin/ms13-002