If you’re reading this then you’ve probably seen all the media coverage over the last couple of days surrounding MS15-011 and MS15-014. These bulletins resolve issues in Microsoft’s group policy engine that allow remote code execution at SYSTEM level if an attacker can intercept network traffic from a domain-joined system. This blog post covers some information about what we reported to Microsoft on the issues, including a video demo of both being exploited in practice.
Back in March 2014, I reported three different vulnerabilities to Microsoft concerning these. The first is what is now known as MS15-011, the second is now known as MS15-014 and the third….well we will come to that later. We should also give credit to Jeff Schmidt of JAS Global and Dr Arnoldo Molina of simMachines and ICANN who it appears also separately reported the first issue, MS15-011, to Microsoft.
For the exploit vectors I used, MS15-011 is the base issue that applies to default configurations. My latter two issues (one being MS15-014) enable this exploit to also work against more secure configurations, such as where SMB signing is set as a mandatory requirement on the client. At the time I thought that Microsoft might take the line that the behaviour detailed in MS15-011 was by design, and provide fixes for the second two issues, allowing administrators to adopt a more secure configuration in a way that could not be easily bypassed.
However, Microsoft did more than this; MS15-011 introduces hardened UNC paths as a new security control. Defenders beware though, you do need to configure these, and applying the patch alone is not enough. Reading through the TechNet article, it looks like there are probably a couple of additional ways to exploit the issue beyond the method I chose, so this new security feature is very welcome.
One of the problems that led to MS15-011 was that SMB signing was not required on the client by default. However, SMB signing can of course be enabled, and in this case the vulnerability detailed in MS15-014 could be used to get around this. I found that it was possible to corrupt the process of group policy application such that the domain member reverts back to default configuration, where SMB singing is no longer required. It is then again possible to exploit MS15-011 as a second stage to get a SYSTEM shell.
As for the third issue reported to Microsoft, this has slightly more restrictive circumstances but effectively enables the attack to be performed even when SMB signing is mandated, without any vulnerability like MS15-014 allowing us to disable it. The reason I’ve been a little secretive is because there is nothing in the bulletins about this issue and I can’t see how the described fixes would address it. The fixes are focused on ensuring mutual authentication and integrity protection is applied. However, my exploit for this issue assumed this and would work even when a fully signed SMB connection was in place with a domain controller. What this means is I have now got some serious work to do delving into the new patches to understand if this third attack still applies or not. Stay tuned for that. Thinking about it has also given me a few new exploit scenario ideas for post-patch Tuesday systems too, so we will have to see where that leads.
As a teaser, I’ll now show a video demo of exploiting both MS15-014 and MS15-011 in a two-stage attack to get SYSTEM level code execution on a windows 7 domain member with a hardened domain configuration that requires SMB signing. In a default domain configuration, only the second part of this exploit (MS15-011) would be required but its more fun to see hardened configurations getting owned with exploit chaining. This demo was one of the demos I originally gave privately at our internal MWRICON conference towards the end of 2014 as part of my presentation on these issues to our own employees. Since patch Tuesday, I’ve now added a voice-over to give reference to the specific Microsoft bulletins.
If you want to see more in depth technical details and exploit demos of these issues then check out my SyScan talk on them next month. By then I’ll have had time to go through the new fixes and see if my third attack still remains an 0-day or not. Who knows, I might even drop an exploit tool for the issues too.
