deal with leak of Venmo access/refresh tokens

[chadwhitacre]

@Changaco asked for a dump of the elsewhere table as part of his work on gratipay/gratipay.com#1369 (IRC). I gave him:

• a snippet of the table as a gist
• a dump of the whole table (~60k rows) uploaded to http://static.whit537.org/2014/elsewhere.tbz (now 404).

I had decided this was acceptable because the elsewhere table doesn't contain any information that's not publicly accessible via existing APIs (the user_info comes from public APIs on other platforms, and the link between a Gittip account and an account elsewhere is scrapable on public Gittip). Except that it does. In gratipay/gratipay.com#1857, when we added the ability to connect a Venmo account, we added access_token and refresh_token fields to the elsewhere table. These are private tokens that can presumably be used to impersonate a Venmo user, which is a big deal because Venmo is a payments company and impersonating a user would likely mean taking their money.

The gist does not contain any access_tokens or refresh_tokens, because I only included the bitbucket, bountysource, github, and twitter platforms in that gist (I didn't have venmo in mind, clearly), and we don't store oauth tokens for those platforms.

The elsewhere.tbz file contains Venmo tokens for approximately 49 users (depending on the exact state of the database when I did the export; currently there are 49 users with venmo attached).

I've taken down the elsewhere.tbz file. The static.whit537.org web server does not keep access logs, so I don't know how many times elsewhere.tbz was downloaded. It was up from Feb 4 at 12:53pm US/Eastern until today, Feb 7 at 8:45am US/Eastern.

Next steps:

• Understand the implications of leaking oauth access and refresh tokens.
• Decide how to repair the damage.
• Decide what notification of affected users is necessary.
• Decide what notification to Venmo is necessary.

I believe we should be able to simply revoke at least one of the tokens, and hopefully both.

We have another situation with Venmo where we're using an oauth app registered under my personal Venmo account, and would like to move to an oauth app registered under the Gittip Venmo account. It could make sense to make that switch as part of dealing with this ticket.

[bruceadams]

I think we want to bring Venmo in the loop soon, probably now. Not sure how best to, in fact, do that.

[clone1018]

@whit537 Did you post the file anywhere on the public internet or just in a query to Chango?

Another question:
Would moving key accounts (from Chad Whitacre to Gittip) reset the users keys? Would the users notice anything?

[chadwhitacre]

@clone1018 The file was available on the public Internet. I posted the URL in public, logged IRC (but only there).

[chadwhitacre]

@bruceadams I think it would make the most sense to start by reaching out to the two Venmo employees that were working with us in the first place. I wish we could give them permissions on this ticket without giving them permission on the repo as a whole. :-/

Not sure how best to do this ...

[bruceadams]

Well, can we give them access to this repo for now and take it away later?

That doesn't help much for the next incident we might want to bring other people in for, but should work for this one, for the moment.

[chadwhitacre]

This is encouraging:

The idea of refresh tokens is that if an access token is compromised, because it is short-lived, the attacker has a limited window in which to abuse it.

Refresh tokens, if compromised, are useless because the attacker requires the client id and secret in addition to the refresh token in order to gain an access token.

[chadwhitacre]

I've reported to Venmo (@simon-weber) via IRC private message (not the most secure but I think acceptable in this circumstance).

[chadwhitacre]

I've renamed this repo from security to security-00000. Let's try having one private repo per security incident. Unfortunately I had to create a new team to give @simon-weber access here, and the existence of that team is (I believe) public.

[chadwhitacre]

From @simon-weber in private IRC:

ok. so we just need affected folks to revoke and make sure there aren't any transactions they don't recognize, right?

[chadwhitacre]

There are 41 affected accounts.

[chadwhitacre]

Notifying users is a challenge, because we don't have email addresses, at least on the Gittip side (gratipay/gratipay.com#89).

[chadwhitacre]

@simon-weber We also need to switch from using an oauth application registered with my personal Venmo account, to using one registered with Gittip's Venmo business account. Would destroying the current oauth application effectively revoke the user's refresh tokens?

[simon-weber]

We revoked each individual token on our end.

We're going to check to see if there were payments made on those accounts since the leak.

[chadwhitacre]

!m @simon-weber. Thank you.

I've emailed [email protected] about a problem I'm having creating a new oauth application using the Gittip business account. I get the following when I click "new" next to Your Applications (0):

[simon-weber]

We should be good to go: there were no payments made through the gittip consumer since the leak (or ever actually, which is probably to be expected since we never had that functionality hooked that up on gittip.com).

[simon-weber]

@whit537 re: trouble making the application: I'll see if I can get more details.

[chadwhitacre]

Awesome, thanks @simon-weber!

[chadwhitacre]

@bruceadams @zwn @clone1018 How does Gittip want to go about disclosing this leak? I propose that we write a blog post about it.

One advantage to the "one repo per security incident" model is that we can make the repo public (after reviewing for further sensitive info) once we're ready to disclose the incident.

[zbynekwinkler]

I am fine with that.

[bruceadams]

A blog post sounds good. (I'm not offering to write it.) Making this issue public is fine as well.

[chadwhitacre]

Draft:

Forty-one Accounts Involved in Security Leak

On February 4, 2014, we leaked security tokens for the Venmo accounts of 41 Gittip users, which an attacker could have used to steal money. We discovered the leak on February 7, and immediately stopped the leak and notified Venmo. Venmo revoked the affected security tokens, and confirms that no fraudulent transactions were made using these tokens.

No user action is required.

For details, please see the incident repository, which was private while the incident was underway and has been made public with this disclosure.

Sorry. :-(

[chadwhitacre]

I've made this repo public. Let's finalize the blog post and publish.

[chadwhitacre]

Published:

http://blog.gittip.com/post/75923869768/forty-one-accounts-involved-in-security-leak

[balupton]

There are 41 affected accounts.

What does that actually mean? Was there only 41 accounts with Venmo linked to Gittip? What makes these 41 accounts special?

No user action is required.

At the very least, Gittip should notify those affected.

[zbynekwinkler]

That is the number of connected Venmo accounts. Gittip has now way of notifying its users 😟 besides the blog post.