A possibility of Account Takeover in Medium

There are times when you discover something that is very common and ordinary which just blows your mind and you start thinking, “How come I didn’t knew this before!?”. I recently had that kind of a moment when I came to know that Twitter allows users to change their username. This immediately triggered a thought, “What if somewhere Twitter integration in a website is depending on Twitter username?”. I know this sounds crazy, but I thought this was worth a try.

The Vulnerability

Long story short, turns out the login from Twitter on Medium depends on the Twitter username! Since Twitter allows users to change their username, if someone having his medium account connected to Twitter changes his username, we can change our Twitter username to his and by logging in via Twitter in Medium, we’ll log into their account.

Here’s how it would look like:

  1. Login to Medium, go to Settings and link the account to Twitter:

alter-text

alter-text

alter-text

  1. Now let’s say this Twitter user changed his username to something else. I as an attacker will change my Twitter username to notsoshant.

alter-text

  1. Now go to Medium and choose the Sign In with Twitter option. By using attacker’s Twitter profile to log in, we can notice Medium actually logs in to victim’s Medium account.

alter-text

As stupid this vulnerability may look like, this obviously shows implementing OAuth can go very wrong sometimes. I don’t prefer OAuth in general because if an OAuth provider gets compromised, all the connected accounts will get compromised automatically. A recent Facebook vulnerability allowed attackers to access token for millions of users. If you are logged in to any service through Facebook, that account was compromised too! So folks, always prefer a new account for each website and avoid OAuth! And experts recommend this too.

Vulnerability Disclosure Timeline

September 13th, 2018: Vulnerability disclosed to Medium
September 25th, 2018: Vulnerability patched by Medium. No rewards or credits given.

Yeah, no rewards or credits because they concluded:

“Report does not meet the criteria outlined in the Bug Bounty program (https://medium.com/policy/mediums-bug-bounty-disclosure-program-34b1c80764c2), and therefore is not eligible for a reward.”

I guess it’s because it falls in the category of “Bugs that require unlikely user interaction or phishing”.

comments powered by Disqus

Related Posts

Attacking Kerberos: Resource Based Constrained Delegation

Now that we are done with Unconstrained and Constrained Delegations, it is time for the finale. In this blog we’ll discuss Resource Based Constrained Delegation (RBCD).

Read more

Attacking Kerberos: Constrained Delegation

In the last blog, we discussed Unconstrained Delegation in detail. We also saw how dangerous Unconstrained Delegation can get. Unconstrained Delegation was the very first implementation of Delegations, introduced back in Windows Server 2000.

Read more

Attacking Kerberos: Unconstrained Delegation

So we are going to talk about Unconstrained Delegation in this blog. I have already covered a small introduction to Delegations and the Kerberos concepts you’d need to understand it in an introduction blog.

Read more