Tips Security Vulnerability Patched (Thank you to Deco.Network)
How we patched a critical production issue, with help from our friends at Deco Network.
On July 26th 2018, I received a message from my friend David Sneider of the Deco Network:
His CTO, Chris Cassano, had been looking through our Tips code, which had just received a major update the previous day, and found a vulnerability in the new code.
Here’s a screenshot of Chris exporting some private keys of funds in transit. (no customer accounts were put at risk).
Although this code had only been in production for less than 24 hours, Tips is one of our our primary features, and this was a huge security oversight!
Actions we Took Immediately
Upon Chris’s bug report, we immediately disabled tips until we could work through a new, secure, version of the Tips software.
We also notified any customers that had affected unclaimed Tips to claim their Tips immediately.
After an internal huddle with the Gitcoin backend team, we came up with patch.
Sidebar: How Tips works
Tips are an easy way to send ETH/ERC20 tokens to any github username without any intermediary ever holding the private key.
In order to achieve the right UX (send tokens to any github username) with the right security concerns (we never hold the private key), we take the following approach:
We use Shamir’s secret sharing algorithm to break the private key into three chunks, of which, two are needed to reconstruct the private key.
In order to avoid Gitcoin having custody of any of the funds, we upload two of the shards of the key to IPFS, and only save one on the Gitcoin server.
We then email out one of the IPFS addresses to the funder, one IPFS address to the recipient of the funds, and destroy those the secrets themselves.
When a funder/recipient receives their email, they can click the email and use the IPFS address that references their secrets, combined with Gitcoin’s secret (which is provided only if they pass an authentication check that they are indeed the recipient of the funds), and claim the funds.
Chris’ exploit
Chris’s exploit combed IPFS for the shared keys, and used the shared keys to reconstruct the private key. Check out Chris’ post for his thought process, and how he found the vulnerability.
Our root cause fix
Our primary oversight in the design, coding, and subsequent code review of this feature was to upload two shares of the key to IPFS. Our root cause fix was to
- store one shard on gitcoin’s server
- destroy one shard (new)
- upload one shard to IPFS
You can see the patch here.
We also are happy to say that we sent a nice reward to Chris for disclosing the security vulnerability to us.
What we learned
We take security very seriously at Gitcoin, and it’s clear to us that while this code was only live for 24 hours, this was a major oversight on our part.
We were reminded that fast Agile development is sometimes incompatible with the needs of security, and are conducting an internal review of our own development processes.
We will also hope to be engaging with Consensys Diligence on security matters in Q3 2018.
We learned that security bug bounties are a good thing, and help to align incentives of hackers with our own incentives, to create more security vulnerability reports! To anyone out there reading this who wants to do more security bounties with us, checkout this issue.
We ❤ Deco Network
It would suffice to say that we have a deep affinity for the Deco Network.
They have appeared on our livestream. We’ve met in person a few times. We hope to continue a fruitful relationship into the future as they launch.
We appreciate them notifying us immediately of this issue, and look forward to supporting them and their audience in the future.
~ @owocki
To learn more about Gitcoin, click below.
