Droplr Drive-by

For the uninitiated, Droplr is a web service that allows you to easily drop a file onto the Internet. Drag the file to the Droplr icon, it uploads the file onto the Droplr servers, then gives you a shortened URL to paste into email, chat, Facebook or whatever.

Droplr is clearly not a service that grew popular because of security. Regardless, its combination of the two following features bring about a false sense of security (through perceived obscurity). Which leads its users into a sort of self-inflicted social engineering hack, as you will see.

First, it's simple and easy to send content out to the publicly addressible Internet. Need to send someone a screen grab? Easy. Drag, then paste the url into an email. Done.

Second, it provides a shortened URL. Also convenient, because who needs long URLs that get distorted in chat windows?

While I've never used the service myself to send anything, I've received any number of links from coworkers and friends. It's easy to recognize the value provided, and like most who use it (I'd guess), I didn't give the security ramifications much thought. Just went with the general impression. Obviously, uploading anything to a third party poses the risk that the third party will snoop your data. This isn't really any different than using email to send sensitive attachments, however.

It was the shortened URLs that finally caught my attention. They appear randomized, and unintelligible, i.e. http://d.pr/B0tw. So it's easy to land on the idea that they are more or less "out of band" URLs. Similar to what you get when you share a Dropbox file – a long random string that is basically unguessable. Except they're not, because of the desire for Droplr to shorten the URLs to make them copy-paste friendly.

The URLs are unassociated, certainly, but that just means that for a random file X, there is no direct association to the person who posted it. Unless the content of X implies something about the user. Or, X gives something away that the user would rather it didn't. Either way.

A friend sent me a link via Skype, and after clicking it, the implication of the short d.pr domain finally dawned on me. If the intention is to provide short URLs, it's implied that you will start at a small index and grow outward. Meaning it's easy to discover links that result in some kind of payload. To create an "out of band" URL you must use a sequence large and random enough so that guessing it is improbable.

(This has been true since tinyURL made URL shortening a thing. However, that service didn't also combine the ability to upload content at the same time, which is the bad mix, in my opinion.)

So I deleted one character from the URL my friend sent me, and sure enough I got someone else's drop.

After only a little time manually appending random alphanumeric paths to http://d.pr/, I came upon someone's order from Sears. Complete with two phone numbers, address, order number, and email. Someone was upgrading their sleeping experience, apparently –

A few other things I discovered in under thirty minutes of hand entered "Droplr drive-bys" –

And finally, a smoking gun, so to speak. I found a screenshot of a bank account with all sorts of account information and digits. It was a European account, but Google Translate helped me figure out what the labels meant. It was probably enough information to get someone in trouble.

So it's clear to me that the impression I had about the relative safety of Droplr is not uncommon. That since the shortened URLs are basically meaningless with regard to the content, it's an easy jump to make that somehow they are not going to be discovered easily. That they are "out of band". But that's simply not the case.

Discovering drops is trivial. And if I am capable enough, I can write a script that automates it for me. Which I did. And include below. And someone else has most likely done too, but isn't sharing, and is instead using for who knows what purpose.

The simple "drive-by" Droplr Perl script. It randomly tries a Droplr URL and opens it in your browser if it exists.

[Code redacted] Note: While this code is trivial to write, I felt it prudent to
remove it from the article. Seriously, it was 24 lines of Perl.

Finally, it seems clear that Droplr understood these issues when they designed their service, or at least grokked them soon enough. A couple snippets from their Terms & Conditions:

Your Droplr.com Account and Site. If you create an account on the Website, you are responsible for maintaining the security of your account, and you are fully responsible for all activities that occur under the account and any other actions taken in connection with the account.

Responsibility of Website Visitors. ... The Website may also contain material that violates the privacy or publicity rights, or infringes the intellectual property and other proprietary rights, of third parties, or the downloading, copying or use of which is subject to additional terms and conditions, stated or unstated. Droplr disclaims any responsibility for any harm resulting from the use by visitors of the Website, or from any downloading by those visitors of content there posted.

And so on. This is a pretty familiar attitude in the cloud. If you can achieve simplicity and convenience, everything else is negligible.