Blast, 2016/06/21 13:18
0 x00 profile
The vulnerability was discovered earlier this year by the author EduardoBraun Prado of WMP. The MCL file has another vulnerability that can lead to remote code execution. Why say again, because this thing is really “bad”, the same place has multiple bypass problems resulting in remote code execution.
0 x01 history – MS15-100 A
The MCL “nightmare” began with the MS15-100 (CVE-2015-2509, Aaron Luo, Kenney Lu, and Ziv Chang of TrendMicro) vulnerability in 2015, when researchers found that as long as the MCL file specified:
<application run="c:\windows\system32\cmd.exe"></application>
Copy the codeMCL is an XML file, WMP simply parses the XML when loading, and then directly runs the content specified in “run”. It looks pretty dumb.
0 x02 history – MS15-134 – B
Ms15-134 (CVE-2015-6127, Francisco Falcon of CoreSecurity) was born shortly after Microsoft filtered the content of Run in MS15-100. Instead of using the run property, the author uses another URL property.
After specifying a file through the APPLICATION URL attribute, WMP loads the URL in its own WebBrowser. But the researchers found that WMP exe is not in Local Machine Lockdown list (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InternetExplorer\MAIN\FeatureControl\ feature_localmachine_available) So scripts in local pages opened in WMP’s WebBrowser will run automatically.
After all, it’s not possible to distribute two files to the user’s computer, so the author thought of a more “elegant” way: adding the script to the Application TAB. Because WMP’s XMLParser ignores all APPLICATION child elements it doesn’t know, if an attacker constructs the attack file a.mlc:
#! html <application url="a.mlc"> <script>alert(1)</script> </application>Copy the codeNote that the URL points to itself, so the file is loaded as an HTML file. Due to WebBrowser’s (IE) loose nature with HTML, unrecognized tags are ignored, and only the meaning of the tag is rendered. This causes the script contained in the file to be rendered directly in WebBrowser and executed in the File field. I don’t have to go into detail about what I can do next.
0 x03 protagonist — MS16-059
At the time of Microsoft’s interception, someone found a new way:
The < application run = "file:///\\127.0.0.1\c$\programdata\cpl.lnk" / >Copy the codeBecause Microsoft blocks UNC, the attacker uses file:/// to bypass the filtering. At the same time, Microsoft also blocked the passed file suffixes, so the author passed in the LNK (shortcut) file to bypass.
The author specified in LNK that a CPL file should be called. CPL is also a DLL that implements a specific interface, so the author managed to bypass MCL interception and execute arbitrary code.
With UNC, the author still only needs to pass in an MCL file to the user, and all the other malicious code relies entirely on remote pulling.
0x04 How is the MCL processed? (Original · 2014 Version)
Because the virtual machine patch is too slow, so here directly with 14 years of DLL to demonstrate, look at an original style.
How to handle MCL files? HKEY_LOCAL_MACHINE\SOFTWARE\Classes\. MCL \OpenWithList\ehshell. Exe: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.
If you look at the ehshell.exe code, you can see that ehshell.exe simply loads ehshell. DLL, then all the logic is done by ehshell. DLL.
You can also draw this conclusion from the call stack (double-click on the stack after the MCL file) :
#! bash 0:025> bp kernel32! CreateFileW 0:025> g Breakpoint 0 hit kernel32! CreateFileW: 00000000`779b1b88 ff2522b90700 jmp qword ptr [kernel32! _imp_CreateFileW (00000000`77a2d4b0)] ds:00000000`77a2d4b0={KERNELBASE! CreateFileW (000007fe`fd944600)} 0:000> dqs esp 00000000`0021e108 00000000`779a0dad kernel32! CreateFileWImplementation+0x7d 00000000`0021e110 00000000`80000000 00000000`0021e118 00000000`00000000 00000000`0021e120 00000000`0000006c 00000000`0021e128 00000000`0039d2e0 00000000`0021e130 00000000`00000003 00000000`0021e138 00000000`00100000 00000000`0021e140 00000000`00000000 00000000`0021e148 00000000`00000000 00000000`0021e150 00000000`00440042 00000000`0021e158 00000000`03a7ed88 00000000`0021e160 00000000`00100000 00000000`0021e168 000007fe`f116bec7 mscorwks! DoNDirectCall__PatchGetThreadCall+0x7b 00000000`0021e170 00000000`00000000 00000000`0021e178 00000000`0021e1d0 00000000`0021e180 00000000`00000003 0:000> du 00000000`03a7ed88 00000000`03a7ed88 "C:\Users\BlastTS\Desktop\test.mc" 00000000`03a7edc8 "l"Copy the codeAs you can see from the LaunchMedia Enter, ehShell basically does nothing.
#! bash # Child-SP RetAddr : Args to Child : Call Site 00 00000000`0021e108 00000000`779a0dad : 00000000`80000000 00000000`00000000 00000000`0000006c 00000000`0039d2e0 : kernel32! CreateFileW 01 00000000`0021e110 000007fe`f116bec7 : 00000000`00000000 00000000`0021e1d0 00000000`00000003 000007fe`f0331830 : kernel32! CreateFileWImplementation+0x7d *** WARNING: Unable to verify checksum for C: \ Windows \ assembly \ NativeImages_v2 0.50727 _64 \ mscorlib \ c3beeeb6432f004b419859ea007087f1 \ mscorlib ni. DLL 02 00000000`0021e170 000007fe`f0207f71 : 000007fe`f0331830 000007fe`eff69210 00000000`03a7ee70 000007fe`f0287aea : mscorwks! DoNDirectCall__PatchGetThreadCall+0x7b 03 00000000`0021e230 000007fe`f0207e2e : 00000000 '03a7EDD8 00000000' 03a7EDD8 00000000 '03a7EE00 000007fe' f0288e86: mscorlib_ni+0x317f71 …………………………………………………… 17 00000000`0021f3b0 000007ff`00250222 : 00000000`02681eb0 00000000`02681f30 00000000`0021f4a0 00000000`0021f060 : 0x7ff`00252817 18 00000000`0021f5b0 000007fe`f116a21a : 40ca06f5`582e02ef bdb2bd08`2c45789a 00000000`00000000 00000000`00000000 : 0x7ff`00250222 19 00000000`0021f5e0 00000001`3f7e161b : 00000000`01e10020 00000000`003bcfa8 00000000`0021f6a0 00000000`00000000 : mscorwks! UMThunkStubAMD64+0x7a 1a 00000000`0021f670 00000001`3f7e153a : 00000000`00312462 00000000`00000000 00000000`003283c0 00000000`01e10020 : ehshell! LaunchMediaCenter+0x14e 1b 00000000`0021f6c0 00000001`3f7e148d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ehshell! wWinMain+0xc3 1c 00000000`0021f920 00000000`779a59ed : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ehshell! InitializeCOMSecurity+0x382 1d 00000000`0021f9e0 00000000`77adb371 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32! BaseThreadInitThunk+0xd 1e 00000000`0021fa10 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll! RtlUserThreadStart+0x1dCopy the codeMediaCenter and ehshell. DLL are both C# DLLS, so WinDbg looks at them rather quickly.
The project is huge, and after a long build process, a search for keywords shows the logic: after loading the MCL, the program is parsed first. By System. XML (MCL) files, and to include in the InternalExtensibilityAppInfo MCL Run attributes to create a special “AppEntryPoint”.
#! Csharp namespace MediaCenter. Extensibility {... public ExtensibilityEntryPointInfo AddExternalAppEntryPoint(string strRun,string strTitle, string strDescription, string strCategory, object objContext,string strNowPlayingDirective) { IDictionarydictEntryPoint = CreateBaseEntryPointDict(Guid.NewGuid(), strTitle,strDescription, strCategory, objContext, strNowPlayingDirective); dictEntryPoint[Run] = strRun; return this.AddEntryPoint(dictEntryPoint); }Copy the codeWhen handling AppEntryPoint, the program does no validation and starts the program directly with process. Start. Of course, this is the original version, so there are no pop-ups or judgments.
#! Csharp namespace MediaCenter. Extensibility {........................... Internal classExtensibilityExternalAppEntryPointInfo: ExtensibilityEntryPointInfo {........................... Internal override LaunchResult Launch(ref Object objState) {……………… Process process = null; try { process = Process.Start(base._strRun); } catch (Exception Exception) ………………Copy the codeHow does new 0x05 filter? (Version since June 2016 patch)
Simple and crude, all popovers that contain Run/Url are confirmed twice. This is also Microsoft’s very violent compromise on the first few serious issues.
0x06 Vulnerabilities of more than ten years
Interestingly, the bug seems to be more than a decade old. MCL files were originally intended to run a program in WMP, a bit like HTA files, and while looking for information I found forum posts in 2006 (and certainly earlier) about how MCL launches programs. Interestingly enough, the feature was not considered a security bug at the time, just a feature, but after it was first reported in 2015, Microsoft gave it its highest security rating — but it was a normal “feature design.” So the concept of security has changed a lot in a decade.
For example, the code below is a solution to a previous post “How to run Zsnes on Xbox 360”, which is exactly the same as ms15-100, posted in 2012.
#! html <application name = "Zsnes" SharedViewport = "" NowPlayingDirective = "" run = "C:/Zsnes/Zsnes.exe"> <capabilitiesrequired directx="True" audio="False" video="False" intensiverendering="True" console="False" cdburning="False" /> </application>Copy the code