Recon stage

So, if we were to describe the app, what does it do? Where are the potential entry points? T&T Admin is an administration app for a fishing company, so upon logging in we see a dashboard full of tools useful for T&T’s fishermen & women. Nothing too fishy though (no pun intended). We know that we should search for authentication vulnerabilities though, so let’s do that.

T&T Admin has two login providers: Github and the good ol’ Email/Password login. Both of them seem to work; Email/Password-login seems to generate a random name upon account generation. What’s interesting is the role all newly created accounts get: Worker (Arbetare in Swedish). Maybe there is a more priviledged role?

Luckily, we have a SysAdmin which is particularly prone to clicking on malicious URLs in emails. if anything, she should have a highly privileged account.

Github OAuth 2.0 flow

Let’s look a bit at how the Github authentication is built. I’ve created a page for what the complete Sign in/Sign up flow for Github looks like here:

A typical sign-in flow in terms of requests

After some recon, maybe you found the following:

• The next-auth.csrf-token cookie is stale and once set it always has the same value
• The Github OAuth 2.0 app docs indicate which redirect_uris are accepted, and when testing it seems like all pages on the domain are accepted

Since the redirect_uri rules seem to be kind of loose, maybe we can leak the code or OAuth token by providing a different redirect_uri?

<aside> 🚨 OAuth account hijacking via redirect_uri is a common vulnerability Read more here

</aside>

Finding a way to hijack account via redirect_uri

We need to find a page that lets us send potential sensitive OAuth 2.0 information to our malicious web server. What is the first thing that comes to mind? An XSS or maybe an open redirect vulnerability!

We could use a URL fuzzer, but why not check robots.txt first? Apparently, the SysAdmin doesn’t want Google to index a whole lot of authentication endpoints. Why is unclear, but at least these gives us a chance to explore them.

At this point you maybe also have figured out that T&T Admin is using NextAuth for managing the whole login process. Strangely though, turns out that all endpoints in robots.txt except for /oauth/callback seems to exist in the NextAuth docs.

What is the /oauth/callback page?

Upon initial discovery, the page looks like a simple redirection page used in the middle of an OAuth flow. After 5 seconds it actually redirects to /account/dashboard. Seems like a component to a deprecated OAuth flow.

But analyzing the source code gets us this little gem: