Hand to hand teach you how to construct a office vulnerability POC in the first-the vulnerability warning-the black bar safety net

2016-09-07T00:00:00
ID MYHACK58:62201678877
Type myhack58
Reporter 佚名
Modified 2016-09-07T00:00:00

Description

In recent years, the APT track The prevalence, often visible variety to fishing the start of the attack, both websites hang horse Style Fishing, there are also spear-mail phishing, as shown herein the office Vulnerability CVE-2 0 1 2-0 1 5 8 with its classic, versatile yet stable exploits often appeared in various reports, here's a detailed explanation for this vulnerability works, and how based on the principles of manual configuration out of the available POC samples, give everyone playing a calculator take a look at take a look at it. The vulnerability principle About the vulnerability principle, there are various online analytical articles, are generally based on examples of the sample to locate the vulnerability of the binary code and analyze the principles, there will not be a detailed analysis of the process, given directly to the vulnerability causes the back also has a small part of the debugging demo. This vulnerability occurs in the office of a component MSCOMCTL. OCX, multiple versions of office the module are the presence of this vulnerability, this paper test environment with WINXP+office2007, for example. MSCOMCTL. OCX this vulnerability module is the office resolved the activeX control to use a dynamic library, if an office document contains activeX such control elements, such as buttons, lists, tree controls, etc., when the document is through the office is open MSCOMCTL. OCX will be automatically loaded into the office application process space is invoked to parse and display the controls. This vulnerability belongs to the classic buffer overflow vulnerability in the stack memory copy overflow vulnerability when office parses A is the constructed controls to the ListView list controls, for example, the occurrence of stack memory bounds copy. The following stack traceback diagram can be representative of the vulnerability the occurrence of the process: ! As can be seen, and Excel in the analysis of the ListView control when reading and loading a control data stream, load the stream in the process of calls to an internal function ReadBytesFromStreamPadded, the function of the function is similar to memcpy memory copy function, according to the parameters from the specified memory copies the specified size of the data to the target memory. But look carefully to be on the track will be found, the vulnerability is not present in this function, but appear in the CObj::load this function, the following analysis of this function to appear the loophole, first posted on the IDA on the function pseudo-code: int stdcall CObjLoad(int a1, void lpMem) { int result; // eax@1 void v3; // ebx@1 int v4; // esi@4 int v5; // [sp+Ch] [bp-14h]@1 SIZE_T dwBytes; // [sp+14h] [bp-Ch]@3 int v7; // [sp+18h] [bp-8h]@4 int v8; // [sp+1Ch] [bp-4h]@8

v3 = lpMem; result = ReadBytesFromStreamPadded(&v5, lpMem, 0xCu); //first the normal copy, the read data head if ( result >= 0 ) { if ( v5 == 'jboC' && dwBytes >= 8 ) //vulnerability trigger conditions { v4 = ReadBytesFromStreamPadded(&v7, v3, dwBytes); //second copy, here to invoke the inevitable cross-border if ( v4 >= 0 ) { if ( ! v7 ) goto LABEL_8; lpMem = 0; v4 = ReadBstrFromStreamPadded((UINT)&lpMem, (int)v3); if ( v4 >= 0 ) { CObj__SetKey((BSTR)lpMem); SysFreeString((BSTR)lpMem); LABEL_8: if ( v8 ) v4 = ReadVariantFromStream((struct tagVARIANT )(a1 + 2 0), (struct IStream )v3); return v4; } } return v4; } result = 2 1 4 7 5 4 9 1 8 3; } return result; } CObj::Load, as the name suggests, is a CObj object to load method, you need from memory in reading the object data, so the start will be from the data stream in the Read 0x0c bytes to the temporary variable v5. Then determine v5 the first 4 bytes is"Cobj"to detect whether to load the type of object, and the dwBytes this variable if greater than 8 was carried out the next load. Note that dwBytes this variable is read that 0x0c bytes when read together come in, because from the IDA of the variable note as can be seen dwBytes =[bp-0x0c]fall in the v5=[bp-0x14]and v5+0x0c=[bp-0x08]of the memory range, so that here a key is dwBytes value can modify the data stream is controlled. Then look at the next step, the same from the original data stream read dwBytes bytes to the temporary variable v7, v7=[bp-0x08], and the dwBytes at this time was greater than 8, so this reads a copy of the inevitable will overwrite the ebp, the occurrence of cross-border copy, forming a stack overflow vulnerability. Based on this analysis it can be speculated that, in the normal case from the control data read out dwBytes value is not greater than 8, because if more than 8 words will inevitably lead to stack copy exception, then this vulnerability is already being tested out. And by the IDA in view of this function the cross-reference will be found that this function seems to effect is not large, is in loading a specific number of controls at the beginning is called a bit. So, I suspect that this loophole is not the so-called serious mistakes, the original is less than 8 write became greater than 8, is that Microsoft deliberately left the back door vulnerability. ! Configured to trigger the vulnerability POC After the above principle analysis, the office in parsing the ListView control called a vulnerability function CObj::Load this function loads CObj object according to can be tampered dwBytes reads the specified size of memory data to 8-byte temporary variable, and check the size there is the back door of the suspect, the cause may be the use of a buffer overflow vulnerability. In order to test our analysis is correct, the following we refer to the above stack back to back figure configuration may trigger this vulnerability in the Excel document. The first Excel document requires the presence of a ListView control, can through the Excel software inside the developer tools to add, add after the equivalent documents to embed an empty ListView object.

[1] [2] next