Analysis of RES Protocol in the series of IE Security

Analysis of RES Protocol in the series of IE Security

 

RES is a special Protocol supported by IE. It is used to read resource information from a binary file and display it on a webpage. As RES has been weakened by the master of Microsoft to become a dog, the two articles to be split are simply written in one article. Unless otherwise prompted, IE11 prevails.

0x00 Res Protocol ABC

Res Protocol is used to extract specified resources from a file. Syntax: res: // sFile [/sType]/sID

Meaning of each Token:

Sfile: percent code. The file path that contains the resource. SType: optional, string or number, indicating the resource type. It can be a predefined type that can be recognized by any FindResource. If a value of the numeric type is specified, a # character must be followed. Default RT_HTML or RT_FILE when not specified. SID: string or digit type. Resource ID. If a numeric value is specified, a # is followed #.

For details, see reference 1. No translation ......

0x01 loading of Res Protocol in new window

When the res protocol is opened in a new window, the res Protocol dll is loaded into the memory. The Res protocol-loaded dll is read using LoadLibraryExW. Some common res protocols, such as res: // ieframe. dll/, do not use the complete path. Although DLL hijacking can be considered, both program files and system32 are administrator permissions, so do not think about it ......

When the res protocol URL is loaded in the new window, the final parsing, loading, and binding of resources is completed by the CResProtocol: DoParseAndBind of the CResProtocol class.

#!bash0:009> kvn 1# ChildEBP RetAddr  Args to Child              00 072fa464 664b2ad5 0f806814 00000000 00000060 KERNEL32!LoadLibraryExWStub (FPO: [Non-Fpo])0:009> dds esp072fa468  664b2ad5 MSHTML!CResProtocol::DoParseAndBind+0x103072fa46c  0f8068140:009> du 0f806814 0f806814  "ieframe.dll"

Code 1: CResProtocol: DoParseAndBind is using LoadLibraryEx to load ieframe. dll

DoParseAndBind:

A,Crack Res URL.

The Res URL format is described earlier.In addition, the first path of res protocol cannot contain "/". Because Microsoft hardcode directly searches for l'/'in the crack URL '/'.The first "/" (except res: //) That is encountered during String Parsing can only be followed by restype or id.

B,When the length of the imported res protocol path is greater than MAX_PATH, E_FAIL is returned, so Fuzz does not mean much here. This vulnerability exists in Win95 + IE4.0. This vulnerability was also identified after that vulnerability.

C,LoadLibraryEx loads the resource DLL. The Flag is DONT_RESOLVE_DLL_REFERENCES | LOAD_LIBRARY_AS_DATAFILE. Therefore, do not repeat the loaded DLL because it is mapped to the read-only memory. It will not be executed.

#!bash0:009> !address 67370000   Usage:                  ImageBase Address:           67370000End Address:            67371000Region Size:            00001000State:                  00001000    MEM_COMMITProtect:                00000002    PAGE_READONLYType:                   01000000    MEM_IMAGEAllocation Base:        67370000Allocation Protect:     00000080    PAGE_EXECUTE_WRITECOPYImage Path:             F:\WINDOWS\SYSTEM32\IEFRAME.dllModule Name:            IEFRAMELoaded Image Name:      F:\WINDOWS\SYSTEM32\IEFRAME.dllMapped Image Name:      More info:              lmv m IEFRAMEMore info:              !lmi IEFRAMEMore info:              ln 0x67370000More info:              !dh 0x67370000

Code 2: ieframe. dll allocated on the read-only page

0x02 previous feasible method: new Image judges res

It is indeed a little late, but to make up for it, I will analyze why it cannot be used.

In Angler Exploit Kit, attackers used Res Protocol to create a bunch of tricks. Use the following code to determine whether a local file exists.

#!jsfunction my_onError(){alert("file not exists!!");}function Check(s) {    x = new Image();    x.onerror=my_onError;     x.src = s;    document.body.appendChild(x);    return 0;}Check("res://f:\\node\\asoehook2.dll/#2/#102")

Code 3: Use Res Protocol to check local files
(However, in the latest IE11, this judgment cannot be performed under http/https/ftp, or the about: blank or the about: in blank. Next)

Why can Image do this? Let's take a closer look. You can also guess that new Image actually creates a CImgElement.

#!bashBreakpoint 10 hiteax=11fe3bc0 ebx=662016f0 ecx=11fe3bc0 edx=000001bc esi=65eb2270 edi=072fa3c8eip=66201739 esp=072fa3a4 ebp=072fa3b4 iopl=0         nv up ei pl nz na pe nccs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200206MSHTML!CImgElement::CImgElement:66201739 8bff            mov     edi,edi0:009> kvn # ChildEBP RetAddr  Args to Child              00 072fa3a0 66201718 0000003d 06a08000 662016f0 MSHTML!CImgElement::CImgElement (FPO: [Non-Fpo])01 072fa3b4 6625110b 072fa440 06a08000 072fa3ec MSHTML!CImgElement::CreateElement+0x28 (FPO: [Non-Fpo])02 072fa3f0 663aa61a 06a08000 11fe8a00 00000000 MSHTML!CreateElement+0xab (FPO: [Non-Fpo])03 072fa500 664c4bb9 0000003d 072fa524 00000000 MSHTML!CMarkup::CreateElement+0xee (FPO: [Non-Fpo])04 072fa548 664c49a0 06a7ee10 06920000 0bb24420 MSHTML!CImageElementFactory::create+0x49 (FPO: [Non-Fpo])05 072fa5b8 664c48e4 00000001 11fe8a00 072fa5d8 MSHTML!CImgElement::Var_create+0x89 (FPO: [Non-Fpo])06 072fa5e0 552f3b7e 189114e0 01000001 163c3d20 MSHTML!CFastDOM::CHTMLImageElement::DefaultEntryPoint+0x44 (FPO: [Non-Fpo])07 072fa648 552f8f53 189114e0 01000001 163c3d20 jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x18e (FPO: [Non-Fpo])

Code 4: Create CImgElement

After src is specified for the Image, the entire process is as follows:

#!bashCImgElement::OnPropertyChange ---> CImgHelper::SetImgSrc ---> CImgHelper::FetchAndSetImgCtx

In earlier IE versions, this set of processes did not consider res to prevent loading, so it could trigger the onerror event. However, src using file: // cannot determine whether the local file exists. This makes res judgment a unique existence.

Just as http cannot access local files through file protocol or UNC (for example, the above Code Check ("file: // f:/yy.jpg") will not throw an onerror event ), however, it can still be used in the about: blank opened on non-http/https/ftp websites.

The above description is invalid in the latest IE because of Microsoft's LMZL policy.

0x03 Local Machine Zone Lockdown

I will not post it to the final reference connection. paste it here:
Https://technet.microsoft.com/en-us/library/cc782928 (v = ws.10). aspx

LMZL is a security policy developed by Microsoft. Simply put, it is to prevent Internet content from accessing local content. As a matter of fact, it is already available in Windows XP SP2, however, after many years, I tried IE8 and can still use RES to access local resources.

Microsoft's whereabouts have always been a mystery. This behavior is also quite mysterious. Why is the logic of RES Protocol processed as a local file not added? Observe the code that IE8 and IE11 process the same local data to draw a basic conclusion-it should be forgotten.

Why does RES Protocol (in IMG src) in IE11 fail?

First, I entered the following code in IE. Unexpectedly, after document. body. appendChild (iii), the element is successfully added, but the image is not displayed, and onerror is not triggered. I thought it was because f: \ asoehook2.dll exists. The result is changed to a random address and the Res Protocol is added, but the onerror is not triggered.

In IE8, the Res Protocol displays images and triggers onerror.

In IE11, when Img SRC is specified as RES Protocol, Img displays a transparent square. Therefore, I first doubt these points: Is there a problem with the download? After tracking the download stack, we found that the download and IE8 are almost identical.

#!bashChildEBP RetAddr  039e85a4 764c14a2 urlmon!CBSCHolder::OnProgress(            unsigned long ulProgress = 0x338,             unsigned long ulProgressMax = 0x338,             unsigned long ulStatusCode = 4,             wchar_t * szStatusText = 0x0bbc2ce8 "res://f:\asoehook2.dll/#2/#102")+0x50 [d:\blue\inetcore\urlmon\mon\mpxbsc.cxx @ 807]039e85dc 764c46e1 urlmon!CBinding::OnTransNotification(            tagBINDSTATUS NotMsg = 
 
  ,             unsigned long dwCurrentSize = 0x338,             unsigned long dwTotalSize = 0x338,             wchar_t * pwzStr = 0x00000000 "",             HRESULT hrINet = 0x00000000)+0x35b [d:\blue\inetcore\urlmon\trans\cbinding.cxx @ 2676]039e8610 764c4458 urlmon!CBinding::ReportData(            unsigned long grfBSCF = 0xd,             unsigned long ulProgress = 0x338,             unsigned long ulProgressMax = 0x338)+0xa1 [d:\blue\inetcore\urlmon\trans\cbinding.cxx @ 5451]039e8638 764c43ec urlmon!COInetProt::ReportData(            unsigned long grfBSCF = 0xd,             unsigned long ulProgress = 0x338,             unsigned long ulProgressMax = 0x338)+0x54 [d:\blue\inetcore\urlmon\trans\prothndl.cxx @ 1863]039e8674 764c4303 urlmon!CTransaction::DispatchReport(            tagBINDSTATUS NotMsg = BINDSTATUS_ENDDOWNLOADDATA (0n6),             unsigned long grfBSCF = 0xd,             unsigned long dwCurrentSize = 0x338,             unsigned long dwTotalSize = 0x338,             wchar_t * pwzStr = 0x00000000 "",             HRESULT hresult = 0x00000000)+0x19e [d:\blue\inetcore\urlmon\trans\transact.cxx @ 3153](Inline) -------- urlmon!CTransaction::DispatchPacket+0x23 [d:\blue\inetcore\urlmon\trans\transact.cxx @ 3278](Inline) -------- urlmon!CTransaction::OnINetCallback+0x116 [d:\blue\inetcore\urlmon\trans\transact.cxx @ 3356]
 

Both of them have successfully obtained the required resources. It seems that this can be ruled out first.

Then, let's track the event again. To MSHTML! CImgHelper: the breakpoint under Fire_onerror. I modified iii. src = "aa" to confirm my correctness. At this time, Fire_onerror is triggered successfully.

Figure: The onerror event is successfully triggered when a non-res Protocol is passed to src of iii.

When Res Protocol is specified in IE11, Fire_onerror cannot be broken. This can prove a conjecture: If IE prohibits RES Protocol from being used in IMG, this prohibition logic may not be processed in the event.

In IE8, Fire_onerror can still be disconnected even if Res Protocol is used:

The target is placed at the front and back layers of Fire_onerror. The previous layer of OnDwnChan does not seem to be correlated. the next layer, the CImgHelper: SetImgCtx has some differences.

#!bash0:008>?eax=00000000?ebx=071b2930?ecx=039e9cb0?edx=00000000?esi=00000000?edi=00000000eip=639c17ce?esp=039e9c9c?ebp=039e9cd0?iopl=0?????????nv?up?ei?pl?nz?ac?pe?nccs=0023??ss=002b??ds=002b??es=002b??fs=0053??gs=002b?????????????efl=00000216MSHTML!CImgHelper::SetImgCtx+0x11:639c17ce?e868feffff??????call????MSHTML!CImgHelper::CScriptCalloutProtection::CScriptCalloutProtection?(639c163b)0:008>?eax=039e9cb0?ebx=071b2930?ecx=071b2934?edx=071b2930?esi=00000000?edi=00000000eip=639c17d3?esp=039e9ca0?ebp=039e9cd0?iopl=0?????????nv?up?ei?pl?nz?na?po?nccs=0023??ss=002b??ds=002b??es=002b??fs=0053??gs=002b?????????????efl=00000202MSHTML!CImgHelper::SetImgCtx+0x16:639c17d3?33f6????????????xor?????esi,esi0:008>?eax=039e9cb0?ebx=071b2930?ecx=071b2934?edx=071b2930?esi=00000000?edi=00000000eip=639c17d5?esp=039e9ca0?ebp=039e9cd0?iopl=0?????????nv?up?ei?pl?zr?na?pe?nccs=0023??ss=002b??ds=002b??es=002b??fs=0053??gs=002b?????????????efl=00000246MSHTML!CImgHelper::SetImgCtx+0x18:639c17d5?397314??????????cmp?????dword?ptr?[ebx+14h],esi?ds:002b:071b2944=031a8e000:008>?eax=039e9cb0?ebx=071b2930?ecx=071b2934?edx=071b2930?esi=00000000?edi=00000000eip=639c17d8?esp=039e9ca0?ebp=039e9cd0?iopl=0?????????nv?up?ei?pl?nz?na?pe?nccs=0023??ss=002b??ds=002b??es=002b??fs=0053??gs=002b?????????????efl=00000206MSHTML!CImgHelper::SetImgCtx+0x1b:639c17d8?0f857b090000????jne?????MSHTML!CImgHelper::SetImgCtx+0x217?(639c2159)?[br=1]0:008>?eax=039e9cb0?ebx=071b2930?ecx=071b2934?edx=071b2930?esi=00000000?edi=00000000eip=639c2159?esp=039e9ca0?ebp=039e9cd0?iopl=0?????????nv?up?ei?pl?nz?na?pe?nccs=0023??ss=002b??ds=002b??es=002b??fs=0053??gs=002b?????????????efl=00000206MSHTML!CImgHelper::SetImgCtx+0x217:639c2159?397344??????????cmp?????dword?ptr?[ebx+44h],esi?ds:002b:071b2974=00000000

CImgHelper: CScriptCalloutProtection does not exist in IE8, but unfortunately, CImgHelper: CScriptCalloutProtection is not our target.

However, the goal is not far away. If you continue to look at some code, you can find that IE11 made a CMarkup: CheckForLMZLLoad (v8, 1) when setting the context of the IMG element );.

Is LMZL still impressed? It is the Local Machine Zone Lockdown mentioned in the previous section. The name seems to be a bit of a problem. It is also a mystery for Microsoft to cover the amount of code it contains.

Remember the second parameter 1.

After entering CheckForLMZLLoad, we can see if (a4 = 1) {v8 = & FCK: FEATURE_BLOCK_LMZ_IMG ;}

Obviously, Microsoft restricts the loading of image resources in the Local Machine Zone when setting the context of IMG.

Set context? I almost forgot. The function for retrieving images and setting context is CImgHelper: FetchandSetImgCtx.

Since the context settings fail, the event binding and triggering will inevitably fail, and even worse, the image will not be displayed. RES Protocol's function of determining whether a local file exists has been destroyed since then.

0x05 Network diagnosis

Maybe you haven't used IE in the past year. It doesn't matter. There is an error in IE that cannot display this page and it's still there. When you access a website that cannot be processed, IE will display res: // ieframe. dll/dnserror.htm # http: // xxx. There is a "Fix connection problem" on this page ".

Click this item to pop up a network repair program, which is amazing. So will there be security issues here? How is the fixing program IE located?

After tracing, you can find that ietify uses the launchmsdt.exe of ndfapi, and the agent starts msdt.exe under system32. The call uses the complete path, so you do not need to consider issues such as exe hijacking.

#!bash0:009> kvn # ChildEBP RetAddr  Args to Child              00 072fa2cc 54f3c7ec 08085978 004bdf80 00000000 KERNEL32!CreateProcessWStub (FPO: [Non-Fpo])01 072fa5b0 54f3cb1c 07fff5a8 fedbc665 54f32b80 ndfapi!LaunchMSDT+0x201 (FPO: [Non-Fpo])02 072fa688 54f3c5d8 00000001 54f30000 072fa6bc ndfapi!CNetDiagClient::LaunchScriptedDiagnostics+0x143 (FPO: [Non-Fpo])03 072fa6a0 54f377a2 00000001 072fa6dc 67654b7d ndfapi!NdfExecuteDiagnosisEx+0x53 (FPO: [Non-Fpo])04 072fa6ac 67654b7d 069d37e0 00040c94 00000000 ndfapi!NdfExecuteDiagnosis+0x12 (FPO: [Non-Fpo])05 072fa6dc 675ee143 072fa72c 07b3f7cc 07ffec54 IEFRAME!DiagnoseConnectionProblems+0xa9 (FPO: [Non-Fpo])06 072fa9bc 7732b0ff 07ff4ff8 072faa0c 07ffec54 IEFRAME!CShellUIHelper::DiagnoseConnection+0x2d3 (FPO: [Non-Fpo])07 072fa9d4 7730c807 07ff4ff8 00000070 00000004 OLEAUT32!DispCallFunc+0x16f

It seems that everything is so rigorous, but who knows, IE always has a variety of small problems in the most unexpected places.