Update (22th June): Barracuda Networks has successfully patched both vulnerabilities in the referral system.
At the time of this writing, the bonus space I've earned through various methods on the awesome Copy service from Barracuda Networks exceeds 1TB.
If you've been living under a rock during the last few months, Copy is a file synchronization service similar to Dropbox, which adds two very savoury ingredients to the tried recipe:
- cost of shared storage is split across all users accessing the shared files (Barracuda Networks calls this "Fair Storage");
- no limit on the extra storage that can be obtained via user referrals.
I can't have enough online storage, so I was naturally interested to add storage to my Copy account by getting referrals. I learned something unexpected in the process.
First mandatory step: AdWords campaign
Back in the Dropbox days, I maxed my account storage via referrals using a targeted Google AdWords campaign, with a total expense of less than €6 during one week, with a pretty good 5% conversion rate. In more detail:
- 558 people clicked on the ads;
- 80 people out of 558 signed up for Dropbox;
- 32 people out of 80 installed the application, giving me 500MB of extra storage.
It felt natural to try this with Copy as well, but I struggled with getting the same conversion rate:
- 1741 people clicked on the ads;
- 13 people out of 1741 signed up for Copy;
- 9 people out of 13 installed the application, giving me 5GB of extra storage.
The case of the missing referrals
A couple days later a friend of mine signed up for Copy using my referral, and we noticed something weird in the e-mail Copy sent him:
My friend was sure he used my referral to signup - I was sure my name was not Fabio either - so that 0.5% conversion rate just began to make more sense: there was probably a bug in Copy's referral system.
Now, I was really curious about how this could happen. Did Fabio R. somehow got my very same referral code? I set out to understand how the Copy sign-up process was carried out client side, hoping to shed light on this and file a report to Barracuda Networks' support team.
The infamous "success" GET request
Later that day I opened Chrome's developer console and tried to make sense of what happened during the registration process. I opened an account through my referral code, installed the desktop application on another system, and I found a couple peculiar requests:
The registration process started with a POST request with the registration data (including the referral code) followed by a GET. At first glance the GET request looked like it was meant to just load the usual "Congratulations" page, but upon closer inspection I noticed it still carried the referral code in its cookies (don't bother to verify this, it's not happening anymore), which made no sense to me: the server already had its chance to store the referral code, why would it be sent again?
Using the awesome requests library by Kenneth Reitz, I quickly set up a script that replicated this particular GET sequence. I had not a clear plan in mind at this point, and just ran the script a couple times to look at the responses and hope to spot wrong patterns.
A couple minutes later I noticed this in my e-mail inbox:
Excuse me? The Copy AdWords campaign was paused and I was pretty sure ten people signing up through my referrals and installing the application in around 10 minutes was unlikely at best.
So it looked like repeating the GET request with the same headers and cookies recorded during registration triggered the referral system, provided the desktop application was installed on the referee's system.
At this point I knew I had stumbled on something: I opened a ticket to Barracuda Networks' support, describing the initial problem with the referral going to Fabio R., and went to bed. That is, after leaving the script to run in an endless loop, just to see what would have happened. I woke up the next day with around 0.9TB of Copy storage.
Barracuda Networks was pretty quick to fix this: I opened my ticket on a friday night and the script wouldn't work anymore next monday...
Fiddling with UUIDs
...except that I noticed something weird in the new GET request that the browser was now emitting at the end of the registration process. The request cookies contained an UUID that wasn't present days ago.
Could it be a fingerprint identifying the computer from which the request was coming? I didn't investigate much, but just out of curiosity I ran again the script crafting a new UUID for each GET request, and got referral bonuses from most (but, interestingly, not all) of the requests.
Patching it, this time for real
I was looking forward to investigate this further, but it looks like Barracuda Networks was quicker to fix this than me to report it. Meanwhile, the Copy desktop client received a push version update from 1.28.657.0 to 1.30.0347. I can only assume it's related to the vulnerabilities reported in this post.
Parting words
Copy really is an awesome service. Its Fair Storage sharing rule is what sets it above most of its competitors for me (think family photos) and I look forward to use it a lot in the future.
If you enjoyed reading this, and don't have a Copy account yet, please sign up through my referral; the genuine extra space I'll earn this way will have me covered just in case Barracuda Networks decides to do something about that questionable 0.9TB earned during one night :)
If you enjoyed reading this, and don't have a Copy account yet, please sign up through my referral; the genuine extra space I'll earn this way will have me covered just in case Barracuda Networks decides to do something about that questionable 0.9TB earned during one night :)
Why bother? Crashplan will already let you use 1TB ;)
ReplyDeleteActually Crashplan offers unlimited storage for $4/mo, but that and Copy are very different services.
ReplyDelete