November 6, 2017

HITCON CTF Quals 2017 - Footbook

Don’t like Facebook? Try our brand-new social networking service!

tl;dr

Proxy requests from 127.0.0.1:3000 to the remote server: socat TCP-LISTEN:3000,fork TCP:13.114.238.13:80

Register a Dropbox account with email address [email protected]

Log in to site at 127.0.0.1:3000 using Dropbox OAuth

Get flag!

explanation

We are presented with a very simple social media website that allows registered users to make public posts and send messages to other registered users (via their email address).

Email addresses for users who log-in directly via username/password are given email addresses of the form [email protected].

An admin user ([email protected]) can be found by visiting profile ID 1… and they have a post:

Only I can see the flag ^_<

So we have our target.

There doesn’t appear to be anything interesting to do in the actual site, so we return to the login page.

Each of the OAuth login options is disabled (client-side) because our host isn’t 127.0.0.1:3000. Ignoring that, and visiting the Twitter OAuth login page, we can log-in via Twitter and our user email will be the email on the Twitter account. Unfortunately, Twitter will only allow us to create/log-in with email addresses we control (and we do not control [email protected])

The other two OAuth providers (GitHub and Dropbox) reject our login for having a different callback URI than expected, and using plain HTTP for a callback URI on a domain/IP other than localhost, respectively. However, if we proxy requests from 127.0.0.1:3000 to the remote server and access the website using it, both of these login systems begin working.

Examining GitHub and Dropbox, we find that Dropbox does not require you verify control of an email address before using it for OAuth authentication. Unfortunately, the email address [email protected] is already taken on Dropbox, so we will have to find another way.

Rereading the JavaScript code for the message-sending code, we see that it only uses data before the first + character in the email username (so sending a message to [email protected] sends a message to [email protected]). We surmise that the OAuth registration code on the server is doing the same thing (otherwise, no messages can be sent to users with + in their email address) and register a Dropbox account with an email address like [email protected].

We are able to successfully log-in to the site, and at the top of the page is a box with the flag!

hitcon{mom_said_i_can_trust_oauth_T_T}